3GPP RAN2 5GNR 技術發展狀況. Feng-Ming Yang Institute for Information Industry

Size: px

Start display at page:

Download "3GPP RAN2 5GNR 技術發展狀況. Feng-Ming Yang Institute for Information Industry"

Esther Hicks
5 years ago
Views:

1 3GPP RAN2 5GNR 技術發展狀況 Feng-Ming Yang Institute for Information Industry

2 5G Vision and Requirements 5G supports efficiently three different types of traffic profiles embb ->high throughput for e.g. video services mmtc -> low energy for e.g. long living sensors URLLC -> low latency for e.g. mission critical services Source : 5G-PPP 2

3 Architecture options in the light of 5G Two radio technologies have to be considered in the 5G discussions LTE (in its Rel-15 version) Next generation Radio (NR) Plus radio level aggregation of both radio technologies Two Core Network concepts have to be considered in the 5G discussions EPC (with potential evolutions) Next Generation Core (NGCN) This results in 8 options Source : SP (T-Mobile) 3

4 5G scenarios in 3GPP NR & NextGenCore (1/4) Source : SP (T-Mobile) 4

5 5G scenarios in 3GPP NR & NextGenCore (2/4) Source : SP (T-Mobile) 5

6 5G scenarios in 3GPP NR & NextGenCore (3/4) Source : SP (T-Mobile) 6

7 5G scenarios in 3GPP NR & NextGenCore (4/4) Source : SP (T-Mobile) 7

8 TSG Plenary Status for 5G 3GPP Study/Work Item New Services and Markets Technology Enablers Study on New Services and Markets Technology Enablers Study on Enhancement of 3GPP support for V2X service FS_SMARTER - Massive Internet of Things FS_SMARTER - Critical Communications FS_SMARTER - Enhanced Mobile Broadband FS_SMARTER -Network Operation Study on Architecture for Next Generation System Study on Channel model for frequency spectrum above 6 GHz Meetin g SA#72 SA#67 SA#72 SA#70 SA#70 SA#70 SA#70 SA#70 RAN#6 9 Relea se Rel- 15 Rel- 14 Rel- 15 Rel- 14 Rel- 14 Rel- 14 Rel- 14 Rel- 14 Rel- 14 Date MAR 2016 ~ MAR 2017 MAR 2015 ~ MAR 2016 MAR 2016 ~ MAR 2017 DEC 2015 ~ JUN 2016 DEC 2015 ~ JUN 2016 DEC 2015 ~ JUN 2016 DEC 2015 ~ JUN 2016 DEC 2015 ~ DEC 2016 SEP 2015 ~ JUN 2016 Study on Scenarios and Requirements for Next Generation RAN#7 Rel- DEC 2015 ~ SEP 8

9 Timelin e for NR and NexGen 2. TSG-SA#74, Dec/2016: NexGen TR completion Approval of SA2 WID 1. TSG-RAN#73, September 2016: 5G NR Requirements TR completion 4. TSG-SA#77 or TSG-SA#78: NexGen stage-2 freeze. 7. TSG#80, June 2018: Release 15 stage 3 freeze for NR and NexGen, including Standalone. 6. RAN#78/RAN#79: Stage-3 freeze for Non-Standalone higher layers (including components common with standalone). Completion target TBD. (between Dec 2017 and March 2018) CHECKPOINT: TSG#75: March 2017: - Completion of NR SI with corresponding performance evaluation and concepts; - Approval of RAN WID(s); - Report from RAN1/RAN2/RAN3/RAN4/SA2 on fwd compatibility of NSA and SA NR; - Report from SA2 on migration; - SA and CT timeline coordination; - Reconfirmation of NR & NexGen timeplan, including completion target for NSA higher layer components (box 6) 5. TSG-RAN#78, December 2017: - Stage 3 freeze of L1/L2 for common aspects of NSA (focused on licensed bands) and SA NR; - Principles agreed for SA-specific L1/L2 components. Note: SA: Standalone NSA: Non-Standalone 9

10 Discussion on prioritization for NR study and work phases In order to allow 3GPP RAN to meet the agreed timeline for phase I of 5G specification in Rel-15, it is proposed that guidance be given to working groups to put on hold until March 2017 the study of the following use cases and advanced features, except for considerations on forward compatibility: Interworking with non-3gpp systems Operation in unlicensed bands Wireless relay, sidelink, backhaul Multimedia Broadcast/Multicast Service Location/positioning, public safety, emergency communication, public warning/emergency alert Support of shared spectrum SON All architecture options except for options 3, 7 and 2 Realization of RAN network functions No te The second phase of the study, which is expected to start in March 2017, will 10 revisit the priority for these use cases and advanced features. Reference : RP

11 RP Way forward on NR features The following studies are not included in the target content for Rel-15 without changing the scope of SID and postponed until March 2017 Waveforms above 40GHz mmtc features Flexible duplex specific optimization for paired spectrum from RAN1/2/3 perspective Note: a common RAN1/2/3 solution to support flexible duplex for both unpaired and paired spectrum is within the target content for Rel-15. Reliability aspect for URLLC Interworking with non-3gpp systems Wireless relay, sidelink, backhaul, ev2v (except for forward compatibility) Multimedia Broadcast/Multicast Service No te Location/positioning, public safety, emergency communication, public 11 warning/emergency alert

12 RP Outcome from prioritization discussion for New Radio Access List of items: Waveforms above 40GHz mmtc [Flexible duplex of paired spectrum] Interworking with non- 3GPP systems Wireless relay Satellite communication Air-to-ground and light air craft communications Extreme long distance coverage Technology SI Sidelink V2V and V2X proposal is approve d Multimedia Broadcast/Multicast Service Shared spectrum and unlicensed spectrum [Location/positioning functionality] Public warning/emergency alert New SON functionality 12

13 3GPP TSG-RAN WG2 SI: Study on New Radio Access Technology 13

14 3GPP TSG-RAN WG2 User plane issue 14

15 Receiver ACK ACK Transmitter Retransmission PDCP SDU Agreement - The ARQ will be supported in RLC. - RLC adds an RLC SN PDCP Header RLC PDU_1 RLC PDU_2 RLC PDU_3 Naturally, to retransmit all segments (including PDU_1 and PDU_3) would need to be re-sent instead of just the missing segments. RLC PDU_1 RLC PDU_2 RLC PDU_3 waste radio resources introduce additional delay since several Retransmission of individual RLC PDUs Reference : R

16 Sender PDCP Sender RLC Receiver PDCP/RLC Reordering - Most companies see the benefit of removing RLC reordering to support URLLC. BUT - that there is additional latency with single reordering if there is non-ideal backhaul between the entity hosting PDCP and the entity hosting RLC: Data Agreement 1: NR specification should not prohibit out-of-order deciphering of PDCP PDUs. Sender PDCP Data Sender RLC Receiver PDCP/RLC Lost RLC status report Reordering in RLC Lost PDCP status report Reordering in PDCP RLC retransmission Delay of non-ideal link PDCP retransmission (a) RLC retransmission Reference : R (b) PDCP retransmission 16

17 Concatenation Show of hands: No Concatenation in RLC 18 Concatenation in RLC 12 Potential working assumption: RLC concatenation can be removed for NR UP protocol stack. Reference : R

18 Segmentation SO-based segmentation For instance, retransmission with lower MCS due to CQI degradation requires SO-based segmentation even for the same or larger available physical resource block. RLC SDU Segmentation (SO-based) SN=0 SO=0 LSF=0 RLC SDU SN=0 SO=400 LSF=1 RLC SDU Agreements 1: In NR, the segmentation function is only placed in the RLC layer as in LTE. Resegmentation (SO-based) SN=0 SO=0 LSF=0 RLC SDU SN=0 SO=300 LSF=0 RLC SDU SN=0 SO=600 LSF=1 RLC SDU SO-based segmentation and resegmentation Reference : R Agreement => SO-based segmentation can be considered for both segmentation and resegmentation as a baseline in NR user plane to support high data rate. (Does not imply anything about location of concatenation). At least overhead for the low data rate case should be 18 analysed further.

19 QoS UL DL UE UL Filter configuration 5 DRB DL DRB UL 4 RAN Split 3 2 DRB configuration 1 QoS policy CN 1. RAN receives QoS policy over the C-plane associated to a flow. The QoS policy may be signalled to the RAN as a part the PDU session establishment process or after the flow detection function in the CN has detected a new flow. 2. The RAN detects the new flow by utilizing QoS marking attached in the encapsulation header of the DL PDU. The RAN determines the forwarding treatment over the radio basing on the QoS policy. 3. The RAN selects the DL DRB (allocation function) that is able to full fill the QoS requirements of the flow 4. If such DRB does not exist a new one is UL TFT configuration with reflective QoS Reference : R established. 5. UE determines the UL mapping rule from 19

20 3GPP TSG-RAN WG2 Control plane issue 20

21 New state (1/3) New Grant Free State Star t No Data IDLE Monitor Paging Mobility Management Data RACH Proc CONNECT Security, Resume_ID Timing Adv Data Sched Send Proc Grant Free Monitor Paging Mobility Management Small Data GF Send Proc Reference : R

New state (2/3) Observation 1: There is value to defining now a low latency and low Reference : R2-166059 overhead small data UL transmission method within the new state Small Data Transmission in

22 New state (2/3) Observation 1: There is value to defining now a low latency and low Reference : R overhead small data UL transmission method within the new state Small Data Transmission in the New State The possibility of combining the contents of messages 1 and 3 and messages 2 and 4 was also suggested, for transmision on a contention-based channel in small cells or when the TA may be known. In the GF state, if a large amount of data (e.g. > 100 bytes) is required to be sent, the UE executes a normal RACH process (as if the UE was in the Idle state). This case is denoted as Large Data in the condition for state transition. In the GF state, if a small amount of data (e.g. < 100 bytes) is required to be sent (denoted by Small Data in the condition for state 22 transition), the UE executes an efficient new

23 New state (3/3) The MCS cannot be mapped to the resume ID as it depends on the amount of data and the channel conditions. A new state where the TA is assumed correct, can allow access using far less resources and less time. Reference : R

24 System Information (1/3) Reference : R

25 System Information (2/3) On-demand System Information Acquisition Signaling overhead for different broadcast period and SI size Reference : R

26 System Information (3/3) In LTE approach, the needed resource to transmit minimum SIB within one T change is R T change / T period. With on-demand delivery, the calculation is R +γrλt change. The overall resource efficiency for on-demand delivery is: RTchange / T efficiency R R T period change T period T change (1 T change ) T period 1 1 ( T change ) Reference : R

27 LTE-NR tight interworking specific aspects UP PDCP RLC Coordination function RRC NR - RRC NR RRC Configuration CP Split bearer NR L2 UP UP PDCP RLC RRC CP Split bearer NR - RRC NR L2 UP MAC MAC PHY NR-PHY PHY NR-PHY LTE RAN NR RAN TX over LTE Air Interface TX over NR air Interface TX over LTE Air Interface TX over NR air Interface UE Reference : R

28 3GPP TSG-RAN WG2 Mobility issue 28

Cell definition UE should be able to distinguish

nonserving cells for RRM measurements in active

UE should be able to determine if a beam is from its

gnb and NR cells A NR cell is handled by a single gnb.

29 Cell definition UE should be able to distinguish between the beams from its serving cell and beams from nonserving cells for RRM measurements in active mobility. UE should be able to determine if a beam is from its serving cell. gnb and NR cells A NR cell is handled by a single gnb. A gnb may handle one or more cells. Reference : R NR cell, TRPs and antennas. There is a single RRC entity for the UE with one NR serving cell. 29

RRM/DL Measurements (1/2) ray-tracing simulation tool Reference : R2-167 1. Location : Wolpyeong-dong, Daejeon, Korea 2.

Metric : L1/L3 filtered RSRP (dbm) 5. The number of N-best beams = 4 Ping- Pong rate LOS NLoS Singlebeabeabeabeam Multi- Single- Multi- 9.89% 4.

30 RRM/DL Measurements (1/2) ray-tracing simulation tool Reference : R Location : Wolpyeong-dong, Daejeon, Korea 2. Tx Beamforming parameters A. Gain dbi, Azimuth Degree :18⁰ Elevation Degree :10⁰ B. Tx Power : 35 dbm 3. UE Rx Beamforming : Omi 4. Metric : L1/L3 filtered RSRP (dbm) 5. The number of N-best beams = 4 Ping- Pong rate LOS NLoS Singlebeabeabeabeam Multi- Single- Multi- 9.89% 4.18% 16.39% 12.19% To determine cell level signal quality, UE should be able to group beams of the same cell for RRM measurement, which leads stable mobility performance. 30

multiple beams can be detected (this does not preclude RRM measurement made on

31 RRM/DL Measurements (2/2) LoS NLoS Agreement 1 For connected mode, cell level signal quality for RRM measurement can be derived from multiple beams, if multiple beams can be detected (this does not preclude RRM measurement made on a single beam) FFS how to combine beam measurements to a cell level single quality 31

32 Uplink Measurement (inactive state) Ptx Prx Power Up PSS/ SSS UL beacon If indicated by NW response, perform DL measurement or beacon reconfiguration NW resp. (Meas./ Reconf.) Power Down PSS/ SSS Waiting for potential NW UL response beacon Light sleep Deep sleep ON duration ON duration Time Deep sleep ON Deep sleep ON Deep sleep DRX cycle DRX cycle Reference : R

33 Uplink Measurement (active state) Good UL quality => participate in tx/rx Mediocre UL, poor candidate for cell Too weak link Reference : R UE Target gnb 2 /cell 2 Source gnb 1 /Cell 1 Decision to configure measurements What UE? RRC reconfiguration (SRS resources) Measurement Request Send SRS Use of UL reference signals for TRP selection Next =>Benefits of UL based mobility, compared to DL based mobility, should be studied with performance analysis. RRC reconfiguration (HO command) Data transmission Detect SRS Measurement Report Handover preparation Decision to perform handover Handover procedure based on UL signa 33

34 34

35 System Information 35

36 RRC Signaling for Light Connection (R14) The lightly connected state is between RRC_IDLE and RRC_CONNECTED: Connected-mode-like functions S1 connection is kept and active in the anchor enb The UE AS context is kept in both UE and anchor enb side. The ECM state is ECM-CONNECTED, from network perspective. Idle-mode-like functions Support of RAN initiated paging, where the paging process is controlled by anchor enb, and RAN based paging area can be configurable as UE specific. Performing cell reselection based mobility, the same cell reselection mechanism in RRC IDLE. 36

37 Key Migration Paths Option 1 Option 7 Option 2 / Option 4 This is the likely migration path for operators who are interested in upgrading their current LTE RAN infrastructure to connect to NextGen Core. With elte not being a legacy technology, and due to potential significant coverage differences dependent upon spectrum availability, it is possible that this intermediate step may exist over a long period of time. Option 1 Option 3 Option 2 / Option 4 This is the likely migration path for operators who want to reuse their existing LTE RAN and core. Moving from Option 3 to Option 2 maybe as significant a step as moving from LTE/EPC directly to Option 2. Option 1 Option 3 Option 7 Option 2 / Option 4 For those operators wanting to start with Option 3, it is not clear how long Option 3 s intermediate step can last and if it will require migrating to Option 7 or can go straight to Option 2/ Option 4. Some further analysis of migrating from Option 3 to Option 7 should be done as part of this Source work : S to determine its 37 viability. (AT&T)

K E Y N O T E S P E E C H. Deputy General Manager / Keysight Technologies

K E Y N O T E S P E E C H. Deputy General Manager / Keysight Technologies //08 K E Y N O T E S P E E C H Jeffrey Chen Jeffrey-cy_chen@keysight.com 08.0. Deputy General Manager / Keysight Technologies M O R E S P E E D, L E S S P O W E R, P E R F E C T A C C U R A C Y NETWORKS/CLOUD