5 G

5G-NR (New Radio) in 3GPP from RAN2
point of view
陳宏鎮
工研院資通所
工研院版權所有 Copyright©2016 ITRI. All rights reserved. 1

Agenda
• Scenarios and Requirements for 5G-NR
• Deployments Scenarios for 5G-NR
• LTE-NR Tight Interworking
• NR Architecture Design

Scenarios and Requirements for
5G-NR

Scenarios and Requirements for 5G-NR
• TR 38.913 “Study on Scenarios and Requirements for Next Generation Access
Technologies”
• A fully mobile and connected society is expected in the near future, which will be
characterized by a tremendous amount of growth in connectivity, traffic volume
and a much broader range of usage scenarios.
• The families of usage scenarios for IMT for 2020 and beyond include:
• eMBB (enhanced Mobile Broadband)
• mMTC (massive Machine Type Communications)
• URLLC (Ultra-Reliable and Low Latency Communications)
• (RP-160671: Target a single technical framework addressing all usage scenarios,
requirements and deployment scenarios defined in TR38.913)
• (TR 38.804: TR for Study on New Radio Access Technology Radio Interface
Protocol Aspects)

Reference:
RWS-150055
Reference:
RWS-150081
• Deployment Scenarios
• Indoor Spot: Focus on small coverage per site/TRP (transmission and reception point) and
high user throughput or user density in buildings.
• Dense Urban: Focus on macro TRPs with or without micro TRPs and high user densities and
traffic loads in city centres and dense urban areas.
• Rural: Focus on larger and continuous coverage (for high speed vehicles).
• Urban Macro: Focus on large cells and continuous coverage.
• High Speed: Focus on continuous coverage along track in high speed trains.
• Extreme rural for the Provision of Minimal Services over long distances: Allow the Provision
of minimal services over long distances for Low ARPU and Low density areas including both
humans and machines.
• Extreme rural with extreme Long Range: allow for the Provision of services for very large
areas such as wilderness or areas where only highways are located primarily for humans.
• Urban coverage for massive connection: Focus on large cells and continuous coverage to
provide mMTC.
• Highway Scenario: Focus on scenario of vehicles placed in highways with high speeds.
• Urban Grid for Connected Car: Focus on scenario of highly densely deployed vehicles placed
in urban area.

• ITU 5G Requirements (2015 June)
100 Mbit/s is expected in urban
Expected to reach 10 Gbit/s and and suburban
support up to 20 Gbit/s 1 Gbit/s can be reached in hotspot
10 Mbit/s/m2 area traffic 3 times higher compared

capacity in hotspot to IMT-Advanced
5 times subject to
further research
Should not be greater than
current IMT networks while
delivering other enhanced enable high mobility up to 500
capabilities km/h with acceptable QoS
up to 106 /km2 in massive machine

type communication scenario Provide 1 ms over-the-air
latency
*4G: IMT-Advanced Reference: WP5D #22, June 2015
• KPI of NR
• Control Plane Latency from a power efficient state to a data transmission state 10ms
• User Plane Latency 0.5ms for URLLC
• User Plane Latency 4ms for eMBB
• Latency for infrequent small packets 10s
• Mobility interruption time 0ms
• 15 years battery life with a sparse small packet traffic model
• Mobility in the range from 0km/h to 500km/h
• The RAN system shall have the capability to minimize the backhaul and signalling
load

eMBB mMTC URLLC
Data Rate Very high Not much considered Not much considered
(e.g. peak rate 10 Gbps)
Latency Low Not much considered Very Low

(e.g. 0.5 ms end-to-end)
Mobility 0km/h to 500km/h Not much considered Not much considered
Very High
Reliability Not much considered Not much considered (e.g. Packet loss rate: as
low as 1e-04)
Power Not much considered Very Low Not much considered

Consumption
Connection High Very High High

Density (e.g. 200-2500 UEs/km ) (e.g.1M connections/ km2)
2 (e.g. 10k device/10km2)

• Requirements for architecture and migration of Next Generation Radio Access
Technologies
• The RAN architecture shall support tight interworking between the new RAT and LTE.
• Considering high performing inter-RAT mobility and aggregation of data flows via at least
dual connectivity between LTE and new RAT. This shall be supported for both collocated
and non-collocated site deployments.
• The RAN architecture shall support connectivity through multiple transmission
points, either collocated or non-collocated.
• Different options and flexibility for splitting the RAN architecture shall be allowed.

Deployments Scenarios for 5G-NR

• In terms of cell layout, the following scenarios are assumed:
• Homogeneous deployment where all of cells provide the similar coverage, e.g. macro
or small cell only;
• Heterogeneous deployment where cells of different size are overlapped, e.g. macro
and small cells.
LTE (macro cell)

Co-located cell
NR (small cell)
LTE NR Non-co-located cell

• The deployment scenarios in terms of CN-RAN connection are classified into the
following cases:
• LTE eNB is a master node;
• NR gNB is a master node;
• eLTE eNB is a master node;
• Definition: The evolution of eNB that supports connectivity to EPC and NG-Core.
• Inter-RAT handover between NR gNB and (e)LTE eNB.

• LTE eNB as a master node:
• Data flow aggregation across LTE eNB and NR gNB via EPC.

• NR gNB acts as a master node:
• NR gNB is connected to NextGen Core;
• Data flow aggregation across NR gNB and eLTE eNB via NextGen Core.

• eLTE eNB acts as a master node:
• eLTE eNB is connected to NextGen Core;
• Data flow aggregation across eLTE eNB and NR gNB via NexGen Core.

• Inter-RAT mobility:
• LTE eNB is connected to EPC and NR gNB is connected to NextGen Core;
• eLTE eNB and NR gNB is connected to NextGen Core.

• Interworking with WLAN
• WLAN is integrated in NR via NextGen Core

• The other scenarios under the scope of the NR study such as wireless relay and
D2D (device to device) are also taken into account although not explicitly
described in this technical report.
Reference: R2-164800
LTE-NR Tight Interworking

Evolution of Dual Connectivity
• Rel-12 Dual Connectivity
• SI: Study on Small Cell Enhancements for E-UTRA and E-UTRAN
• WI: Dual Connectivity for LTE
• DC Control Plane
• DC User Plane
• DL Bearer Split
• Rel-13 Dual Connectivity Enhancements
• WI: Dual Connectivity Enhancements
• UL Bearer Split
• Rel-14 Dual Connectivity for LTE-NR Tight Interworking
• SI: Study on New Radio Access Technology

Scenarios of Small Cell Deployment
• Scenario 1: macro and small cells on the same carrier frequency (intra-frequency) are connected
via non-ideal backhaul.
• Scenario 2: macro and small cells on different carrier frequencies (inter-frequency) are
connected via non-ideal backhaul.
• Scenario 3: only small cells on one or more carrier frequencies are connected via non-ideal
backhaul.
3GPP TR 36.932: "Scenarios and Requirements for Small Cell Enhancements for E-UTRA and E-UTRAN"
工研院版權所有 Copyright©2016 ITRI. All rights reserved. 23 5
Challenges and Solutions
• Challenges in small cell deployments
• Mobility robustness
• Increased signalling load due to frequent handover
• Improving per-user throughput
• Dual connectivity is the operation where a given UE consumes radio resources
provided by at least two different network points connected with non-ideal
backhaul (Scenario 2).
• Strong Interference from macro on the same carrier is not present.
• Signalling overhead towards the CN can potentially be saved by keeping the mobility
anchor in the macro cell.
• Inter-node resource aggregation is used to improve per-user throughput.
3GPP TR 36.842: "Study on Small Cell enhancements for E-UTRA and E-UTRAN; Higher layer aspects"
General Introduction of Rel-12 Dual Connectivity
• E-UTRAN supports Dual Connectivity (DC) operation whereby a multiple RX/TX
UE in RRC_CONNECTED is configured to utilise radio resources provided by two
distinct schedulers, located in two eNBs connected via a non-ideal backhaul over
the X2 interface.
• eNBs involved in DC for a certain UE may assume two different roles: an eNB may
either act as an MeNB or as an SeNB.
• MeNB: Master eNB
• In dual connectivity, the eNB which terminates at lease
S1-MME.
• SeNB: Secondary eNB
• In dual connectivity, the eNB that is providing additional
radio resources for the UE, but is not the Master eNB.

• In DC, a UE is connected to one MeNB and one SeNB.
• MCG (Master Cell Group): a group of serving cells associated with the MeNB,
comprising of the PCell and optionally one or more SCells.
• SCG (Secondary Cell Group): a group of serving cells associated with the SeNB,
comprising of PSCell and optionally one or more Scells
• At least one cell in SCG has a configured UL CC and one of them, named PSCell, is
configured with PUCCH resources.
• When SCG is configured, there is always at least one SCG bearer or one Split bearer.
• PSCell cannot be de-activated.

• Interaction between MeNB and SeNB
• The MeNB maintains the RRM measurement configuration of the UE.
• In the case of the SCG addition and SCG SCell addition, the MeNB may provide the latest
measurement results for the SCG cell(s)
• Upon receiving the request from the MeNB, a SeNB may create the container that
will result in the configuration of additional serving cells for the UE (or decide that it
has no resource available to do so).
• For UE capability coordination, the MeNB provides (part of) the AS- configuration
and the UE capabilities to the SeNB. (UE Capabilities Negotiation)
• The SeNB decides which cell is the PSCell within the SCG.
• The MeNB does not change the content of the RRC configuration provided by the
SeNB.
• When adding a new SCG SCell, dedicated RRC signalling is used for sending all
required system information of the cell as for CA, except for the SFN acquired from
MIB of the PSCell of SCG. (System Information Update in DC for serving cell is similar
to that in CA)
Overall Architecture – Control Plane
• Inter-eNB control plane signalling for DC is performed by means of X2 interface
signalling for coordination.
• From MeNB to SeNB: SCG-ConfigInfo
• From SeNB to MeNB: SCG-Config
• Control plane signalling towards the MME is performed by means of S1 interface
signalling.
• There is only one S1-MME connection per DC UE
between the MeNB and the MME.

Overall Architecture – Control Plane
• Each eNB involved in DC for a certain UE controls its radio resources and is
primarily responsible for allocating radio resources of its cells.
• For a UE configured with DC, all RRC messages, regardless of the SRB used and
both in downlink and uplink, are transferred via the MCG.
X2

Overall Architecture – User Plane
• In DC, the radio protocol architecture that a particular bearer uses depends on
how the bearer is setup.
• U-plane connectivity depends on the bearer option configured:
• MCG bearers
• Split bearers Neither direct bearer type
change between Split bearer
• Re-ordering Function in PDCP, Flow control between MeNB and SeNB
and SCG bearer nor
• SCG bearers simultaneous configuration of
SCG and Split bearer are
supported.
MCG bearer SCG bearer
Split bearer

SeNB Addition
UE MeNB SeNB S-GW MME
1. SeNB Addition Request

(carry SCG-ConfigInfo)
2. SeNB Addition Request Acknowledge

(carry SCG-Config)
3. RRCConnectionReconfiguration
4. RRCConnectionReconfigurationComplete
5. SeNB Reconfiguration Complete
6. Random Access Procedure
7. SN Status Transfer
8. Data Forwarding
Path Update procedure

9. E-RAB Modification Indication
10. Bearer Modication
11. End Marker Packet
12. E-RAB Modification Confirmation

SeNB Addition

Receive SeNB
UE perform 2. SeNB Addition Request Acknowledge
(carry SCG-Config) PRB utilization
Measurement 3. RRCConnectionReconfiguration
rate for
Based on 4. RRCConnectionReconfigurationComplete
assessment
MeNB’s 6. Random Access Procedure
configuration
8. Data Forwarding


SeNB Addition
Step 1: The MeNB decides to request
(carry SCG-ConfigInfo) the SeNB to allocate radio resources
for a specific E-RAB. MeNB indicates
within SCG-ConfigInfo the MCG
(carry SCG-Config)
configuration and the entire UE
capabilities for UE capability
coordination to be used as basis for
6. Random Access Procedure the reconfiguration by the SeNB, but
does not include SCG configuration.
7. SN Status Transfer The MeNB can provide the latest
8. Data Forwarding measurement results for the SCG
cell(s) requested to be added. The
Path Update procedure SeNB may reject the request.

SeNB Addition


(carry SCG-Config)
Step 2: The SeNB triggers Random
Access so that synchronisation of the
SeNB radio resource configuration can
6. Random Access Procedure be performed. The SeNB provides the
new radio resource of SCG in SCG-
7. SN Status Transfer Config to the MeNB
8. Data Forwarding


SeNB Addition


(carry SCG-Config)
Step 3: If the MeNB endorses the new
configuration, the MeNB sends the
RRCConnectionReconfiguration
6. Random Access Procedure message to the UE including the new
radio resource configuration of SCG
7. SN Status Transfer according to the SCG-Config.
8. Data Forwarding


SeNB Addition

Step 4: The UE applies the new
configuration and replies with
2. SeNB Addition Request Acknowledge RRCConnectionReconfigurationComple
(carry SCG-Config)
3. RRCConnectionReconfiguration te message.
4. RRCConnectionReconfigurationComplete In case the UE is unable to comply
5. SeNB Reconfiguration Complete with (part of) the configuration
included in the
RRCConnectionReconfiguration
8. Data Forwarding
message, it performs the
reconfiguration failure procedure.

SeNB Addition


(carry SCG-Config)
4. RRCConnectionReconfigurationComplete Step 5: The MeNB informs the SeNB

5. SeNB Reconfiguration Complete that the UE has completed the
reconfiguration procedure successfully
8. Data Forwarding


SeNB Addition


(carry SCG-Config)
Step 6: UE performs the Random
6. Random Access Procedure Access procedure towards the SCG
8. Data Forwarding


SeNB Addition
Split Bearers
SCG Bearers

Support of Uplink Bearer Split in Rel-13 DC
• ul-DataSplitThreshold is not configured (Rel-12 Behaviour)

Support of Uplink Bearer Split in Rel-13 DC
• ul-DataSplitThreshold is configured (Rel-13 Behaviour)

LTE-NR Tight Interworking Deployment Scenarios
• LTE-NR aggregation for tight interworking
• In terms of CN-RAN connection
• NR tightly integrated in LTE via EPC
• LTE tightly integrated in NR via NextGen Core
• NR tightly integrated in LTE via NexGen Core

LTE-NR Tight Interworking Deployment Scenarios
• New Bearer Type to be considered
• Split bearer via SCG
• In this bearer type, C-plane connection is served by a master node (MeNB or
MgNB) while U-plane data for the same bearer is delivered by leveraging radio
resources across a master node and a secondary node via SCG.
S1 or NG3 NG3
Xn Xn
PDCPLTE PDCPNR PDCPNR PDCPLTE
RLCLTE RLCLTE RLCNR RLCNR RLCNR RLCLTE
MACLTE MACLTE MACNR MACNR MACNR MACLTE
MeNB (LTE) SgNB (NR) MgNB (NR) SeNB (LTE)

Control Plane Options for Tight Interworking
• Option C1: Only the MeNB generates the final RRC messages to be sent towards the UE after the
coordination of RRM functions between MeNB and SeNB. The UE RRC entity sees all messages
coming only from one entity (in the MeNB) and the UE only replies back to that entity.
• Option C2: MeNB and SeNB can generate final RRC messages to be sent towards the UE after the
coordination of RRM functions between MeNB and SeNB and may send those directly to the UE
and the UE replies accordingly.
Control Plane Control Plane
Option 1 Option 2
MeNB MeNB
Anchor
RRC
RRC
Xn Xn
SeNB
SeNB
Uu Uu
Assisting
RRC
UE UE
Uu
Uu
RRC RRC

Comparison aspect Option C1 Option C2
NR RRC message MeNB prepares the LTE RRC message SNG-NB prepares the NR RRC message including NR
configuration including NR configuration. configuration.
Signalling latency Additional latency to transport the SNG- No additional latency for direct signalling when the
NB configuration over X2-link interface messages are sent over the NG1 interface provided
and encoding using the LTE RRC format. by SNG-NB.
Measurement control and LTE RRC controls measurement NR specific measurements could be reported to NR
reporting configuration and reporting for NR. RRC directly.
Coordination with M-RRC LTE RRC validates the NG configuration LTE RRC may not validate the NG Configuration.
and generates the LTE RRC message Coordination is still needed between LTE RRC and NR
RRC.
Overall view LTE RRC needs to adapt to NR RRC NR RRC is isolated with respect to LTE RRC allowing
changes, not allowing LTE RRC and NR independent evolution of both these protocols. In
RRC to evolve independently addition, this model allows more flexible operation
compared to Option 1 and may benefit from lower
latency on the NR interface for control plane
configurations. Finally, the model is also flexible to
support tight interworking where NR is the anchor.
工研院版權所有 Copyright©2016 ITRI. All rights reserved. Reference: R2-163511 45
• Agreements
• UE has a single RRC state machine based on the master, and single control plane
connection to CN.
• Network has two RRC entities that can generate ASN.1.
• ASN.1 generated by the secondary can be transported by the master (at least in
some cases, e.g. for first configuration).
• Some coordination is required between LTE (respectively NR) master node and NR
(respectively LTE) secondary node.
• LTE (respectively NR) master node should not need to modify or add to the NR
(respectively LTE) configuration of the UE.
• From a RAN2 perspective, we aim to have an independent capability information for
NR and LTE (meaning that node of one RAT does not need to look at the capabilities
of the other RAT). Does not preclude that capabilities of one RAT might contain some
information related to the other RAT (e.g. at least measurement capabilities)
• FFS
• Is ASN.1 generated by one node transparent (no necessity for the master to
understand the ASN.1 generated by the secondary) to the other node?
• Whether UE capabilities are involved in the coordination?
• Whether LTE (respectively NR) master node should not be required to understand NR
(respectively) configuration of the UE?
• Can NR and LTE generate final RRC messages?
• Can secondary send messages directly to UE over the secondary radio (e.g. an SRB
on the secondary)?
• Can messages generated by master node can be transported over the secondary
radio?
• Can a single message generated by master/secondary node can be transported over
both master and secondary radio?

• Solutions on the table:
• Alternative 1:
• SCG configuration is transparent to MCG. Any coordination necessary is done using XN2
signalling. (Rely on the interface between the nodes.)
• Alternative 2:
• SCG configuration is always understood by MCG and vice versa (similar to LTE DC).
• Alternative 3:
• Parts of the SCG configuration is transparent to MCG.
• Alternative 4:
• Coordination is done in UE, e.g., hard capability split.

NR Architecture Design

NR Architecture
• CU: Central Unit
• DU: Distributed Unit
• As in LTE, NR shall study lower layer aggregation (e.g. CA-like) and upper layer
aggregation (e.g. DC-like)
NR Architecture
• NR eNB corresponds to 1 or many TRPs.
NR Architecture
• What is the definition of 5G NR Cell?
• Still under discussion
Mobility
• In LTE, xSS based mobility is used for inter-cell mobility. The xSS contains the cell-
id (PCI), and the UE reports the PCI together with the cell quality determined
based on CRS.
• In LTE, RS-set based mobility is used in COMP scenario 4 (intra-cell). The UE
measures on the configured RE’s, which could contain UE dedicated or common
RS, and reports the measured quality.
• RAN2 understanding of RAN1 agreement: There is an "xSS" (similar as LTE cell
specific RS). On the "xSS" there is at least a NR Cell Id. The xSS is at least used in
idle.
Mobility
• Two levels of network controlled mobility:
• 1: RRC driven at 'cell' level.
• 2: Zero/Minimum RRC involvement (e.g. at MAC /PHY)
NR Protocol Functions
Protocol Legacy U-plane functions
IP header compression and encryption of user data

(security)
PDCP In-order delivery to upper layer and duplicate detection
Packet-level retransmissions across links (upon connection
re-establishment)
Concatenation
RLC Segmentation and reassembly
In-order delivery to upper layer and duplicate detection
Byte-level retransmissions (AM only)
Priority handling between logical channels
MAC Concatenation, (De)multiplexing of MAC SDUs and
padding
1. Study whether a single packet reordering function is possible.
2. Study whether segmentation function can be configured (enabled/disabled) to support
different services.
3. Study whether concatenation function can be moved to lowest L2 sublayer.
4. Study whether retransmission of PDU segments can be removed (i.e. only complete PDU level
retransmission).
New RRC State
• Connected State
• Data Transmission/Reception
• IDLE State
• Power Saving
• Transition between IDLE State and Connected State result in singalling overhead
and long transmission delay.

New RRC State

New RRC State
• Connected State
• Data Transmission/Reception
• IDLE State
• Power Saving
• New RRC State (e.g., Inactive State)
• The connection (both CP and UP) between RAN and Core should be maintained in
the “new state”.
• For the UE in the “new state”, a RAN initiated notification procedure should be
used to reach UE. And the notification related parameters should be configured by
RAN itself.
• For the UE in the “new state”, RAN should be aware whenever the UE moves from
one “RAN-based notification area” to another.

New RRC State
UE eNB MME SGW
1. RA msg1
2. RA response msg2
3. RA msg3 S1-C kept

RRC resume request
4. RRC connection resume S1-U kept
5. RRC connection
resume complete
6. UL data
7. DL data

New RRC State
• RAN-based notification area
New RRC State
• RAN initiated notification
New RRC State
Potential Design for State Transition
e.g. Expiration of RAN PA Update timer + reselection to

TRP/cell not in configuration, reselection failure, power off.

New RRC State
• Further Consideration
• The overall procedure/singnalling for state transition is still under discussion.
• How the RAN-initiated notification will be transmitted (e.g. via a beam, broadcast, etc)
• The overall RAN-initiate notification procedure is still under discussion.
• How CN location updates and RAN updates interact, if needed?
• Study the possibility for the UE to perform data transmission without state transition from
the 'new state' to full connected.

QoS Framework
• For DL for a non-GBR flow, the eNB sees an indication over NG-u and based on
the indication the eNB maps the packet to a DRB of an appropriate QoS.
• RAN2 understanding of SA2 agreements is that eNB has a QoS profile
associated with the indication.
• Functionality is required to differentiate flows from different PDN-connections
over the radio interface (e.g. by using separate DRBs or by an explicit indication
in a header)
• For DL, the eNB establishes DRBs for the UE taking the QoS profiles in to
account.

Thanks
[email protected]

5 G

Uploaded by

Copyright:

Available Formats

5 G

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5 G

Uploaded by

Copyright:

Available Formats

5G-NR (New Radio) in 3GPP from RAN2

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 1

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 2

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 3

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 4

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 7

10 Mbit/s/m2 area traffic 3 times higher compared

up to 106 /km2 in massive machine

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 9

Latency Low Not much considered Very Low

Mobility 0km/h to 500km/h Not much considered Not much considered

Power Not much considered Very Low Not much considered

Connection High Very High High

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 10

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 11

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 12

LTE (macro cell)

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 13

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 14

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 15

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 16

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 17

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 18

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 19

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 21

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 22

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 25

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 26

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 28

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 29

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 30

1. SeNB Addition Request

2. SeNB Addition Request Acknowledge

Path Update procedure

12. E-RAB Modification Confirmation

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 31

1. SeNB Addition Request

Path Update procedure

12. E-RAB Modification Confirmation

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 32

12. E-RAB Modification Confirmation

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 33

1. SeNB Addition Request

2. SeNB Addition Request Acknowledge

Path Update procedure

12. E-RAB Modification Confirmation

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 34

1. SeNB Addition Request

2. SeNB Addition Request Acknowledge

Path Update procedure

12. E-RAB Modification Confirmation

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 35

1. SeNB Addition Request

12. E-RAB Modification Confirmation

工研院版權所有 Copyright©2016 ITRI. All rights reserved. 36

1. SeNB Addition Request

2. SeNB Addition Request Acknowledge

4. RRCConnectionReconfigurationComplete Step 5: The MeNB informs the SeNB

Path Update procedure