NB-IOT Notes

NB-IOT Notes 3GPP TSG-RAN WG2 Meeting #92 DRAFT_R2-157014 Anaheim, USA, 16th – 20th November 2015 Agenda Item: 13.3.4 Source: Mediatek Inc. (Session Chair) Title: Report of the LTE breakout session (NB-IoT) Document for: Approval 7.16 WI: Narrowband IOT (NB_IOT-Core; leading WG: RAN1; REL-13; started: Sep. 15; target: Mar. 16; WID: RP-151621) Time budget: N/A Overall: The mindset should be that Requirements in TR 45.820 shall be fulfilled. Please note that high level proposals are difficult to treat, e.g. “do the same as eMTC”, “do the same as eDRX”, “do the same as in 45.820”, “do the same as in LTE”. For such proposals, please also explain in more detail what the proposal means. 7.16.1 General Organization, Requirements, Overall CP/UP aspects, Running Stage-2 CR incl outcome of email disc 91bis#07, Coverage levels incl outcome of email disc 91bis#48, whether to reuse LTE stage-3 specifications or not, other. Incoming LS R2-156027 LS on Agreements on CIoT architecture for NB-IOT (S2-153695; contact: Intel) SA2 LS in to: RAN2 Rel-13 FS_AE_CioT - Docomo would like to clarify what is the meaning of mandatory for the network. Nokia wonders if it means that we need to upgrade the networks. - Vodafone think the meaning is as for UE. Point is that we should support the control plane solution. Vodafone thinks that we don’t need the UP solution in Rel-13. - Ericsson thinks that we specify the UE behaviour as usual and that is it. - ZTE thinks it doesn’t imply priority. We need to specify both solutions. Ericsson agrees. - LG think optionality is only for UE. , We aim to specify both solutions in Rel-13. This can be revisited at RP. , Optional mandatory refers to the UE from RAN2 specifications point of view. R2-156873 LS on new security work item for NB-IoT (S3-152582; contact: Vodafone) SA3 LS in to: RAN2 Rel-13 , Noted Running Stage-2 CR for information from last meeting R2-155007 Running 36.300 CR to capture agreements on NB-IoT Huawei DraftCR 36.300 Coverage level change R2-156755 Report of the email discussion [91bis#48][NB-IOT] Coverage level Huawei Tech.(UK) Co., Ltd report P1: - Nokia thinks that indication is not needed, but this is part of UE RACH resource selection. - Qualcomm think that we need to wait for physical layer design to be specific. 1 / 15 P2: - Whether S1 context release can be used depends on UP or CP solution. P4 - Intel think that option B is sufficient and that this is consistent with email discussion. Mediatek and Ericsson agrees. QC think that the UE should have the option to update coverage level. - Vodafone think that maybe we should keep it a bit open what happens when UE changes cell belonging to different eNBs. - Ericsson think that mobility is even less for NB-IOT than for eMTC. - Huawei points out that according to the GERAN study there are power consumption benefits with updating coverage level. Agreements 1: RAN node can determine the UE’s coverage level from random access procedure. How this is done depends on RACH design of physical layer. 2: The original eMTC design, e.g. by using S1 Context Release message to indicate coverage level can be used as the baseline, at least for the UP solution. 3: CN may include coverage enhancement (CE) level information, Global Cell Id and Paging Attempt Count IE in Paging message to indicate related information to RAN node. , CB: Potential agreement, For UE in idle mode, UE do not make specific access only to report coverage level change. Other R2-156131 Scheduling considerationsGemalto N.V. discussion - Intel has some sympathy for these proposals. Intel would like to optimize for fixed location. Ericsson agrees, and would not like to optimize for the scheduling part. Vodafone think this requires study, and would be better considered for rel-14. This was not considered in the GERAN study. Mediatek also do not see clear benefits for the scheduling optimization. - Intel would like to look at this for rel-13. LG is not interested in this. - Chair points out that keeping UE in connected mode for long times is not part of any of the agreed SA2 solutions. - Not enough support for rel-13. , Noted R2-156426 NB-IoT UE capability profile NTT DOCOMO INC. discussion - Vodafone think that NB-IOT devices are specifically low cost devices. Docomo thinks there are benefits in reusing what we have today from functionality perspective. - Samsung wonders what the use case for the different capabilities is. Docomo think that the use cases for NB-IOT is currently very narrow and think that they will increase. QC points out that NB-IOT use cases are limited by the limited bandwidth. Huawei don’t think that two profiles are needed in this release. - Docomo want to address more use cases. , Noted 7.16.2 Control Plane 7.16.2.1 Radio Resource Control - RRC Access Control, Need for RRC connection re-establishment, Need for redirection, Applicability of RRC connection reconfiguration, signalling enhancements in the S1 architecture, other Access Control R2-156385 Access control for roaming UEs in NB-IOT TeliaSonera AB discussion moved from 7.16.1 to 7.16.2.1 - Samsung wonders why we need to discriminate. - TS explains that roaming may happen due to a competitor network having problems, i.e. abnormal cases. 2 / 15 - Nokia think we should have the same support as in EAB wrt roaming UEs. - Vodafone point out that we need traffic priorities, e.g. three different priorities, in the access control mechanism. CMCC agrees, and think that NB-IOT , The access control mechanism for NB-IOT shall be able to discriminate between different roaming UEs, i.e. the same roaming differentiation as for EAB. R2-156136 Access control for NB-IoT Ericsson discussion moved from 7.16.2.3 to 7.16.2.1 - Neul wonders if the proposal is based on the assumption that value tag is in the MIB or SIB1. Neul then wonders how the UE knows that barring is ongoing. Ericsson think there is a bit in SIB1 telling if barring is ongoing. - Intel wonders if this is EAB except for the notification. Ericsson confirms. - Docomo wonders how this applied to access classes. Docomo understands that barring shall be applicable for Access classes as today. Ericsson agrees. One bit represents one AC. - How to handle MO signalling? Ericsson did not go into this detail. R2-156315 Analysis of NB-IOT access control mechanism China Mobile Com. Corporation discussion Updated in R2-156867 R2-156867 Analysis of NB-IOT access control mechanism China Mobile Com. Corporation discussion - LG point out that ACDC can be used with bitmap approach too. - CMCC think this is future proof. - Ericsson wonders how the categories are configured. LG clarifies that this is supported by CT1. - Docomo wonders whether this is required. ZTE does not think this is required. R2-156521 Access Control in NB-IOT LG Electronics Inc. discussion Barring bitmap per AC, ACDC, LTE-ACB? - Do we need service granularity or not? - CATT supports ACDC. QC points out that ACDC requires more broadcast information, and would not like to introduce it unless needed. - Ericsson point out that for prioritization we only have identified two priorities, not different services so far, also in the GERAN study. - Vodafone think we don’t need ACDC, but that we do need some prioritization. - Ericsson think that ACDC involves handling of application ID etc. Intel points out that with ACB we can discriminate between different classes e.g. signalling data etc. - Huawei think we should keep ACDC as a candidate solution. Ericsson think this would add complexity. - QC think that we need to progress more before sending a LS, as the other groups may not be up to date on NB-IOT. , We need some priority discrimination , We assume that the priority discrimination classes can be hard-coded in the specification, normal reporting, high-priority/alarm/exception report. This need to be provided by NAS. The final classes are FFS. , CB: offline discussion on details, way forward (LG) Barring bitmap (e.g. per AC), random draw LTE-ACB - Nokia, Sony, Vodafone, Intel Ericsson, Neul, QC, Huawei supports barring bitmap , We use barring bitmap , We assume that NB-IOT doesn’t support SSAC and ACB-skip. Details - Neul think that value tag is updated when barring information is used. Ericsson clarifies that the intention is that value tag is only updated when barring is started and stopped, not for modifications. 3 / 15 - Neul wonders why we can’t follow the modification period. Ericsson think that we change the barring bitmap faster than then normal modification period allows. Intel are not sure this is needed. - Ericsson clarifies that it is indicated in SIB1 that this barring SIB is transmitted, and then the UE has to check it. - Intel has concerns on the power consumption for reading of SIBs and would like to check. - CATT think that UEs will be paged before any change of access control and this will spread the load. QC wonders whether the intention is to page every UE in the Cell. Chair points out that we may have paging cycles of 1h. Nokia supports the Ericsson proposal to not use paging. LG think this will depend on the mechanism to inform the UE on the barring change. - Docomo think that we need further work to identify which establishment causes we need. - Vodafone think we have a third priority class, this can be addressed later if needed. - Huawei point out that exception reporting has a time requirement of 10s. , The barring bitmap is transmitted separately from other system information and only when access control is enabled. , It is FFS whether change of bitmap will trigger SI change indication. , It is FFS how to spread the load after un-barring / barring change. , The barring bitmap check is applicable to normal reports. , A separate flag is broadcasted which indicates if exception reports are subject to barring bitmap check or not. Connected Mode Mobility R2-156172 NB-IOT - Measurements in connected mode Ericsson, China Mobile Com. Corporation discussion - Ericsson explains that measurement reporting may depend on indication from the network, e.g. a broadcast indication. - Mediatek wonders if this will impact battery life. Ericsson explains that this is indeed only about reporting measurements that are done in Idle for RRM. - Intel are ok with the UE reporting such measurements, if they are done in Idle mode. - Vodafone don’t think that measurements are needed, and think that measurements cannot be sent unciphered and are thus not applicable to solution 2. Vodafone think that we should not discuss this. - Nokia supports this. Gemalto think that there may or may not be any measurements to report. This may also bring new requirements for security. It need to be clear that this do not bring overhead. Ericsson believes that this do not cause overhead and is best effort. Sony points out that we have the same mechanism in UMTS, and would be ok, but think we should be careful about the size. - CATT are ok with the proposal, but would prefer that they are not reported in separate additional measurement report message. - Docomo support the proposal. - Intel would like to keep agreement general for both solutions. - Vodafone think that the only use case is location. - Samsung think that we need to know more about location technology to be used. - There is significant support, but doubts on the usefulness. No agreement. Proposal 2: - Intel think we don’t know how the physical layer works. Neul agrees. QC think we need a RLF criterion based on own cell quality. , RAN2 assumes that there is at least one RLF criterion , It is FFS if NB-IOT device performs radio link monitoring on the DL to trigger RLF. 4 / 15 Signalling Enhancements TR 23.720 R2-156425 RRC aspects in NB-IoT HTC Corporation discussion R2-156348 General RAN impacts due to SA2 agreements on NB-IOT Intel Corporation discussion - Vodafone wonders if data is treated as signalling in solution 2. Ericsson thinks that NAS-PDU should be MO-data. Intel agrees. - Nokia wonders how it is determined what solution is used. Intel think that this is discussed in SA2. Intel think that until there is a response from the CN the RAN should assume that the solution 2 is used. - Nokia think that eNB should decide which solution to be used. Docomo think that we need to consider the case that a UE connects to legacy network. Neul points out that SA2 agreements is only for NB-IOT. - CATT thinks that for solution 2 there would be a dedicated CN. The eNB need to know before response from CN, in order to select CN node. - Docomo is concerned about the scenario where a NB-IOT UE connects to a legacy LTE network and the NB-IOT UE assumes that solution 2 need to be supported. We postpone this discussion until we get input from SA2. Proposal 3 (HTC) - The intention is only to align with LTE. - Nokia think we might need to segment. We need to establish the connection first and then send the data. Neul think we can already do this. Intel think we can agree this as a baseline. - Nokia does not like to segment RRC connection setup complete and would not like to piggyback NAS message if it is too large. Sony agrees. Ericsson think that we can use MAC multiplexing. CATT think this is not a very big problem. - Sony think that NAS carrying Data could be transferred by UP bearer. - Ericsson thinks that we should limit the solution 2 to small data. Proposal 5 (HTC) - Ericsson think that maybe measuremnts need to be supported and that security may be needed also for solution 2. QC point out that the whole point of solution 2 is to avoid security setup. Nokia proposes to send a LS to SA3. CATT think that SA2 already has discussed this with SA3. QC point out that security activation is clearly not part of solution 2. Proposal 10 (Intel) - LG wonders if same NAS is used for NB-IOT as for LTE. Neul expects that there will be significant differences , For solution 2, a data radio bearer (DRB) is not used in NB-IOT. , As a baseline agreement, At most one NAS signallig message or NAS message carrying small data can be piggybacked in RRCConnectionSetupComplete in the RRC connection establishment procedure for solution 2. , A UL NAS signalling message or UL NAS message carrying small data can be transmitted by a UL RRC container message for solution 2. A DL NAS signaling or DL NAS small data can be transmitted by a DL RRC container message for solution 2. , We assume that AS security is not needed for NB-IoT solution 2. This can be revisited if need for AS security is found. , We assume that for solution 2, there is no need to differentiate between the different data types (i.e. IP, non-IP or SMS) in the AS level. For UP solution, PDCP header compression may be used for IP type traffic. , We assume that for solution 18, a data radio bearer (DRB) is established in NB-IOT. , To take as baseline assumption that LTE UE radio capabilities concept is also applicable for NB-IOT (i.e. UE can share UE radio capabilities upon network request); details FFS. , There is an RRC establishment cause. , We assume that the following values of RRC establishment cause may be applicable for NB-IOT: mt-Access, mo-Signalling, mo-Data,mo-Exception-Data; FFS if different cause values should be used for CP and UP solution. , Draft LS to CT1, SA2, SA3 on NB-IOT progress (Docomo Wuri) 5 / 15 - attaching the running CR, asking for feedback on o RRC establishment causes. R2-156971 Draft LS to CT1, SA2, cc: SA3 on NB-IOT progress NTT Docomo LSout R2-156502 RRC procedures for solution 2 in TR 23.720 Neul Limited discussion - No need to discuss that the Paging procedure is supported for notification of MT call, This is clear from earlier. Proposal 3.4: - Neul clarifies that this proposal refers to RRC connection reject. - ZTE thinks it is too early to decide and it should be revisited when access control is more clear. Ericsson supports the proposal and think that wait time should also be in RRC connection release. - Vodafone thinks there may not be a release message. - Nokia think we may have two wait times, Sony think we should only have one. Proposal 4.1: - Ericsson think that RRC connection reconfiguration might be used. Nokia agrees. - Vodafone think there is nothing to reconfigure, and proposes that this procedure is simply not supported. Qualcomm think we should question every possible overhead. Ericsson think reconfiguration may be needed for control in enhanced coverage. - Gemalto points out that RRC connection reconfiguration may be used at SW update / larger data transfer. - RRC connection reconfiguration is supported for UP solution. Proposal 5.1 - Neul clarifies that we may support both timer and explicit message. - CATT think there is a risk that the timer expires when the UE has data for transmission. - Sony think that it is better to not have a timer, as message is faster. The message based approach is anyway timer based. - Nokia have concerns on how to start the timer, see no benefits, and think it is sufficient to support message. - Ericsson think that the default is a message based release. - Docomo think that this causes complexity. - Vodafone would like to have a system that is optimized and supports this proposal. Vodafone think we don’t have a RRC connection release message at all. - Fujitsu are concered about possible UE network desynch. Intel shares this concern. - Blackberry think we cannot decide now. Gemalto would prefer both message and timer. - Nokia think we have already decided to have the RRC connection release message. - We will revisit this at next meeting, we may go with the majority view. Proposal 5.1 - Nokia wonders if we need UL information transfer. Neul responds that we need this at least for ACK on higher layers. Proposal 6.3 - Sony wonders what mechanism this refers to. Neul think that we don’t need to limit to a specific mechanism. - Chair wonders how reliable such indication need to be. - Ericsson think that we don’t have this interaction between AS and NAS today. - QC think we should wait until we know more about the physical layer. - CATT wonder what is the upper layer. Neul clarifies that upper layer is NAS. QC think that upper layers could be anything. , The RRC Connection is established for small data transfer for solution 2. , There will be a “wait time” in the RRC connection reject. , We assume that RRC connection reconfiguration is not required for short RRC connections for the solution 2 when the connection is used for small data transfer. , It is FFS if RRC connection reconfiguration is needed for solution 2. , It is FFS how RRC connection is released. , DL information transfer and UL information transfer messages are supported to carry small data and carried over SRB1 in solution 2. 6 / 15 Data over NAS - solution 2 R2-156438 NB-IoT small data transmission encapsulated in RRC message Nokia Networks discussion - Already covered , noted R2-156349 Discussion on control plane based solution of data over NAS for NB-IOT Intel Corporation discussion - Ericsson think that eNB should know if there is signalling or data. - Intel think that RRC connection establishment cause is the only means for differentiation. - Docomo wonders if the scheduler needs to differentiate between signalling and data. Intel thinks not. - Nokia think that NAS signalling should have higher priority than data. Intel point out that we only have a single HARQ process so there will not be prioritization in a UE. - QC think it can be handled sequentially. , RRC connection establishment cause can be used for differentiated handling, e.g. of data and signalling, in AS. It is FFS if anything else is needed. R2-156238 RAN aspects of Solution 2 in TR 23.720 CATT discussion - Largely already treated. - Asus think that it is useful for the AS to know the contents, in order to release the RRC connection. - Neul think that optimized RRC connection release is triggered by NAS, but not by AS knowing the contents of NAS message. , noted AS context caching - solution 18 R2-156424 Work on user plane based solution with AS information stored in RAN NTT DOCOMO, INC. discussion R2-156395 RRC Connection Suspend and Resume Ericsson discussion R2-156350 Discussion on user plane based solution of AS context reuse for NB-IOT Intel Corporation discussion - Vodafone wonders what happens when a UE changes eNB in Idle mode. - Docomo think that the main scenario is low mobility. SA2 has discussed this. - Ericsson think that the RRC resume can fail or trigger context fetch. Proposal 1 - Neul comments that the suspend state seems more like connected than Idle state. Ericsson clarifies that this was the agreement from SA2. Main point is that Idle procedures apply. Sony think Neul observation is correct. Intel think that this is indeed an enhanced RRC idle state. Blackberry agrees, but think that there should be a differentiation in the naming. - CATT think we can use L1 procedures instead of RRC procedures, which would give less overhead. Ericsson think that L1 signalling cannot be used for state transitions. Chair points out that the L1 signalling is not reliable. There seems to be very little support for this. - Ericsson confirms that the main difference is in the state transitions and the access. - Chair think we need to be very careful to not introduce new states. We can bring contributions for next meeting if we want to modify this. - Neul like the proposal to have new procedures compared to reuse existing ones, for clarity, - Docomo think we can reuse existing procedures. - Vodafone would like to more clearly define what is the AS context. Ericsson clarifies that tiis basically what we forward at HO prep. Proposal 2 - QC wonders if C-RNTI would be cleared when UE goes to Idle. Ericsson think it is cleared, also when the AS context is retained. Intel think C-RNTI can be used. Docomo think that the resume ID is not needed, because S-TMSI and eNB ID can be used. - QC has concerns on security for sending S-TMSI in clear text. - CATT asks if C-RNTI can be valid if UE changes cell. 7 / 15 - Chair think that over X2, UE context can today be identified by - Ericsson think that C-RNTI values can be exhausted. - Nokia would like to use C-RNTI as it is used also in reestablishment. Proposal 3: - Nokia and Intel think it is too early to agree. - We postpone agreement. Proposal 7 - Ericsson clarifies that DRB may not always be resumed, e.g. for TAU. Docomo and Intel has doubts that this is needed. Proposal 8: - Intel think we should wait until we know better how this procedure works. - Ericsson clarifies that the intentiton is to state that we can do mac multiplexing and have several messages. - Huawei wonders how the eNB could know which TB size to allocate. Chair points out that for LTE there is a method already although it does not allow for vert fine greaned resrouce indication. Proposal 10 - Neul wonders how the eNB could know which TB size to allocate, and if data is ciphered. Ericsson clarifies that the bearer need to be resumed. - Vodafone wonders what would be the cause value. - Qualcomm wonders if the request can fail and then how data can be sent. - Ericsson think that if there is a failure the data will be dropped. Docomo Proposal 2: - Neul think that SA2 is working on this. The chair thinks that the alternative is that all eNBs in an area handled by the CN supports the UP solution. Vodafone assumes that all eNB in a TA would have the same support. Sony support the docomo proposal. Ericsson think that also CP solution-allowed bit should be broadcasted. Nokia think that this can slo be handled in the connection establishment phase. - Intel think we should wait for SA2, until we know more. , Agree that the UE may retain the AS context in RRC_IDLE mode for UP solution. RAN2 assumes that this enhanced RRC_IDLE state is referred to as RRC_IDLE but this may be revisited. , Introduce a RRC Connection Suspend procedure which is used at transition from RRC_CONNECTED to RRC_IDLE state and where the UE stores the AS context; , We assume that at suspend – resume, security is continued. It is FFS how this is done. , Introduce a RRC connection resume procedure which is used at transition from RRC_IDLE to RRC_CONNECTED and where previously stored information in the UE as well as in the eNodeB is utilized to resume the RRC connection. , The RRC suspend procedure and the RRC resume procedure may be new procedures with new messages, or may be implemented as new IEs in existing LTE procedures. This is FFS. , In the message to resume, the UE provides an Identifier to be used by the eNB to access the stored information required to resume the RRC Connection. Identifier FFS , If the resume procedure fails, e.g. if the AS context is not present, we assume that the UE initiates connection setup. It is FFS if this is done in an optimized way or not. , It is FFS if DRB can be multiplexed with connection resume request if the granted transport block size permits. R2-156421 Compatible S1 architecture with eMTC and normal UEs NTT DOCOMO, INC. discussion - Vodafone think this should be discussed in the eMTC session. Neul agrees. - Docomo explains that the reason is that the solutions were initially done for NB-IOT. - Sony point out that this was discussed in RP, and it was not agreed to add it to eMTC, but it could maybe be done in NB-IOT. - Ericsson agrees that it would make sense that this is applicable for other UEs. Ericsson think that UP solution does not require CN updates and is thus suitable to be used by non-NB-IOT UEs. 8 / 15 - Neul point out that NB-IOT should be very optimized and would be connected to a specialized CN. - Docomo would like that we state that there is no technical problem with the proposal. - The chair think that there will be some extra work, and it is not clear how much. Such proposal need to be clarified at RP. , Noted Other R2-156437 RRC connection re-establishment for NB-IoT Nokia Networks discussion R2-156394 RRC Connection Control for NB-IoT Ericsson discussion R2-156547 RRC Connection Control for NB-IoT SAMSUNG Electronics Co., Ltd. discussion late R2-156504 Timer-based connection release Neul Limited discussion R2-156222 RRC Functionality to Support Software Update/Reconfiguration FUJITSU LIMITED discussion R2-156428 Further discussion on NB-IOT functionalities HTC Corporation discussion R2-156446 RRC connection management for NB-IOT small data transmission ASUSTEK COMPUTER (SHANGHAI) discussion R2-156558 Consideration on PSD Boosting in In-band NB-IoT Sony discussion 7.16.2.2 System Information SI Contents – incl outcome of email disc 91bis#46 , SI Scheduing – incl outcome of email disc 91bis#47, SI Change. SI contents R2-156351 Email discussion report on [91bis#46][NB-IOT] System information content Intel Corporation discussion Recommendation 7 - Ericsson think that presenceAntennaPort1 may be needed. Recommendation 7 - Intel explains that category0Allowed-r12 should be moved to removed. Agreements: The following SI fields are not supported based on RAN2#91bis agreements (i.e. option A): a. csg-Indication p. csg-Identity q. ims-EmergencySupport-r9 r. ac-BarringForEmergency s. ssac-BarringForMMTEL-Voice-r9 t. ssac-BarringForMMTEL-Video-r9 u. ac-BarringForCSFB-r10 v. ac-BarringSkipForMMTELVoice-r12 w. ac-BarringSkipForMMTELVideo-r12 x. speedStateReselectionPars y. mobilityStateParameters z. q-HystSF aa. csg-PhysCellIdRange bb. mbsfn-SubframeConfigList - leaving FFS if this field (or a similar field) is needed in case of in-band deployment to indicate the subframes which are used for MBSFN in the underlying LTE cell. The following SI fields are supported based on RAN2#91bis agreements with 9 / 15 same values of field as those in Rel-13 LTE (i.e. option B1): a. plmn-IdentityList b. cellBarred The following SI fields are supported based on RAN2#91bis agreements with different values of field than those in Rel-13 LTE. It has been agreed to have this IE or similar in the MIB. a. systemInfoValueTag To merge the extensions of legacy SI fields which were added in different specification versions (e.g. cellSelectionInfo with cellSelectionInfo-v920, cellSelectionInfo-v1130 and cellSelectionInfo-v1250; or freqBandIndicator with freqBandIndicator-v9e0; or tdd-Config with tdd-Config-v1130; or multiBandInfoList with multiBandInfoList-v9e0; or ul-CarrierFreq with ul- CarrierFreq-v9e0). NOTE: (*) indicates those fields that need to be further discussed, for example, due to required RAN1/4 inputs or the extended coverage level or Rel-13 eMTC ongoing discussions. Agree that the following SI fields are not supported (i.e. option A): k. If RRC connection re-establishment is not supported, t301 and t311. l. ac-BarringSkipForSMS-r12 m. allowedMeasBandwidth n. presenceAntennaPort1 (*) o. neighCellConfig p. t –ReselectionEUTRA-SF q. q-QualMinWB-r11 r. q-QualMinRSRQ-OnAllSymbols-r12 s. t-ReselectionEUTRA-SF t. cellReselectionPriority x. category0Allowed-r12 Agree that the following SI fields are supported with same values of field as those in Rel-13 LTE (i.e. option B1): e. trackingAreaCode f. cellIdentity g. intraFreqReselection (*) h. freqBandIndicator (*) Agree that the following SI fields are supported with different values of field than those in Rel-13 LTE (i.e. option B2): l. cellSelectionInfo (*) m. p-Max (*) n. schedulingInfoList (*) o. si-WindowLength (*) p. radioResourceConfigCommon (*) q. ue-TimersAndConstants (*) r. timeAlignmentTimerCommon (*) s. q-Hyst (*) t. intraFreqCellReselectionInfo (*) excluding allowedMeasBandwidth, presenceAntennaPort1, neighCellConfig and t –ReselectionEUTRA-SF (which are not supported) u. intraFreqNeighCellList (*) v. interFreqCarrierFreqList (*) excluding t-ReselectionEUTRA-SF, allowedMeasBandwidth, presenceAntennaPort1, cellReselectionPriority, neighCellConfig (which is not supported) The support for the following SI fields is FFS: 10 / 15 k. tdd-Config l. multiBandInfoList m. cellSelectionInfo-v1130 n. category0Allowed-r12 o. freqBandIndicatorPriority-r12 p. freqInfo q. cellReselectionServingFreqInfo r. intraFreqBlackCellList s. ac-BarringInfo t. eab-Param-r11 Agree that SIB16 is supported as agreed for Rel-13 eMTC (i.e. optionally support similarly to legacy). R2-156647 NB-IoT system infromation Qualcomm Incorporated discussion - Nokia proposes that this should be discussed in RAN4. , FFS if we broadcast t-ReselectionEUTRA or instead fix reselection timers in specification taking into account different DRx cycles. R2-156548 System Information Contents for NB-IoT SAMSUNG Electronics Co., Ltd. discussion late SI scheduling R2-156134 Email discussion report on SI scheduling Ericsson report result of email discussion [91bis#47] moved from 7.16.2.1 to 7.16.2.2 Proposal 5: - Neul think that also other parameters need to be sent often, e.g. parameters for paging and cell reselection. - Ericsson think those parameters can be in SIB2 and the UE can read value tag and not re- read. Proposal 6: - Neul proposes to wait. - Agreements: 1 MIB has a fixed size and fixed resource mapping and contains information required to acquire the rest of the system information. The size and resource mapping depends on the physical layer design. 2 System information other than that contained in MIB is grouped into different SIBs (SIB1, SIB2, etc). 3 Different SIBs can be scheduled with different periodicity. 4 The periodicity of SIB1 can be fixed while periodicity of other SIBs can be indicated in SIB1. 5 Cell access and cell selection related system information (e.g. PLMN ID, cell barring, q-RxLevMin, etc) should be prioritized (i.e. transmitted relatively frequently compared to other SIBs) to reduce the time required for cell selection/cell re-selection. 6 We assume that the SI message concept from LTE is applied also in NB- 11 / 15 IOT. This can be revisited. 7 A variable SIB size should be supported. RAN1 should provide input on (1) the maximum TB size for broadcast transmission and (2) whether the TB size for broadcast transmission is variable or fixed. 8 We assume that system information scheduling is PDCCH-less, i.e. parameters (e.g. time/frequency location and MCS/TBS) are fixed or indicated with scheduling information in MIB or SIB1, instead of dynamically indicated on PDCCH (this need RAN1 confirmation). R2-156352 System information design and impacts for NB-IOT Intel Corporation discussion Proposal 1: - The chair wonders if we can choose the simplest approach, C. - QC think we need to optimize for the most common case, static devices. - Ericsson think we should optimize for the majority of the UEs. - Intel do not want the UE to accumulate several SI messages in Parallel. Neul agrees and are in favour of approach C. LG agrees. - Neul don’t understand why we can’t choose the simplest approach and optimize for the UEs in the worst radio. Proposal 3 - Sony wonders why this should not be the same as the modification period. - Ericsson points out that the modification period is signalled in SIB1. Proposal 5 - Ericsson wonders if the indications would be sent in MIB. Intel think that the indications can be sent in SIB1. - Gemalto wonders if the whole SIB1 is covered by system info value tag. - Neul are not sure how useful this is. Ericsson are also not sure. Proposal 7 - QC think that this is not needed - Ericsson think that this is useful for short DRX cycles, as reading MIB could be avoided - Neul think there are not many UEs with short DRX cycle and that this is not needed. Huawei thinks that when the value tag is in the MIB there is no gain. - Intel think we should not exclude this. - Not agreed for now. , The UE is not required to accumulate several SI messages in Parallel. , The UE may need to accumulate an SI message across multiple SI windows, depending on coverage level. , We should define the duration over which the content of NB-IOT SIB1 cannot be changed; details FFS pending RAN1 progress. , The UE is not required to detect SIB changes while being in RRC CONNECTED. The NW may release the UE to RRC IDLE if it wants the UE to acquire changed SIB(s). SI change R2-156560 System Information Area ID and Value Tag Sony discussion R2-156735 Discussion on the System Information Change Indication for NB-IOT ETRI discussion R2-156835 System information change in NB-IoT LG Electronics Inc. discussion late R2-156135 System Information for NB-IoT Ericsson discussion moved from 7.16.2.1 to 7.16.2.2 12 / 15 7.16.2.3 Idle mode procedures Scenarios, requirements and functionality for mobility: Cell Selection, Cell reselection, measurements, Other impact to idle mode. R2-156549 Cell Reselection for NB-IoT SAMSUNG Electronics Co., Ltd. discussion R2-156372 NB-IOT - Cell Selection and Reselection MediaTek Inc. discussion R2-156173 NB-IOT - Idle mode mobility Ericsson discussion R2-156353 Mobility impacts for NB-IOT Intel Corporation discussion R2-156762 Idle Mode MobilityHuawei Tech.(UK) Co., Ltd discussion R2-156544 Idle mode mobility for NB-IoT LG Electronics France discussion R2-156550 Potential Issues for Coverage Enhancement in NB-IoT SAMSUNG Electronics Co., Ltd. Discussion For inter-frequency cell reselection, how to do load balancing - Ericsson think that redirection would be sufficient. Redirection is a command to go to a specific carrier, preferably based on measurements. If measurements are not available an option could be to provide a dedicated cell reselection config. - Mediatek think priority based cell reselection shall be supported and that power consumption for measurements could be small. - LG think that load balancing is important. Cell reselection based on ranking is assumed to be sufficient. - Neul has concerns on priority based cell reselection, and think that this will generate overhead. - QC wonders how dynamic the load balancing is assumed to be. Chair think this is quite static. - Gemalto think that UEs would be likely to stay on a carrier if we use ranking based cell reselection. - Neul think that redirection is sufficient and that it can work without measurements. - Intel wonders how we handle multiple in-band carriers? - Mediatek think that priorities are simple. ZTE wonders if this is dedicated or common priorities. Mediatek think this is dedicated priorities. - ZTE don’t think blind redirection would work. - Samsung think that eNB should gather information for load balancing and then prioritize. , We will have a method for inter-frequency load distribution (quite static). Details FFS. 7.16.2.4 Paging Principles, Idle mode DRX, determination of paging occasion, paging repetition in long DRX cycles, need for optimizations for “false” paging, other. General R2-156769 Paging procedure in NB-IOT LG Electronics Inc. discussion R2-156174 NB-IOT - Paging and DRX in Idle mode Ericsson discussion - Intel thinks that the eDRX CR will be more or less directly applicable to NB-IOT, the main question being where the SFN is transmitted. - Ericsson think that the whole SFN do not need to be transmitted in the MIB. LG prefers to have the whole SFN in the MIB and think there can be space. - We wait for RAN1 regarding the details on SFN. - Qualcomm think that Multiple POs in PTW brings more power consumption. Eri Proposal 3: - Huawei thinks that a cell default paging cycle can be used. - Intel points out that we need to make assumptions on how coverage levels are handled with respect to paging. - QC agrees with the proposal. Vodafone agrees. Intel is ok. , We assume that NB-IOT shall use the eDRX system solution(s). 13 / 15 , In NB-IOT an SFN-based short DRX, long DRX (eDRX) with paging transmission window (PTW) is used. , NB-IOT supports a short DRX up to X seconds, where X need to be selected to allow RAN repetitions between PO, and to allow CN to trigger retransmissions on PO level. , UE monitors all his PO’s in the PTW , PTW start, and PO is calculated based on UE-ID , For the short DRX individual paging cycle is not needed, the defaultPagingCycle of the cell can be used. , As specified for eDRX, we assume that the extended DRX cycle length and PTW size are negotiated between UE and CN during ATTACH/TAU. , RAN2 assumes that the CN sends the paging message to the eNodeB just before the PTW of the NB-IOT device. R2-156375 NB-IOT - Impacts on Paging Mechansim MediaTek Inc. discussion R2-156132 Paging considerations Gemalto N.V. discussion Coverage Levels R2-156175 NB-IOT - Paging and coverage enhancements Ericsson discussion R2-156270 Consideration on coverage level ZTE Corporation discussion Enhancements R2-156354 Paging impacts for NB-IOT Intel Corporation discussion R2-156551 Discussion on Paging in NB-IoT SAMSUNG Electronics Co., Ltd. discussion R2-156767 Further Considerations on Message Reading Indicator Huawei Tech.(UK) Co., Ltd discussion R2-156561 Reduction of Paging Message Reading on PDSCH Sony discussion R2-156379 NB-IOT - Paging Enhancements and Capacity Analysis MediaTek Inc. discussion 7.16.3 User Plane 7.16.3.1 MAC/RLC General functions, Segmentation and reassembly, Support for scheduling / BSR, RACH aspects not related to message-based vs. preamble based, DRX signalling optimization, HARQ, Stage-3 level, Information elements. Descriptions. RACH R2-156430 Further discussion on random access procedure for NB-IoT HTC Corporation discussion R2-156615 NB-IoT: Initial analysis of PRACH capacity ZTE discussion moved from 7.16.1 to 7.16.3.1 R2-156268 Analysis for NB-IoT RACH procedure ZTE Corporation discussion HARQ R2-156137 HARQ principles for NB-IoT Ericsson discussion moved from 7.16.3.2 to 7.16.3.1 DRX R2-156506 DRX in RRC_CONNECTED Neul Limited discussion RLC-AM R2-156138 Need for RLC AM in NB-IoT Ericsson discussion moved from 7.16.3.2 to 7.16.3.1 14 / 15 R2-156765 RLC AM Discussion Huawei Tech.(UK) Co., Ltd discussion R2-156643 Transmission Reliability MediaTek Inc. discussion R2-156171 Lossless delivery for NB IoT NTT DOCOMO INC. discussion R2-156265 Analysis for RLC AM of NB-IoT ZTE Corporation discussion R2-156355 Support of RLC-AM for NB-IOT Intel Corporation discussion R2-156562 AM RLC and DRX for NB-IOT Sony discussion Withdrawn: R2-156552 Considerations on MAC Procedures for NB-IoT SAMSUNG Electronics Co., Ltd. discussion 7.16.3.2 PDCP General functions: header compression, security, Information elements. R2-156645 NB-IoT SA2 architecture implications Qualcomm Incorporated discussion 15 / 15