EDT note for Thesis

# EDT note for Thesis --- ###### tags: `Thesis` ## Agreement --- - The UE initiates EDT in Msg1 when the size of Msg3 including the user data, which UE intends to transmit, is equal or smaller than the maximum possible TBS size for Msg3 broadcast per CE. - PRACH partitioning for EDT indication is configured per enhanced coverage level. - For EDT indication, PRACH resources can be configured as in legacy eMTC or NB-IoT with respect to physical layer resources, preambles/subcarriers. - PRACH resource pool, i.e. physical layer resources, preambles/subcarriers, for EDT indication is separate from PRACH resource pool for legacy RACH procedure - Protocol overhead (MAC/RLC/PDCP/RRC) for EDT is assumed to be 25 bytes for TBS evaluations. - The minimum possible TB size is assumed to be around 320 bits based on the values in (N)PUSCH tables. - If new UL grant format is defined, it does not need to be backwards compatible. - Same RAR format is used for EDT UEs. - The EDT UL grant shall always allow the max TB size broadcasted in system information unless the provided UL grant is for legacy Msg3. - The EDT UL grant shall allow the UE to choose an appropriate TB size, MCS, repetitions, and RUs (for NB-IoT) from a set of TB sizes provided based on the UL data. It is FFS how the set of possible TB sizes, MCS, repetitions, and RUs (for NB-IoT) is provided, e.g. hardcoded in the specs. This is pending RAN1 confirmation. - RAN2 assumes that 8 possible candidate values for the maximum TB size broadcasted in system information. RAN2 assumes that for each maximum TB size broadcasted, up to 4 possible TB sizes, i.e. blind decoding options, are allowed. - For eMTC, the reserved bit in MAC RAR can be used for the EDT feature in eMTC only if it is necessary. - Send an LS reply to RAN1 capturing the agreements above including the agreement on the maximum and minimum possible TB sizes and ask RAN1 for confirmation. - RAN2 has agreed that EDT was for data not signaling or SMS --- ## RAN2 # 101 ### R2-1802603 EDT TBS Determination [MediaTek] This contribution aims to discuss EDT indication via PRACH and NPRACH resource partitioning for NB-IoT. - If EDT UL grant is significantly greater than the UL data packet, the UE may fall back to legacy RACH procedure and only transmit legacy Msg3. - Now only determined the maximum size of data size which UE can used EDT procedure, we may need to set a minimum value for this, since if the data is quite small, most of the part will be padding, for the resource ultilization could be very low. - For example, if the max size of data is 1000 Byte, and UE only have the packet of 250 Byte, it will waste 3/4 resource to do just padding. - Potential solution is to set a minium size for the TBS set of EDT. - There is a possibility that UE decide not to use EDT transimission after MSG2 introduing the UL grant size, for this UE should fall back to legacy procedure - Re-transmit the preamble will waste resource - Potential solution is including legacy MSG3 grant into the RAR message. - The method to indicate the minumum TBS - TBS values indicated by UL grant with flexibility in the RAR - TBS values indicated via Msg1 - Use time domain to determined resource ![](https://i.imgur.com/LOsBDOA.png) --- ![](https://i.imgur.com/RbkTBiM.png) The two method will have same overhead for RACH resource. ### R2-1802766 [GEMALTO] - Should avoid segmentation in EDT procedure due to the complexity of EDT should not be high. ### R2-1802996 NPRACH resource partition - A part of dedicated CFRA preambles can be used for EDT indication - still need to know the concept of CFRA - This discussion is to show how to partition the resource for legacy and EDT procedure. - option 1 - by carrier/frequency - This would waste resource if EDT didn't be requested frequently - option 2 - by time - It wouldn’t be easy to separately provide (N)PRACH resource for EDT indication in time domain without impact on legacy PRACH resource because normal NB-IoT UEs should not transmit the preamble on the specific time which is reserved for EDT indication - option 3 - by preamble - CFRA? - it would reduce the total number of preambles that can be used by legacy UEs ### R2-1802997 Consideration on UL grant for Msg3 [LG] As indicated in the last meeting, if the eNB can provide only maximum TBS size (e.g., 1000 bits) for EDT data transmission but size of EDT data to transmit by the UE is small, there is no way to avoid lots of padding bits in Msg3. This report gave two directions to solve this: - the UE requests EDT without intended size of UL grant and the eNB provides multiple UL grants and the UE selects one of them. - This will have big impact on RAR's format. - Also affect the legacy UEs. - the UE requests EDT with intended size of UL grant and the eNB provides only one UL grant. - the only thing to realize this option is to define PRACH resource partitioning for indicating intended data size. The UE selects and transmits a preamble according to the intended data size for EDT, and then the eNB provides the UE with one UL grant which satisfies the requested data size by Msg1. - This is the only proper option to solve this issue. --- <9.14.2> Early Data transmission for NB-IoT and MTC is treated jointly under this AI. Including output of email discussion padding issue in Msg3 --- ### R2-1803077 Padding issue in Msg3 Ericsson report [Ericsson] Proposal 1 Discuss the feasibility of eNB providing different size UL grant for Msg3 retransmission. - LG and QC think that for HARQ retransmission the eNB shall not provide a grant with a different size. Huawei agrees. - Ericsson explains that this should be possible. MediaTek thinks that the baseline would be that HARQ works as it does currently. Proposal 2 Protocol overhead (MAC/RLC/PDCP/RRC) for EDT is assumed to be 20 bytes for TBS evaluations. - Huawei would like to asssume 25 bytes for 3GPP protocol overhead. => Protocol overhead (MAC/RLC/PDCP/RRC) for EDT is assumed to be 25 bytes for TBS evaluations. Proposal 3 Discuss further the possible minimum payload size and select a minimum TBS for EDT from (N)PUSCH tables based on the discussion. - MediaTek wonders whether we have a limitation regarding the number of possibilities. QC explains we need to think about the step sizes. Sierra Wireless would like to keep it minimum considering SMS as a baseline. Gemalto agrees. - Ericsson thinks it would be good to have something compatitive with technologies alternative to 3GPP. => The minimum possible TB size is assumed to be around 320 bits based on the values in (N)PUSCH tables. Proposal 4 Include the minimum TBS in a reply to RAN1 LS. Proposal 5 Usable TB sizes are chosen from the existing (N)PUSCH tables. The number of possible sizes are decided after discussion of the grant mechanism. Proposal 6 RAN2 intends to specify a mechanism to avoid the padding issue. - Huawei thinks that this should be up to the feedback from RAN1. QC suggests to discuss the solutions first. QC thinks wording can also be improved since there will be padding in either case. We can say “to minimize” instead. - QC and Intel would like to deprioritize addressing this issue. Proposal 7 Ask feasibility of flexible resource allocation (e.g. solution 2./3./6.) from RAN1. => We need to discuss the next proposal first. Proposal 8 Discuss further if Msg3 padding issue is addressed using flexible resource allocation, pending RAN1 confirmation, and/or (N)PRACH partitioning. - MediaTek thinks it would be good to address this issue. - QC thinks PRACH partitioning should not be considered. LG thinks PRACH partioning should not be ruled since other options have impacts on other procedures. Huawei thinks PRACH partioning would be **waste of resources**. - MediaTek explains why it would be good to address this issue otherwise it may be too costly for the UE regarding power consumption. This is especially the case for UEs in bad coverage. - Ericsson suggests discussing the details of the solution as the usecases have already been discussed and identified. Proposal 9 Segmentation support (solution 7.) is discussed separately based on further contributions. Proposal 10 Discuss sub-PRB allocation for Msg3 based on further contributions. Agreements: - Protocol overhead (MAC/RLC/PDCP/RRC) for EDT is assumed to be 25 bytes for TBS evaluations. - The minimum possible TB size is assumed to be around 320 bits based on the values in (N)PUSCH tables. --- ### R2-1802220 TBS of EDT Msg3 in NB-IoT and MTC Huawei, HiSilicon discussion ### R2-1802221 Draft reply LS to RAN1 on early data transmission Huawei Proposal 1: Indicate to RAN1 that the larger the number of TBS values the better in both NB-IoT and MTC. - LG thinks it would be good to consider the use cases and there is no need to send too many values. Proposal 2: RAN2 to confirm that the new UL grant format / definition does not need to be backward compatible (向下兼容). - LG thinks there should not be any impact on the legacy UEs w r t power consumption. - QC and Ericsson agree with the proposal. - ZTE thinks similarly with LG. RNTI’s can be the same for legacy and EDT UEs. - MediaTek thinks more work is needed if format is changed. For the UL grants, there is no need to be backwards compatible. - Ericsson proposes that RAR format should be kept same and UEs need to check the header. => If confirmed new UL grant format does not need to be backwards compatible. => **Same RAR format is used for EDT UEs.** Proposal 3: RAN2 to provide the following feedback to RAN1 for NB-IoT: Alt.0, Alt.1 and Alt.5 are too restrictive in terms of number of possible combinations. - Alt.2 allows enough combinations for flexibility and can be a suitable option. - Alt.3 has not benefit compared to alt 2, is less flexible and uses unnecessarily bits in the SIB. - Alt.4 offers the full flexibility in terms of which TBS can be used and is preferred. - QC and Ericsson agree with the intention. - Gemalto also agrees and wonders if there is a need to have too many TB sizes. - ZTE wonders about the need for a bit in RAR for eMTC. - QC prefers to indicate only the alternative preffered. - Huawei thinks there is no point in providing a grant in between legacy and maximum possible TB size. - Ericsson think we should not mandate anything on eNB. => We will draft a reply LS based on the solution we would like to have and there is no need address the alternatives from RAN1. RAN2 would like RAN1 to choose the alternatives based on the agreements, i.e. related solution, from this meeting. Proposal 4: Indicate to RAN1 that the reserved bit in MAC RAR can be used for the EDT feature in MTC. - MediaTek thinks it is OK to state that the reserved bit can be used if necessary. Ericsson prefers not to use it unless there are no other means. Intel is fine using the reserved bit for MTC if necessary. - Ericsson thinks that we can indicate that it is possible but also state that it should only be used unless there are no other alternatives. LG agrees. Agreements - If new UL grant format is defined, it does not need to be backwards compatible. - Same RAR format is used for EDT UEs. --- ### R2-1803080 TB sizes and UL grant for Msg3 Ericsson discussion ### R2-1803081 DRAFT Reply LS to RAN1 on early data transmission Ericsson Proposal 1 Use flexible uplink resource allocation, such as two or more signalled TB sizes for Msg3 to avoid excessive padding. Proposal 2 Ask RAN1 about feasibility of flexible TBS indication in UL grant for Msg3 based on above information. If found feasible, ask RAN1 to specify UL grant with multiple TBS options. - MediaTek thinks a general agreement would be good to inform RAN1 and ask for confirmation. - MediaTek proposed that we can inform RAN1 that it would be benefical if the UE could choose a TB size that requires minimum number of padding bits. - QC agrees with MediaTek that this would be beneficial. - QC and Sierra Wireless would like to have the discussion based on the alternatives provided during the related email discussion. - MediaTek thinks it would be if the UE can use this flexibility to fallback to legacy and this should be stated in the LS reply. MediaTek would like to keep the size of padding bits to %10 in the largest TBS. - LG wonders how it would be possible for the UE to go with the legacy mechanism. - Huawei thinks that eNB should either provide UL grant size for the legacy message or the maximum possible value broadcasted in SI. - QC thinks that the network should provide the maximum possible value broadcasted in system information. Sierra Wireless, Gemalto, MediaTek, and Nokia assume the same. MediaTek thinks that the UE may use a more reliable MCS instead of padding bits. This is up to RAN1 to decide. - Sierra Wireless thinks that a table of possible TB sizes can be provided in SI or hardcoded in the specs and the UE chooses based on the maximum possible value broadcasted in SI. Gemalto agrees with Sierra Wireless. - ZTE indicates that network resources should also be considered. - Ericsson states that that would mean the network would provide the legacy grant when no resources are available for the max possible TB size. - MediaTek thinks that RAN2 already agreed that the solution adresses both UP and CP solutions and therefore segmentation should not be a requirement. - ZTE thinks that mandating the max possible TB size broadcasted would mean that the network may be quite conservative in terms of max TB size, i.e. smaller max TB size. => We intend to send an LS reply to RAN1 stating that RAN2 thinks that it would be benefical if the **UE could choose a TB size that requires minimum number of padding bits** from a set of possible TBS values. => The EDT UL grant shall always allow the max TB size broadcasted in system information unless the provided UL grant is for legacy Msg3. => The EDT UL grant shall allow the UE to choose an appropriate TB size, MCS, repetitions, and RUs (for NB-IoT) from a set of TB sizes provided based on the UL data. It is FFS how the set of possible TB sizes, MCS, repetitions, and RUs (for NB-IoT) is provided, e.g. hardcoded in the specs. This is pending RAN1 confirmation. => RAN2 assumes that 8 possible candidate values for the maximum TB size broadcasted in system information. RAN2 assumes that for each maximum TB size broadcasted, up to 4 possible TB sizes, i.e. blind decoding options, are allowed. => Send an LS reply to RAN1 capturing the agreements above including the agreement on the maximum and minimum possible TB sizes and ask RAN1 for confirmation.  Draft LS reply to RAN1 on early data transmission [offline# 402] [Huawei] in R2-1803882. => Replace “The EDT UL grant shall always allow the max TB size broadcasted in system information unless the provided UL grant size is the legacy minimum TB size for Msg3.” with “The EDT UL grant shall always allow the max TB size broadcasted in system information unless the provided UL grant is for legacy Msg3.” => Replace “For eMTC, the reserved bit in MAC RAR can be used for the EDT feature in eMTC if necessary.” with “For eMTC, the reserved bit in MAC RAR can be used for the EDT feature in eMTC only if it is necessary.” => With the changes above, the LS is approved in R2-1803884. Proposal 3 Minimum TBS for Msg3 transmission is in order of few hundred (200-300) bits at most. Indicate this to RAN1. => This proposal has already been discussed. Proposal 4 Ask RAN1 to consider redefining the UL grant in RAR message and to use 5-bit MCS index for signalling TB size or combinations of multiple TB sizes, RUs, repetitions, if viable. Proposal 5 Indicate to RAN1 that for LTE-M one reserved RAR bit is not needed to be used for EDT feature. Proposal 6 Indicate to RAN1 in the reply LS that the UL grant can be redefined if needed, thus no spare bits need to be used for EDT. Agreements - The EDT UL grant shall always allow the max TB size broadcasted in system information unless the provided UL grant is for legacy Msg3. - The EDT UL grant shall allow the UE to choose an appropriate TB size, MCS, repetitions, and RUs (for NB-IoT) from a set of TB sizes provided based on the UL data. It is FFS how the set of possible TB sizes, MCS, repetitions, and RUs (for NB-IoT) is provided, e.g. hardcoded in the specs. This is pending RAN1 confirmation. - RAN2 assumes that 8 possible candidate values for the maximum TB size broadcasted in system information. RAN2 assumes that for each maximum TB size broadcasted, up to 4 possible TB sizes, i.e. blind decoding options, are allowed. - For eMTC, the reserved bit in MAC RAR can be used for the EDT feature in eMTC only if it is necessary. - Send an LS reply to RAN1 capturing the agreements above including the agreement on the maximum and minimum possible TB sizes and ask RAN1 for confirmation. ---  Email discussion on the remaining issues for EDT in the CP and UP solutions [Huawei] - Intention: to progress the discussion on the remaining issues for EDT in the CP and UP solutions. - The email discussion is until the next meeting.  Email discussion on the security issues for EDT [Intel] - Intention: to progress the discussion on the security issues for EDT. - The email discussion is until the next meeting.  Email discussion on running 36.331 CR for eMTC and NB-IoT for EDT to capture the Rel-15 EDT agreements [Qualcomm] - Intention: to progress the running 36.331 CR for eMTC and NB-IoT for EDT to capture the Rel-15 agreements. - The email discussion is until the next meeting.  Email discussion on running 36.331 CR for eMTC excluding EDT to capture the Rel-15 agreements [Qualcomm] - Intention: to progress the running 36.331 CR for eMTC excluding EDT to capture the Rel-15 agreements. - The email discussion is until the next meeting.  Email discussion on running 36.321 CR for eMTC and NB-IoT for EDT to capture the Rel-15 EDT agreements [Intel] - Intention: to progress the running 36.321 CR for eMTC and NB-IoT for EDT to capture the Rel-15 agreements. - The email discussion is until the next meeting.  Email discussion on running 36.321 CR for eMTC excluding EDT to capture the Rel-15 agreements [Intel] - Intention: to progress the running 36.321 CR for eMTC excluding EDT to capture the Rel-15 agreements. - The email discussion is until the next meeting. ## RAN2 #101bis ### R2-1804756 Size of downlink PDU in EDT [Qualcomm] there is no segmentation and reassembly of MSG4 in EDT hence upper layer downlink PDU must fit into the TBS used for MSG4 for EDT. If the upper layer downlink PDU does not fit into the TBS used for MSG4 then eNB will trigger **fall-back** to (legacy) RRC connection establishment/resumption and UE will enter *RRC Connected state*. ### R2-1804896 Handling fallback issues in EDT [Intel] Consider fallback scenario, when EDT UE failed to recieve corresponding RAR in CE level x, after maxNumPreambleAttemptCE, UE consider to be in the next CE level. Since MAX TBS assigned to each CE level will be different, it may happened that the MSG3 PDU > the new TBS size. In this case, RRC should inform low layer not to initiate the RA procedures. In this tdocs, few proposal are rasied related to - provide 2 grant together (EDT & legacy) - if fallback, flush msg3 buffer in UE for both CP & UP ### R2-1804925 EDT in RA [Nokia] Basically, this tdoc is mainly talking about the same scenario as R2-1804756 which describe when changing a CE level, check TBS first and indicate to use EDT or not. Second, UE should re-struct the MAC PDU when different TBS setting ### R2-1805078 Report of the Email discussion [101#57][NB-IoT/MTC R15] EDT remaining issues [Huawei] ==This is the comment gathering report== - Companies to provide their views on whether EDT is considered as a connection control procedure (described in section 5.3) or a data transfer procedure (described in section 5.6) and what should be the UL/DL EDT messages names for the CP solution. - Still FFS for the result - Conditions for initiate EDT procedures - For Huawei - a) EDT is an optimsation of the signalling over the air interface and it should be kept transparent to NAS as far as possible. Thus we think that the decision should be taken by RRC and that the upper layers do no need to differentiate. - b) RAN2 has agreed that EDT was for data not signaling or SMS and translate to establishCause : mo-Data / mo-ExceptionData and delayTolerant with call type set to originating calls. - c) EDT shall only be initiated when the UE is not expected any uplink data after MSG3. If not the case, there is no benefit to EDT. - d) EDT shall only be initiated when the UE is not expected any further DL data after MSG4. If not the case, there is no benefit to EDT. - For Kyocera - For c) d) from Huawei, not agree with these restriction. At least for DL, UE doesn't know how much resources the eNB will allocate for Msg4 exactly. - For Nokia - For b), Establishment cause can be subsetof exsiting establishment cause as it has been agree that EDT is only for data. - Agree with Huawei c) d) - For Ericsson - For d), need to be confirmed that it can test in practice - For Intel - For c), this should mean there is no further data arrival before RRC initiates EDT. - For d), same concern with Kyocera, Ericsson - For Qualcomm - For c) d), it is based on implementation choice - For LG - For a concern from MSG3 UE trigger initial, and then network part try to allocate resource for their DL message, otherwise release and then do the paging - RRCConnectionReject: might not be applicable as a response to RRCConnectionResumeRequest for EDT. - Because of UP, so prefer not go into detail - RRC Early data Request: not include multiToneSupport and multiCarrierSupport in MSG3, since there is no msg5. - ZTE has other opinion : keep the two IE will be useful in fallback case.