Tdoc List
2016-08-24 18:04
| Agenda | Topic | TDoc | Title | Source | Type | For | Avail | Treated | Decision | Wdrn | Replaced-by | Replaces |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Opening of the meeting (Monday, 9 a.m.) | |||||||||||
| 2 | Approval of the agenda | R6‑160001 | Draft Agenda | Convener (Nokia) | agenda | Approval | Yes |
YesNicklas JOHANSSON (Ericsson) volunteered to keep track of the RAN6 workplan in the future (see AI 9)
The convener also presented a draft schedule of the meeting for which no comments were raised.
| approved | No | ||
| R6‑160004 | Void | ETSI MCC | discussion | discussion | No |
Yes
| withdrawn | Yes | ||||
| 3 | General matters | |||||||||||
| 3.1 | Matters related to organization and way of working of the group | R6‑160063 | TSG RAN WG6 meeting organization and way of working | convener (Nokia) | discussion | discussion | Yes |
Yesconclusion: GERAN #70 report will be reviewed by email over RAN6 reflector after RAN6 #1 to have a final report;
Qualcomm: RAN6 may not need 5 days in the future
conclusion: let's look at this again at the end of RAN6 #1
Qualcomm: probably enough to use one reflector, so no need for drafts reflector
conclusion: let's see now many documents we will see on the drafts reflector in the future, if not really used then was can change the process and use one reflector only
MCC: old reflectors will not be removed from the archive, just no longer be used
Ericsson: can we have an earlier deadline for Tdocs?
conclusion: Tdoc request and submission deadline will be 9pm CET (CEST in summer) on Fri one week before the meeting
| noted | No | ||
| 4 | Liaisons / reports from other groups / meetings | R6‑160055 | LS on CS/PS coordination in GERAN Shared Networks (R3-161501; to: SA2; cc: GERAN2 = RAN6; contact: Ericsson) | RAN3 | LS in | discussion | Yes |
Yespresented by Nicklas JOHANSSON (Ericsson)
convener: RAN3 is fine with the proposal from SA2 to apply same approach as suggested by GERAN; no comments
conclusion: no reply from RAN6
convener: GERAN #69 sent LSs to CT1 and SA3 where we are still wating for replies, GERAN #70 sent LSs to CT1 and CT4 as well also no response here so far; we will check what happened with them
| noted | No | ||
| R6‑160064 | LS on Legacy Security Issues (S3-161224; to: RAN6, CT1; cc: CT6; contact: Qualcomm) | SA3 | LS in | discussion | Yes |
Yespresented by Mungal Singh DHANDA (Qualcomm)
Qualcomm: CR looks similar to what we have in our specs but it is here subscription and PLMN based;
Qualcomm: a bit worried about "use of not encrypted mode shall be disabled", we always start in non-encrypted mode; how does Access Stratum enforce what is indicated in the LS? So complicated (if not impossible) for the MS to implement;
Ericsson: agrees that we start in non-encrypted mode even if we want to go to encrypted as fast as possible; it seems this requirement is forbidding non-encrypted at all (this is not what we have today);
convener: should we allow for more time to review it?
Qualcomm: also Note 2 does not make much sense, how can a false BS talk to a genuine BS? If MS cannot trust a genuine BS, then what can the MS do?
conclusion: Qualcomm will draft an LS reply in R6-160088
| replied to | No | ||||
| R6‑160088 | Reply to LS R6-160064 = S3-161224 on Legacy Security Issues (to: SA3; cc: CT1, CT6; contact: Qualcomm) | current meeting | LS out | approval | No |
No
| reserved | No | ||||
| 5 | Work related to Rel-13 or earlier features | |||||||||||
| 5.1 | eDRX_GSM | R6‑160023 | Clarification of CCCH_GROUP Determination | Ericsson Inc. | CR | Decision | Yes |
Yespresented by John DIACHINA (Ericsson)
convener: source to TSG should be R6
Nokia: 2nd inserted bullet unclear, MS tries to negotiate but network does not support eDRX that's we defined lowest eDRX behaviour
Ericsson: does not think there is a problem, is the concern about a transient condition?
Nokia: is it necessary to specify things explicitly as there is no other way to do it?
Ericsson: we need to clarify the timing of this action
Nokia: we may need a statement for EC-RACH as well
convener: MS is any MS or MS in EC operation?
Ericsson: we do not talk about EC-RACH here
convener: still unclear about MS we talk in "MS shall determine its CCCH_GROUP"
Ericsson: it is clear that this must be an MS in EC operation (otherwise it would not be able to send an EGPRS PACKET CHANNEL REQUEST message)
convener: then change "a MS shall determine the applicable CCCH_GROUP" to "the MS shall determine the applicable CCCH_GROUP"
convener: test spec affected?
Ericsson: is a mistake
| revised | No | R6‑160076 | |
| R6‑160076 | Clarification of CCCH_GROUP Determination | Ericsson Inc. | CR | Decision | No |
No
| reserved | No | R6‑160023 | |||
| R6‑160024 | Clarification of PEO codepoint usage | Ericsson Inc. | CR | Decision | Yes |
Yespresented by John DIACHINA (Ericsson)
convener: source to TSG needs to be corrected and IOT WI code should be added, consequences if not approved needs to be updated
MCC: wrong CR number on the CR cover
Ericsson: would like to modify "0 PEO access request" to "0 non EC-GSM-IoT access request" as this may then be used also in other cases
Nokia: should we change our previous approach, was former CR approved?
Ericsson: yes, code-point was discontinued and should not be used
Nokia: but should we change this then and reuse it for something?
Nokia: another code-point than this spare bit could be used
Ericsson: does not see a problem for positioning
Nokia: we prefer to use spare bit for positioning and code point for PEO
Ericsson: using a spare bit for positioning only is maybe not the best choice as we have other REL-14 aspects to take into account, maybe some offline discussion is needed
convener: any information how often the code point is used?
Ericsson: seems to be limited to Germany
Nokia: impact on 45.002 (we have a CR on it as well) and 45.001
convener: prefers to have this separate
| revised | No | R6‑160077 | |||
| R6‑160077 | Clarification of PEO codepoint usage | Ericsson Inc. | CR | Decision | No |
No
| reserved | No | R6‑160024 | |||
| R6‑160025 | Clarification of PEO codepoint usage | Ericsson Inc. | CR | Decision | Yes |
Yespresented by John DIACHINA (Ericsson)
Nokia: can be explicitly a PEO packet channel request
Ericsson: if we have it for positioning why do we need to call it PEO (better have a generic name); we could also use TS3 and TS4 so there are a number of choices
convener: so extending it to other signalling proposals is the reason for a more generic name
convener: consequences if not approved, source to TSG need to be updated; but we need to have more discussion on the CR
| revised | No | R6‑160080 | |||
| R6‑160080 | Clarification of PEO codepoint usage | Ericsson Inc. | CR | Decision | No |
No
| reserved | No | R6‑160025 | |||
| R6‑160078 | Clarification of PEO codepoint usage | Ericsson | CR | Agreement | No |
No
| reserved | No | ||||
| R6‑160079 | Clarification of PEO codepoint usage | Ericsson | CR | Agreement | No |
No
| reserved | No | ||||
| 5.2 | CIoT_EC_GSM | |||||||||||
| 5.2.1 | Radio aspects | R6‑160010 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Decision | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
MCC: -Core should be used
conclusion: no further comments so only WI code to be corrected
| revised | No | R6‑160065 | |
| R6‑160065 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Decision | No |
No
| reserved | No | R6‑160010 | |||
| R6‑160026 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Approval | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Ericsson: CR is for 45.003 as in the Tdoc request but it is wrong here on the CR cover
Nokia: diagramms pretend that blocks are happening multiple times but some happen actually just once; similar block diagram could be added for RACH;
Ericsson: either figures or text needs correction (modifying text looked more complex) but also other specs may be affected;
Nokia: blind physical layer transmission? to be clarified
Ericsson: could be clarified in the figure
| revised | No | R6‑160066 | |||
| R6‑160066 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Approval | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Noikia: no subclass for blind physical transmission, correct?
Ericsson: there is some text, below M is the number of blind physical transmissions
Nokia: requests corrections for 2 figures including M
| revised | No | R6‑160099 | R6‑160026 | ||
| R6‑160099 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Approval | No |
No
| reserved | No | R6‑160066 | |||
| R6‑160009 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Decision | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
MCC: -Core to be used
convener: first change to eDRX?
MCC: then better have both WI codes listed as otherwise this is not visible in the CR database
| revised | No | R6‑160067 | |||
| R6‑160067 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Decision | No |
No
| reserved | No | R6‑160009 | |||
| R6‑160050 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: thanks for the spec review, 6th modification: phase shift of pi is not really correct, better to add this to 45.004 where the modulation is and have an informative note; SI reading as quickly as possible after change mark would be useful
Nokia: fine to have informative note in 45.004;
Ericsson: there are 2 possible cases where you acquire EC-SI
after offline discussion: Nokia: mobile behaviour should be clarified in 5
convener: here we look more at network aspect, should we have a CR to 44.018 reference to 45.002 for mobile aspect?
Ericsson: supports this or even better: we can move the clarification to 44.018
conclusion: 6th change will be removed, 6th change will be moved to 45.004 (i.e. merged into R6-160072), 6.3.3.4 v) will be removed from this CR and corresponding text will be added in a CR to 44.018 (i.e. merged into R6-160060), -Core in WI code to be added
| revised | No | R6‑160068 | |||
| R6‑160068 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160050 | |||
| R6‑160030 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Approval | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Nokia: 1st modification: include serving cell, bottom of 5th modication needs a clarification; has also CR to 6.9.4: clarification from our CR can be added here;
conclusion: 1st, 3rd and 5th modification need a revision
| revised | No | R6‑160069 | |||
| R6‑160069 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Approval | No |
Noincludes change of section 6.9.4 of R6-160052
| reserved | No | R6‑160030 | |||
| R6‑160052 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: 6.9.4: signal levels should not be removed?
Nokia: correct; note: complete 6.9.4 change will be merged into R6-160069
Ericsson: 6.10.3: informative note: not fully understood what is meant by "matching", is not bullet-proof and name of parameter is not correct
Nokia: would clarify/reword the note
Ericsson: 7th modification: change is not correct as it is now
Nokia: agrees that this should be conditional, so some rewording needed
Ericsson: 8th modification: 2nd line in table: RCC missing, not just NCC+BCC
Nokia: will add RCC
| revised | No | R6‑160070 | |||
| R6‑160070 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160052 | |||
| R6‑160049 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: numbering of synchronisation sequences is a bit strange and should be clarified
Nokia: can do this
| revised | No | R6‑160071 | |||
| R6‑160071 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160049 | |||
| R6‑160051 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
| revised | No | R6‑160072 | |||
| R6‑160072 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
Nowill include 6th change of R6-160050
| reserved | No | R6‑160051 | |||
| R6‑160008 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Decision | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Ericsson: Nokia has a CR on same TS in R6-160047
convener: text in front of the table is unclear for EC operation
Ericsson: Sentence in front of table 6.2-4 can be removed, can be covered in Nokia CR
conclusion: modfication for the sentence above table 6.2-4 will be removed as covered in R6-160074
| revised | No | R6‑160073 | |||
| R6‑160073 | Miscellaneous corrections for EC-GSM-IoT | Ericsson LM | CR | Decision | No |
No
| reserved | No | R6‑160008 | |||
| R6‑160047 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yesmoved from AI 5.2.2 to AI 5.2.1
presented by Srinivasan SELVAGANAPATHY (Nokia)
convener: would suggest to move 7th modification in Ericsson's CR (revision of R6-160008)
Ericsson: prefers to remove the sentence before R6-160008 before table 6.2-4
conclusion: only WI code to be corrected
| revised | No | R6‑160074 | |||
| R6‑160074 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160047 | |||
| R6‑160053 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: section 4: " was removed, should not be the case
Ericsson: not sure as T3 = T3", will check offline
conclusion: change to remove " is ok
Ericsson: 6.11.1 2nd bullet: should be spelled out
Nokia: bullet was just moved
Ericsson: "EC packet control acknowledgement" is better than "blind physical layer transmissions"
convener: CC1 case only in first bullet
Ericsson: there is no case where CC1 is using blind physical layer transmission, so remove CC1 from first bullet
conclusion: will replace 4 times "in CC1 not using blind physical layer transmissions" into "not using blind physical layer transmissions (CC1)"
Ericsson: to 6.4, 3rd paragraph: whole paragraph needs to be updated to get it correct
convener: support level does not mean it has to use integral timeslot level
conclusion: changes of 2nd and 3rd paragraph planned and to be aligned with 5.7
| revised | No | R6‑160075 | |||
| R6‑160075 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160053 | |||
| 5.2.2 | Performance aspects | R6‑160002 | CR 45.005 - EC-GSM-IoT UE Rx performance requirements | MediaTek Inc. | CR | Approval | Yes |
Yes
| revised | No | R6‑160082 | |
| R6‑160082 | CR 45.005 - EC-GSM-IoT UE Rx performance requirements | MediaTek Inc., Intel | CR | Approval | Yes |
Yespresented by Jukka VAYRINEN (Mediatek)
Ericsson: figures are in [ ] as for the BS side, when is it planned to remove them?
Mediatek: at next RAN6 meeting in Nov.
| agreed | No | R6‑160002 | |||
| R6‑160013 | Incremental redundancy requirement for EC-GSM-IoT | Ericsson LM | discussion | Discussion | Yes |
YesProposal 1: Remove the IR requirement for MCS-1/16
Proposal 2: Apply the EGPRS MCS-9 requirement also for EC-GSM-IoT MCS-9
Proposal 3: Define the EC-GSM-IoT GMSK requirement at -111 dBm signal level, at a 6 kbps/TS throughput target
presented by Marten SUNDBERG (Ericsson)
Nokia: idle blocks also considered as time in throughput calculation?
Ericsson: assumes they are excluded in the calculation
Nokia: simulated or measured results in the diagram
Ericsson: fig.1 is simulated performance, suggests to include the fig. in brackets until we have feedback from mobile vendors
Nokia: statement above fig.1: input level?
Ericsson: you are correct, signal level, was converted so we could not put it in the figure
conclusion: proposals 1, 2, 3 are agreed
| noted | No | ||||
| R6‑160014 | Incremental redundancy requirement for EC-GSM-IoT | Ericsson LM | CR | Decision | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Ericsson: includes the changes proposed in R6-160013
convener: only WI code on CR cover needs to be corrected to add -Perf, we can revise it but do not need to see the revision again
| revised | No | R6‑160093 | |||
| R6‑160093 | Incremental redundancy requirement for EC-GSM-IoT | Ericsson LM | CR | Decision | No |
Yes
| agreed | No | R6‑160014 | |||
| R6‑160027 | Normalized coherency error requirements for EC-GSM-IoT MS | Ericsson LM | discussion | Discussion | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Nokia: any reason to limit the sequence of concurrent bursts? will it be tighter for the MS?
Ericsson: if not over consecutive it would lead to different requirements; 45.005 has the reuirements that bursts have to be consecutive so we tried to clarify this in a CR; so yes, consecutive was assumed
Ericsson: agrees that drift over 4 timeslots may change, but requirement should be ok to check the behaviour we want to check
Nokia: some feedback from MS vendors would be good
convener: is annex in 45.005 really clear?
Ericsson: can clarify this in connection with the CR R6-160028
| noted | No | ||||
| R6‑160028 | Normalized coherency error requirements for EC-GSM-IoT MS | Ericsson LM | CR | Approval | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Nokia: some clarifications in last modified sentence needed;
Ericsson: considers the requirements to be core requirements and how it is tested is up to RAN5
Nokia: we should at least add "uniform" or "of same length"
Ericsson: yes, can add something like this
convener: prior discussion with MS vendors?
Ericsson: synchronizing in frequency within 90Hz, 0 Hz offset and 20Hz standard deviation needs to be verified (how well can you synchronize)
but agreeing the CRs and leaving the values in [ ] is ok to allow for checking until the next meeting
| revised | No | R6‑160094 | |||
| R6‑160094 | Normalized coherency error requirements for EC-GSM-IoT MS | Ericsson LM | CR | Approval | No |
No
| reserved | No | R6‑160028 | |||
| R6‑160015 | BTS interference performance requirements for EC-GSM-IoT | Ericsson LM, Nokia | CR | Decision | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Ericsson: some values need to be updated
convener: WI code has to include -Perf
| revised | No | R6‑160095 | |||
| R6‑160095 | BTS interference performance requirements for EC-GSM-IoT | Ericsson LM, Nokia | CR | Decision | No |
No
| reserved | No | R6‑160015 | |||
| R6‑160016 | BTS sensitivity performance requirements for EC-GSM-IoT | Ericsson LM, Nokia | CR | Decision | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
convener: WI code has to include -Perf
Ericsson: some editorial updates of dB formats can be done in next revision but does not change requirements
| revised | No | R6‑160096 | |||
| R6‑160096 | BTS sensitivity performance requirements for EC-GSM-IoT | Ericsson LM, Nokia | CR | Decision | No |
No
| reserved | No | R6‑160016 | |||
| R6‑160029 | BTS sensitivity performance requirements for Overlaid CDMA | Ericsson LM | CR | Approval | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Nokia: expects some Nokia results by Friday so would like to keep final decision open until then
convener: also WI code should be changed
| revised | No | R6‑160097 | |||
| R6‑160097 | BTS sensitivity performance requirements for Overlaid CDMA | Ericsson LM | CR | Approval | No |
No
| reserved | No | R6‑160029 | |||
| R6‑160048 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: 6.3.2 subbullet 2 is applicable more general than indicated here
Nokia: ii) includes also the power measurement, on the 4 time slots the power has to be set (if more slots then they need to have the same power);
Ericsson: "timeslot rythm" should be replaced, "or listed in other tables" is not clear
Nokia: not only 45.005 but also others need be cleaned up (like 55.021)
Ericsson: suggests to leave out "relative to the co-channel interference ratio (C/Ic) or listed in other tables" as the reference to table 7.5-3 is clear
Ericsson: reason for "Further time slots may be active but shall not use TSC 0 from TSC set 1" in 6.3.2 is unclear
Nokia: no combining is done
Ericsson: unnecessary normative requirement, has no impact on the test
Nokia: will check internally
| revised | No | R6‑160098 | |||
| R6‑160098 | Corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160048 | |||
| 5.2.3 | Protocol aspects | R6‑160019 | 44.014 Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yesmoved from AI 5.2 to AI 5.2.3; presented by John DIACHINA (Ericsson);
Nokia: there can be also gaps
Ericsson: we could drop the "consecutive"
Nokia: consequences if not approved has a typo
Ericsson: can be fixed
convener: source to TSG should be R6
44.014 as Core or Perf spec?
Ericsson: is more related to mobile conformance testing
convener: agrees there are no Perf. figures, we can keep it under Core part
| revised | No | R6‑160056 | |
| R6‑160056 | 44.014 Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yespresented by John DIACHINA (Ericsson)
| agreed | No | R6‑160019 | |||
| R6‑160020 | Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yesmoved from AI 5.2 to AI 5.2.3; presented by John DIACHINA (Ericsson)
MCC: should say -Core in WI code and instead of R6.2 use R6
Ericsson: instead of PG1 it should have PG with superscript 1 but the formatting change is not visible
convener: 3.3.1.2: text should be in italics or in primes?
Ericsson: tried to follow 24.008 but can double-check
convener: remove one "to", should say just "is set to" (problem occurs in multiple places)
Nokia: 3.5.1a.1: "last reported" correct? means last reported to core network or expected DL coverage class?
Ericsson: last reported in UL unit data
Nokia: "last reported to core network" would be clear but not sure whether core network is intended here; or also possible "last selected"
convener: what is the ambiguity that we see here?
Ericsson: BSS may overwrite what MS considered and then "last reported" may not be so clear/relevant
Qualcomm: thinks that sentence is ok, MS can not do anything if BSS does something else
Ericsson: "last reported in a system access" would probably be better
after offline discussion: Ericsson: we will clarify that "last reported" is related to what MS reports (i,e EC-packet channel request message)
Nokia: "selected DL coverage class"
Ericsson: but network may assign something else than what mobile selects
Nokia: is "selected" the final one?
Ericsson: yes
| revised | No | R6‑160057 | |||
| R6‑160057 | Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yespresented by John DIACHINA (Ericsson)
convener: no RAN ticked?, needs a revision but we do not need to see it again
| revised | No | R6‑160100 | R6‑160020 | ||
| R6‑160100 | Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yes
| agreed | No | R6‑160057 | |||
| R6‑160021 | Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yesmoved from AI 5.2 to AI 5.2.3; presented by John DIACHINA (Ericsson)
convener: -Core missing in WI code, R6.2 => R6, some spaces missing in CR text
Qualcomm: 2nd sentence confusing: transmission in DL?
Ericsson: yes, as we talk about DL coverage class; but fine to rephrase
Qualcomm: needs to be corrected in 2 places
| revised | No | R6‑160058 | |||
| R6‑160058 | Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yespresented by John DIACHINA (Ericsson)
| agreed | No | R6‑160021 | |||
| R6‑160022 | Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yesmoved from AI 5.2 to AI 5.2.3; presented by John DIACHINA (Ericsson)
convener: -Core missing in WI code, R6.2 => R6
Nokia: cat.D?
MCC: please make sure the change is visible
| revised | No | R6‑160059 | |||
| R6‑160059 | Miscellaneous EC-GSM-IoT Changes | Ericsson Inc. | CR | Decision | Yes |
Yespresented by John DIACHINA (Ericsson)
convener: any reason why not ticking ME?
Ericsson: as this is for GNSS
| agreed | No | R6‑160022 | |||
| R6‑160003 | Updates of the naming convention from EC-EGPRS to EC-GSM-IoT | CATR | CR | Yes |
Yespresented by Yuan DONG (CATR)
Ericsson: this CR is completely included in R6-160020
conclusion: CR was merged into R6-160020
| merged | No | |||||
| R6‑160037 | Miscellaneous corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Deepak PRABHU KANLUR (Nokia)
Ericsson: changes to table Table 3.5.1a.1 not needed as covered in R6-160020;
Nokia: ok, will be removed
convener: use WI code -Core
| revised | No | R6‑160060 | |||
| R6‑160060 | Miscellaneous corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
Nowill also include a change from R6-160050
| reserved | No | R6‑160037 | |||
| R6‑160038 | Miscellaneous corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Deepak PRABHU KANLUR (Nokia)
convener: use WI code -Core
Ericsson: 2nd sentence in defintion: should better say "EC-TBF uses"; TB-flow identity: under5.2.2 better remove "concurrently"; table change unclear
Nokia: fine with definition change; agrees to remove "concurrently" but we talk about one mobile
convener: agrees that for same mobile "concurrent" is unclear
Qualcomm: same value possible for different mobiles but only one will react; so "concurrent" is needed;
Ericsson: we could add one additional sentence: "EC-devices do not support concurrent TBFs"
convener: we do not need to have (E)GPRS and EC-GSM-IoT in the same sentence, i.e. we could have an extra sentence for EC-GSM-IoT
Qualcomm: or just clarify that last part of sentence is different for EC-GSM-IoT
| revised | No | R6‑160061 | |||
| R6‑160061 | Miscellaneous corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160038 | |||
| R6‑160039 | Miscellaneous corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | Yes |
Yespresented by Deepak PRABHU KANLUR (Nokia)
Ericsson: maybe better split 2nd bullet in 6.2 into 2 bullets; 7.1a.1 & 7.1a.3 c change: clear from the title so not really needed;
Qualcomm: 6.2: change linked to UL TBF mode
convener: for 2nd change in 7.1a.1 we wanted to clarify this
Ericsson: worried to that addtiional text can cause additional confusion
conclusion: first change will be modified, changes in 7.1a.1 & 7.1a.3 not needed
| revised | No | R6‑160062 | |||
| R6‑160062 | Miscellaneous corrections to EC-GSM-IoT | Nokia Networks | CR | Decision | No |
No
| reserved | No | R6‑160039 | |||
| R6‑160040 | Uplink Transmission Opportunities indicated in FUA | Nokia Networks | discussion | discussion | Yes |
Yespresented by Deepak PRABHU KANLUR (Nokia)
proposal: to agree the accompanying CR to 44.018 [R6-160041] in order to increase Start First UL Data Block, indicating transmission opportunities, to 6 bits, else there are chances that some UL opportunities remain unused and hence transmission efficiency being degraded
Ericsson: nothing precluded, does not mean blocks cannot be used because initially they are not used; we should not eat up more bits (than 4 bits); 300ms/600ms/900ms scheduling distance in the future enough
Nokia: did not get what's the problem with 2 bits additional;
Ericsson: 80 bits of 88 will be used, so 8 bits left to use which is not much; if we use 6 bits it would restrict the scheduling
Nokia: we are just highlighting that a few UL ooportunities may not be used
convener: initial calls are occuring, solvable by network by different scheduling; scheduling of subsequent blocks an issue; 6 bits would allow already allocating for further blocks; 300ms/600ms/900ms latency sufficient?
CC3 and CC4 will miss even further transmission opportunities than indicated in the Tdoc for CC2?
Ericsson: for CC2/CC3/CC4 we have 12 bits to play with, so adding 1 bit more may be enough (i.e. 5 bits instead of 6 bits);
Ericsson: still not sure what we try to solve; just intial transmission affected; not convinced there is a real problem in reality;
convener: so are we ok with the current situation or is there agreement that we should improve it?
Nokia: would be ok with an extra 1 bit as Ericsson indicated
Ericsson: wasn't a proposal from us to go for 5 bits but we would be safe with this 1 extra bit
Ericsson: we do not want to waste network capacity, but this is not the case
convener: if number of scheduled blocks for UL would be affected by going from 4 to 5 bits, this would be a clear drawback but it seems we are not sure about this;
Ericsson: maybe Nokia could analyze the consequences of going from 4 to 5 bits?
convener: since the feature is completed, essential corrections are considered only, so far not clear that the change is essential (as network may be able solve it); but let's still have a short look at CR R6-160041
| noted | No | ||||
| R6‑160041 | Start First UL data Block coding bit | Nokia Networks | CR | Decision | Yes |
Yespresented by Deepak PRABHU KANLUR (Nokia)
convener: if Nokia can bring more justification for this change then we can come back to it otherwise the CR is postponed or rejected
| postponed | No | ||||
| 5.3 | CSPS_Coord_GERAN | R6‑160007 | Correction to CSPS coordination in shared networks | Ericsson LM | CR | Agreement | Yes |
Yespresented by Nicklas JOHANSSON
convener: source to TSG should be R6 instead of RAN6? But this is probably a minor issue.
| agreed | No | ||
| 5.4 | Any other documents related to Rel-13 or earlier features | |||||||||||
| 6 | Work related to Rel-14 | |||||||||||
| 6.1 | Positioning enhancements for GERAN (work item ePOS_GERAN) | R6‑160018 | Multilateration Signaling Procedures | Ericsson Inc. | discussion | Discussion | Yes |
Yesproposal: The intent is to identify if one or both of the alternatives is the preferred way forward and proceed with stage 3 work accordingly.
presented by John DIACHINA (Ericsson)
Nokia: with normal burst only possible for shorter distance, multiple training sequences needed for each coverage class?;
Nokia: alt.1 has less transmissions than alt.2
Ericsson: in alt.2 the UE is autonomous
convener: reason for using this TOM protocol
Ericsson: for integrity protection & cyphering; there is nothing new with this protocol; fig.1 is not yet triggering TOM; TOM kicks in in fig.2
Nokia: measurement report needs to be secured; security is more for measurements of neighbour cells
convener: step 2 unclear with the FFS statement
convener: it would be good to summarize the working assumptions in a document, further offline discussion needed (e.g. existing protocols can be used or additions to RLP needed)
| revised | No | R6‑160081 | |
| R6‑160081 | Multilateration Signaling Procedures | Ericsson Inc. | discussion | Discussion | No |
No
| reserved | No | R6‑160018 | |||
| R6‑160006 | Multilateration Energy Consumption Analysis | Ericsson LM | discussion | Discussion | Yes |
YesTdoc cllaims that it has been shown that:
- from an energy efficiency point of view that the MS autonomous method is always better than the NW assisted method for Multilateration
- the energy to perform a positioning with the proposed methods is on acceptable levels. Both methods are recommended for further studies and specification work
- procedure to collect the Timing Advance values would benefit from additional optimizations to decrease the energy consumption.
presented by Nicklas JOHANSSON (Ericsson)
Nokia: energy consumption considers only normal coverage, for extended coverage higher consumption can be expected
Nokia: consider also one case in CC2 as well for a fair comparison
Ericsson: we could consider 2 cases one in normal coverage and one cell in CC2; we should have some assumptions now on energy consumption so we could update our paper
| revised | No | R6‑160083 | |||
| R6‑160083 | Multilateration Energy Consumption Analysis | Ericsson LM | discussion | Discussion | No |
No
| reserved | No | R6‑160006 | |||
| R6‑160034 | Radio Interface Enhancements for TA based multilateration | Nokia Networks | discussion | Discussion | Yes |
Yes
| revised | No | R6‑160054 | |||
| R6‑160054 | Radio Interface Enhancements for TA based multilateration | Nokia Networks | discussion | Discussion | Yes |
YesProposal: One code point of EC-NumberOfBlocks can be used to differentiate EC or PEO access request so that the spare bit can be used as access discriminator to differentiate further use of access burst from channel request.
presented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: security issue as data exchanged in clear text?
Nokia: some enhancement is possible; whenevever BSS receives paging request it assigns identifier for further commands
Ericsson: mapping of the identifiers to radio resource identifiers is not clear
Nokia: BSS maintains binding between TLLI and short identifier
Ericsson: we are interested to do this procedure and we are discussing fine radio details so we need to see what we want to report back to RAN
MCC: you WI has a 3 months study phase with a number of objectives, how do you plan to document the results (as there is no TR for it)?
Ericsson: will summarize the results in the status report to RAN #73
convener: Is the proposal agreeable?
Ericsson: overlaps completely with the PEO discussion we sent to offline discussion before so we better come back to it later
| revised | No | R6‑160085 | R6‑160034 | ||
| R6‑160085 | Radio Interface Enhancements for TA based multilateration | Nokia Networks | discussion | Discussion | No |
No
| reserved | No | R6‑160054 | |||
| R6‑160035 | Energy efficient hybrid TA/OTD multilateration for neighbour cells in extended coverage | Nokia Networks | discussion | Discussion | Yes |
Yesproposals:
1. For moving MSs, a lower positioning accuracy than achievable with 3 TA values is acceptable if the energy consumption per positioning can be considerably reduced.
2. The MS should use a resolution of 1/8 normal symbol period or better for the time synchronization to the network and the reporting of the observed time differences.
3. The MS' neighbour cell measurement report for the TA multilateration shall include, in addition to Rx levels, OTD values for a configurable number of neighbour cells.
presented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: interesting solution to serve energy, concern is that when positioning needs to be done data is out-of-date, so the network is triggering a lot of measurements to have up-to-date information
Nokia: is a possibility of enhancement of the current procedures using existing real-time measurements
Ericsson: procedure looks more complicated for the network, also for rather stationary MSs multilateration would be used, may have negative impact on other measurement requests, critical is that there is no information from UE manufacturers which accuracy is achievable (8 times oversampling would be reuired)
Ericsson: assumed that system level simulations are required to determine the possible positioning accuracy (but WID does not explicitly requested this)
convener: having just one WG for an evaluation does not allow multiple simulation iterations, more feedback from device manufacturers for this proposal is certainly a justified comment
Ericsson: cannot agree to proposal 2 and 3, for proposal 1 "for moving MSs a lower accuracy is acceptable" would be ok for us
Orange: primary goal of this WI was anyway not really moving targets, so localizing at a certain was intended
convener: no consensus so far on the 3 proposals (further feedback from vendors needed)
Ericsson: on this WI we will prepare a summary of all agreements and a workplan that can then be reviewed by this meeting end of this week and could be reused for the WI status report
MCC: please prepare this summary in R6-160084
conclusion: The following sentence was agreed:
Evaluation for positioning accuracy shall focus on stationary devices, for moving MSs lower positioning accuracy can be accepted.
| noted | No | ||||
| R6‑160036 | Energy Consumption Analysis of Radio Interface Procedures for Positioning Enhancements | Nokia Networks | discussion | Discussion | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: fig.1: worried that network may not trigger anything
Nokia: it says "current mobile" so not on other mobiles
Ericsson: how often do you have OTD measurements available? if not enough you will have to trigger them and we are worried you will have to trigger a lot of measurements to have OTD data available
Ericsson: what does green highlights in table 1 mean?
Ericsson: paging response in fig.1 missing?
Nokia: we have optimized the proposal here
Ericsson: more RRC paging response?
Nokia: paging response is locally handled in BSS here
convener: update this Tdoc after further offline discussion
| revised | No | R6‑160086 | |||
| R6‑160086 | Energy Consumption Analysis of Radio Interface Procedures for Positioning Enhancements | Nokia Networks | discussion | Discussion | No |
No
| reserved | No | R6‑160036 | |||
| R6‑160084 | Positioning enhancement for GERAN - workplan/agreements | Ericsson | discussion | discussion | No |
No
| reserved | No | ||||
| 6.1.1 | Radio aspects | |||||||||||
| 6.1.2 | Performance aspects | R6‑160011 | Simulations for positioning enhancements – Assumptions | Ericsson LM | discussion | Discussion | Yes |
Yesproposals: The assumptions are:
1. For link and system level simulations, re-use the assumptions from 3GPP TR 45.820 with the limitation/exceptions that:
a. For system simulations:
i. Use building penetration loss model 1 and inter-site correlation coefficient 0.5
ii. No specific traffic model added in the network, but instead a sufficient number of synchronization attempts are performed.
b. For link simulations:
i. Use EPA propagation model
2. The results are presented:
a. With the used positioning method declared
b. With a model presented of the synchronization accuracy assumptions for the MS and BTS
c. With the maximum number of base stations used for positioning declared
d. With the percent of users out of coverage declared
e. As percentile of positioning accuracy of 100 m or better
presented by Marten SUNDBERG (Ericsson)
convener: EPA instead of TU model used before?
Ericsson: during cellular IOT they performed the same so we used TU but TU is a pessimistic urban channel and here it makes a difference for the synchronisation accuracy; for shorter channels they would behave the same but it was shown that TU is not a typical case (although TU stands for typical urban)
conclusions: Assumptions under 1. and 2. are agreed; Tdoc is revised to correct a delay spread value error
| revised | No | R6‑160087 | |
| R6‑160087 | Simulations for positioning enhancements – Assumptions | Ericsson LM | discussion | Discussion | No |
No
| reserved | No | R6‑160011 | |||
| R6‑160012 | System level simulations for positioning enhancements – Methods and Results | Ericsson LM | discussion | Discussion | Yes |
Yespresented by Marten SUNDBERG (Ericsson)
Nokia: impact of delay spread not considered?
Ericsson: SINR was not modelled, SINR dependent system model possible that includes also delay spread, delay spread was taken into account
Ericsson: UE may pick up to three strongest signals which may come from same BS (strongest based on RX level);
convener: fig. 6: it seems it is clear that 1/8 symbol accuracy would be useful to avoid that you need many BSs, was there any discussion with mobile phone manufacturers whether this is achievable?
Ericsson: 1/4 is maybe more realistic than 1/8; there is also the question what soort of oversampling is considered by the BS
| noted | No | ||||
| 6.1.3 | Protocol aspects | |||||||||||
| 6.2 | Dedicated core networks for GERAN (work item DECOR-GERAN) | R6‑160017 | DECOR - Way forward | Ericsson Inc. | discussion | Discussion | Yes |
Yespresented by John DIACHINA (Ericsson)
Nokia: subbullet 2 and 3 should be a consequence of bullet 1
Nokia: would you loop?
Ericsson: you may loop several times until you find an SGSN that can accept but this should not be the normal case
Nokia: "• The rerouting procedure needs to be updated to support Rel-13 DECOR."?
convener: conclusion is a bit confusing, stage 2 is in REL-13 and we are providing GERAN stage 3 here
Ericsson: agrees that it should better say "GERAN REL-14 support for Rel-13 DECOR"; another editorial to be fixed;
convener: so the proposal is then "Proceed with implementing GERAN REL-14 support for Rel-13 DECOR as described in section 3."
conclusion: This way forward is agreed, Tdoc will be updated in R6-160089
| revised | No | R6‑160089 | |
| R6‑160089 | DECOR - Way forward | Ericsson Inc. | discussion | Discussion | No |
No
| reserved | No | R6‑160017 | |||
| R6‑160005 | Introduction of Dedicated Core Networks in GERAN | Ericsson LM | CR | Agreement | Yes |
Yespresented by Nicklas JOHANSSON (Ericsson)
Nokia: "UE usage type" is just SGSN only, why does it need to go from one SGSN to anotherSGSN; typos in 6.6.2 (needs some rephrasing), table 11.3.133, table 11.3.131 (linking of tables was not possible)
convener: if only one bit is used, others should be spare
convener: typo in 3.1: DCN-ID
Ericsson: but this will be removed
convener: some other typos (blanks)
| revised | No | R6‑160090 | |||
| R6‑160090 | Introduction of Dedicated Core Networks in GERAN | Ericsson LM | CR | Agreement | No |
No
| reserved | No | R6‑160005 | |||
| 6.3 | Small technical enhancements and improvements (work item TEI) | |||||||||||
| 6.4 | Downlink MIMO for GERAN (study item DOMIMO) | R6‑160042 | pCR 45.871 Downlink MIMO – Mode and Link Adaptation | Nokia Networks | pCR | Decision | Yes |
Yespresented by Juergen HOFMANN (Nokia)
no comments
| agreed | No | ||
| R6‑160043 | pCR 45.871 Downlink MIMO – Signalling | Nokia Networks | pCR | Decision | Yes |
Yespresented by Juergen HOFMANN (Nokia)
no comments
| agreed | No | ||||
| R6‑160044 | Compatibility Analysis of Downlink MIMO for GERAN | Nokia Networks | discussion | discussion | Yes |
Yesfrom the Tdoc: "It is observed from the simulation results above that the performance of legacy speech and data channels can be degraded by about 0.4 dB on average when exposed to 2x2 DL MIMO interference. However, in a practical network, the likelihood of experiencing only MIMO interference is very low. It is expected that the legacy speech channels will experience a mixture of MIMO and non-MIMO type interferences and hence the overall negative impact is judged to be rather limited."
presented by Juergen HOFMANN (Nokia)
no comments
| noted | No | ||||
| R6‑160045 | pCR 45.871 Downlink MIMO – Compatibility Analysis | Nokia Networks | pCR | Decision | Yes |
Yespresented by Juergen HOFMANN (Nokia)
no comments
| agreed | No | ||||
| R6‑160046 | pCR 45.871 Downlink MIMO – Conclusion | Nokia Networks | pCR | Decision | Yes |
Yespresented by Juergen HOFMANN (Nokia)
no comments
| agreed | No | ||||
| R6‑160091 | TR 45.871 v1.1.0 on | Nokia Networks | draft TR | Agreement | No |
Nonote: It is intended to provide this TR 45.871 to RAN #73 for approval.
| reserved | No | ||||
| 6.5 | Any other Rel-14 documents | R6‑160031 | Alternative mappings for EC-GSM-IoT higher coverage classes | Nokia Networks | discussion | Discussion | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: how would BS know that it is a REL-13/REL-14 channel request?
Nokia: has 2 approaches (1 needs additional bit, other not)
Ericsson: with the bit you still do not know whether it is REL-13 or REL-14
Nokia: CC1 can still be allocated to REL-13 mobiles
Ericsson: DL coverage class: primarily used for CC1, legacy ECC1 mobile will not be able to read it?
Nokia: if it skips reading it would have an impact (causing inefficiency in sleeping) but normal operation would not be impacted
Orange: proposal is addressing a real problem but with time this constraint may be less stronger on the other hand, there is a risk of over-complication; there are probably also other solutions that are less complicated
convener: will be further discussed also in connection with the planned new WI
| noted | No | ||
| R6‑160032 | EC-GSM-IoT New Channel Formats for Short Packets with NIDD CN | Nokia Networks | discussion | Discussion | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: initial assumptions on the stack seem to be different now
Nokia: we assume only application payload alone needs to be transported so we can get rid of overheads
Ericsson: reads that it is tightly linked to UDP so we cannot skip it without modifying it
convener: this document will be also part of the new WI proposal
Ericsson: any feedback from MS vendors on this one or the alternative coverage class
Nokia: on this one we are in discussions with MS vendors, on the other one (R6-160031) we have positive feedback
| noted | No | ||||
| R6‑160033 | New WID on Radio Interface Enhancements for EC-GSM-IoT | Nokia Networks | WID new | Agreement | Yes |
Yespresented by Srinivasan SELVAGANAPATHY (Nokia)
Ericsson: quite some work
Ericsson: same mechanism but transmitted block shorter?
MCC: WI code needs to be updated and 4 supporters needed
Sierra Wireless: time budget needed
Sierra Wireless: on the paper it looks good but with so few people to finish this in 6 months is probably too tight so reducing the scope would useful
Nokia: some complexity reduction may be possible (single-slot for CC3 does not require multi-slot)
Sierra Wireless: also Core network impact? box is not ticked
Nokia: unclear whether it needs to be ticked
Nokia: actually there is a REL-14 WI on core network already which we can link
Ericsson: simulations needed?
Nokia: adding "MCL improvement target of at least 3dB"
Ericsson: any input to justify this value?
Nokia: could provide some information
Ericsson: putting additional restriction on alternative mapping, is ok to have a mapping that does not fulfill this requirement as long as we have a mapping that allows the mapping
Ericsson: if both options are kept, combinations increase quite quickly
Nokia: shorter radio block improvements are less mature, so it is possible to consider this in a later WI
| revised | No | R6‑160092 | |||
| R6‑160092 | New WID on Radio Interface Enhancements for EC-GSM-IoT | Nokia Networks | WID new | Agreement | No |
No
| reserved | No | R6‑160033 | |||
| 7 | Any other technical work | |||||||||||
| 8 | Liaison and output to other groups | |||||||||||
| 9 | Revision of the work plan | |||||||||||
| 10 | Future meetings | |||||||||||
| 11 | Any other business | |||||||||||
| 12 | Close of the meeting (no later than Friday, 5.30 p.m.) |