Patent Publication Number: US-11039354-B2

Title: Secondary node change signaling in future radio networks

Description:
RELATED APPLICATIONS 
     This application is a continuation of prior U.S. application Ser. No. 16/346,903, filed 2 May 2019, which was the National Stage of International Application PCT/EP2017/078181 filed 3 Nov. 2017, which claims the benefit of U.S. Provisional Application No. 62/417,724, filed 4 Nov. 2016, the entire disclosure of each being hereby incorporated by reference herein. 
    
    
     TECHNICAL FIELD 
     Disclosed herein are embodiments for handling a transfer of a User Equipment, UE, context within a secondary network from a source secondary network node to a target secondary network node; especially a transfer is considered for Long Term Evolution-New Radio interworking. 
     BACKGROUND 
     The Third Generation Partnership Project (3GPP) has started work on the development and design of the next generation mobile communications system (a.k.a., the 5G mobile communication system or simply “5G” for short). 5G will encompass an evolution of today&#39;s 4G networks and the addition of a new, globally standardized radio access technology known as “New Radio” (NR). 
     The large variety of requirements for NR implies that frequency bands at many different carrier frequencies will be needed. For example, low bands will be needed to achieve sufficient coverage and higher bands (e.g. Millimeter Wave, mmW, such as near and above 30 GHz) will be needed to reach the required capacity. At high frequencies, the propagation properties are more challenging and high order beamforming at the base station (e.g., evolved NodeB, eNB, or NR NodeB, gNB) will be required to reach sufficient link budget. For example, narrow beam transmission and reception schemes may be needed at higher frequencies to compensate the high propagation loss. For a given communication link, a beam can be applied at the transmission point (TRP) (i.e., a transmit (TX) beam) and a beam can be applied at the user equipment (UE) (i.e., a receive (RX) beam)), which collectively is referred to as a “beam pair link” (BPL) or just “link” for short. 
     NR will have a beam centric design, which means that the traditional cell concept is relaxed and user equipments (UEs) (fixed or mobile wireless communication devices) will in many cases be connected to and perform “handover” between narrow beams instead of cells. Hence, 3GPP has agreed to study concepts for handling mobility between beams (both within and between transmission points (TRPs)). In the following, such mobility will also be referred to as beam based mobility; the potentially high number of mobility beams will make handover much more complex that of LTE; e.g. it may be unfeasible for the UE to perform power measurement of all possible beams; instead of this there may be a preselection in the network of best suitable beams to be measured by the UE. 
     Overall requirements for the Next Generation (NG) architecture (see TR 23.799, Study on Architecture for Next Generation, which is incorporated herein by reference in its entirety) and, more specifically the NG Access Technology (see TR 38.913, Study on Scenarios and Requirements for Next Generation Access Technologies, which is incorporated herein by reference in its entirety) may impact the design of 5G (see RP-160671, New SID Proposal: Study on New Radio Access Technology, DoCoMo, which is incorporated herein by reference in its entirety) from mobility to control plane design and mechanisms. 
     SUMMARY 
     It is an object to design basic radio resource management (RRM) functions, such as mobility handling among Long Term Evolution (LTE) (e.g. Evolved Node B (eNB)), NR Radio nodes (e.g. gNB) entities, and user equipments. 
     This object is achieved by the independent claims. Advantageous embodiments are described in the dependent claims and by the following description. 
     Embodiments relate to the secondary node change and the reconfiguration of a new secondary node where the RRC protocol(s) of the source secondary node and/or target secondary node are partially in charge of the secondary node change. Advantages of the proposed embodiments may include minimization of the specification of NR related mobility measurement configurations and procedures in LTE specifications and vice versa by distributing mobility management/control between MeNB and SgNB or MgNB and SeNB in case of LTE-NR interworking. An additional benefit is the LTE eNB does not need to implement NR related mobility procedures and algorithms. 
     According to one aspect a method performed by a source secondary network node to transfer a User Equipment context from the source secondary network node to a target secondary network node that is different than the source secondary network node is provided. The method comprises: transmitting, by the source secondary network node, a first message to the target secondary network node, wherein the target network node is configured to respond to the first message by transmitting to the source secondary network node a second message comprising configuration data of the target secondary network node; receiving, at the source secondary network node, the second message transmitted by the target secondary network node; and after receiving the second message, initiating a transfer of the UE context from the source secondary network node to the target secondary network node, wherein initiating the transfer of the UE context comprises transmitting, by the source secondary network node, to a master network node a third message comprising the configuration data of the target secondary network node. 
     In some embodiments, the first message comprises a Handover Request message, the Handover Request message instructing the target secondary network node to perform one or more configuration actions. 
     In some embodiments, the second message comprises a Handover Response message. 
     In some embodiments, the configuration data comprises one of: a radio resource control (RRC) protocol data unit (PDU) or an information element. 
     In some embodiments, the method further comprises receiving, at the source secondary network node, a fourth message transmitted by the master network node, the fourth message comprising a Release Request, wherein the master network node is configured to transmit the fourth message after receiving the third message. 
     In some embodiments, the source secondary network node comprises a first New Radio Node, the target secondary network node comprises a second New Radio Node, and the master network node comprises an Evolved Node B. 
     In some embodiments, the source secondary network node comprises a first Evolved Node B, the target secondary network node comprises a second Evolved Node B, and the master network node comprises a New Radio Node. 
     In another aspect, a source secondary network node is provided, the source secondary network node comprising a transmitter, a receiver, a memory, and a data processing system comprising one or more processors, wherein the source secondary network node is configured to perform the methods described above. 
     In yet another aspect, a method performed by a master network node to transfer a User Equipment context from a source secondary network node to a target secondary network node that is different than the source secondary network node is provided. The method comprises: receiving, at the master network node, a first message transmitted by the source secondary network node, the first message comprising a request to initiate a transfer of the UE context from the source secondary network node to the target secondary network node; in response to the request, transmitting, by the master network node, a second message to the target secondary network node; and receiving, by the master network node, a third message from the target secondary network node, the third message comprising configuration data of the target secondary network node. 
     In some embodiments, the method further comprises transmitting, by the master network node, a fourth message to the source secondary network node, the fourth message comprising an acknowledgement of the request. In some embodiments, the method further comprises transmitting, by the master network node, a fifth message to the source secondary network node, the fifth message comprising a Release Request. 
     In some embodiments, the method further comprises: in response to receiving the third message, transmitting a sixth message to the User Equipment, the sixth message comprising a RRCConnectionReconfiguration message; and receiving a seventh message from the User Equipment, the seventh message comprising a RRCConnectionReconfiguration Complete. In some embodiments, in response to receiving the seventh message, the master network node transmits, to the target secondary network node, an eighth message, the eighth message comprising a Reconfiguration Complete. 
     In some embodiments, the first message comprises a Change Request. 
     In some embodiments, the configuration data of the target secondary network node comprises one of: a radio resource control (RRC) protocol data unit (PDU) or an information element. 
     In some embodiments, the source secondary network node comprises a first New Radio Node, the target secondary network node comprises a second New Radio Node, and the master network node comprises an Evolved Node B. 
     In some embodiments, the source secondary network node comprises a first Evolved Node B, the target secondary network node comprises a second Evolved Node B, and the master network node comprises a New Radio Node. 
     In yet another aspect, a master network node is provided, the master network node comprising a transmitter, a receiver, a memory, and a data processing system comprising one or more processors, wherein the master network node is configured to perform the foregoing methods. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Further details of embodiments are described with reference to the drawings, wherein: 
         FIG. 1  illustrates an exemplary wireless communications system according to some embodiments. 
         FIG. 2  illustrates a prior art signaling diagram. 
         FIG. 3  illustrates a prior art signaling diagram. 
         FIG. 4  illustrates a prior art signaling diagram. 
         FIG. 5  illustrates a prior art signaling diagram. 
         FIG. 6  illustrates a signaling diagram according to some embodiments. 
         FIG. 7  illustrates a signaling diagram according to some embodiments. 
         FIG. 8  illustrates an exemplary flow chart according to some embodiments. 
         FIG. 9  illustrates an exemplary flow chart according to some embodiments. 
         FIG. 10  is a block diagram of a secondary network node according to some embodiments. 
         FIG. 11  is a block diagram of a master network node according to some embodiments. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  illustrates an exemplary wireless communications system according to some embodiments. Wireless communications system  100  may comprise a User Equipment  105  (i.e., fixed or mobile wireless communication device) and one or more base stations, including a master radio resource control (RRC) network node  120 , and a plurality of secondary RRC network nodes  110 A-B. In some embodiments, the master network node  120  and the secondary network nodes  110 A-B are further in communication with a core network  130 . In some embodiments, the master network node  120  may comprise a master Evolved Node B as known in LTE networks (referred to herein as MeNB), and the secondary network nodes  110 A-B may comprise secondary New Radio (NR) RRC entities for the next generation/5G access technologies (referred to herein as SgNB). In other embodiments, the master network node  120  may comprise a master NR network node (referred to herein as MgNB) and the secondary network nodes  110 A-B may comprise secondary eNBs (referred to herein as SeNB). 
     In some embodiments, the master network node  120  may serve the UE  105  as indicated by link  115 A. In some embodiments, a secondary network node  110 A-B may further provide additional resources for the UE  105 , such as serving cells. For example, a secondary network node  110 A-B may provide additional resources based on a received measurement report, traffic conditions, or bearer types. Thus, in some embodiments, UE  105  may be served by both a master network node  120  and a source secondary network node  110 A, as illustrated by links  115 A and  115 B. However, in some embodiments, it may be desirable to switch from the source secondary network node  110 A to a target secondary network node  110 B, in which case the UE may be served by both the master network node  120  and the target secondary network node  110 B after a secondary network node transfer, as illustrated by links  115 A and  115 C. 
     LTE Dual Connectivity 
     In LTE Dual Connectivity (DC), thanks to the mutual intelligibility between master and secondary network nodes (MeNB  120  and SeNB  110 A), the MeNB  120  is able to maintain the RRM measurement configuration of the UE  105  for mobility procedures. Furthermore, the MeNB  120  may decide to ask a SeNB  110 A to provide additional resources (serving cells) for a UE  105  e.g., based on the received measurement reports or traffic conditions or bearer types as it is straightforward the interpret those by the RRC entity located at the master network node  120 . Therefore, the mobility can mainly be coordinated by the MeNB  120  in case of LTE DC. 
       FIGS. 2-5  are prior art signaling diagrams for LTE DC based on 3GPP TS 36.300, which is incorporated by reference herein in its entirety. As illustrated in  FIG. 2 , the SeNB Addition procedure for LTE DC is initiated by the MeNB  120  and is used to establish a UE context at the SeNB  110 A in order to provide radio resources from the SeNB  110 A to the UE  105 . This procedure is used to add at least the first cell, i.e., PSCell of the Secondary Cell Group (SCG) in case of LTE DC. As shown in  FIG. 2 , the MeNB  120  may transmit a first message  201 , which is a SeNB Request (carry SCG-ConfigInfo) message. The SCG-ConfigInfo may include the MeNB  120  configuration and the entire UE  105  capabilities for UE capability coordination to be used as a basis for the reconfiguration by the SeNB. Next, the SeNB  110 A may transmit a second message  203 , which is a SeNB Addition Request Acknowledge (Carry SCG-Config) message. The SCG-Config may include the new radio resource of SCG, including radio configuration information and data forwarding address information (if applicable). Next, to perform the handover, the MeNB  120  may transmit a third message  205  to the UE  105 , which is a RRCConnectionReconfiguration message. Next, the UE  105  may transmit a fourth message  207  back to the MeNB  120 , the fourth message comprising a RRCConnectionReconfigurationComplete message. Finally, the MeNB  120  may transmit a fifth message  209  to the SeNB  110 A comprising a Reconfiguration Complete message. 
       FIGS. 3-4  illustrate a SeNB  110 A release procedure for LTE DC. The SeNB Release procedure may be initiated either by the MeNB  120  or the SeNB  110 A and is used to initiate the release of the UE context at the SeNB. The recipient node of this request cannot reject. The SeNB Release procedure does not necessarily need to involve signaling towards the UE, e.g., RRC reconnection re-establishment due to Radio Link Failure in MeNB  120 .  FIG. 3  illustrates a release procedure initiated by the MeNB  120 , and  FIG. 4  illustrates a release procedure initiated by the SeNB  110 A. As shown in  FIG. 3 , the MeNB  120  initiates the release procedure of the SeNB  110 A by transmitting a first message  301  to the SeNB  110 A, the first message being a SeNB Release Request. The SeNB Release Request may trigger the source SeNB  110 A to stop providing user data to the UE  105 , and if applicable, to start data forwarding. The MeNB  120  then transmits message  303  to the UE  105  comprising a RRC ConnectionReconfiguration, and the UE responds and transmits message  305  to the MeNB  120  confirming RRCConnectionReconfiguration Complete. As shown in  FIG. 4 , the SeNB  110 A initiates the release procedure by transmitting a first message  401  to the MeNB  120  comprising a SeNB Release Required. The MeNB  120  then transmits message  403  to the SeNB  110 A comprising a SeNB Release Confirm. The MeNB  120  then transmits message  405  to the UE  105  comprising a RRC ConnectionReconfiguration, and the UE responds and transmits message  407  to the MeNB  120  confirming RRCConnectionReconfiguration Complete. 
       FIG. 5  illustrates how a SeNB change procedure may be initiated by a MeNB  120  and used to transfer a UE context from a source SeNB  110 A to a target SeNB  110 B, as well as change the SCG configuration in the UE from the source SeNB  110 A to the target SeNB  110 B. As shown in  FIG. 5 , the LTE SeNB change procedure may be initiated by a MeNB  120  transmitting message  501 , a SeNB Addition Request, towards a target SeNB  110 B via the source SeNB  110 A. In response, the target SeNB  110 B may transmit message  503 , a SeNB Addition Request Acknowledgement towards the MeNB  120  via the source SeNB  110 A. The MeNB  120  may transmit message  505 , a SeNB Release Request, to the source SeNB  110 A, which the recipient SeNB  110 A cannot reject. The MeNB  120  may then transmit message  507 , a RRCConnectionReconfiguration message towards the UE  105 , and in response receive message  509 , a RRCConnectionReconfigurationComplete message from the UE  105 . The MeNB  120  may further send message  511 , a SeNB Reconfiguration Complete message towards the target SeNB  110 B. 
     Secondary Node Configuration in Case of LTE-NR Interworking 
     In case of secondary node modification, or node change, or release procedures, the master node may not necessarily maintain the radio resource management, RRM, measurement configuration of the UE for the secondary node, but may only generate a final RRC message. The RRC message transmitted from the master node may contain the RRC PDU which is of an RRM measurement configuration prepared by the RRC entity in the secondary node. Whether the master node needs to understand the RRM measurement configuration or not may be left to the implementation. 
     In case of secondary node modification, node change, or release procedures, the RRM measurement report related to the mobility within the secondary node(s) may be received by the master node (RRC entity of the master node) a final RRC message. In a first option, the master node, without needing to parse the information, may transfer the NR part of the RRC message including the RRM measurement report, e.g., over X2* interface, to the secondary node (e.g. to the RRC entity located in the secondary node), e.g. by means of a container. In a second option, if a direct SRB is allowed between the secondary node and UE, the measurement report may be sent directly between the UE and the secondary node. 
       FIGS. 5 and 6  show two options, e.g. called option A and option B, for the secondary node change and the reconfiguration of a new secondary node, wherein the RRC protocol of a secondary node is partially in charge of the secondary node change. 
     In both Options, different from LTE DC, secondary node change (SgNB) may be initiated by the secondary node (e.g. S-SgNB) instead of the master node (MeNB). As NR mobility is expected to be different from mobility in LTE, the mobility algorithms may cope with the beam based mobility. 
     In Option A, not all the secondary node (SgNB) change signaling has to go through the master node (MeNB), whereas in Option B, all the signaling relevant to secondary node (SgNB) change goes via the master node (MeNB), allowing it to understand all the signaling steps; it may depend on the implementation, how deep the master node shall understand the signalling. In either case, if the procedure is not intercepted by master node (MeNB), the target secondary node (e.g. T-SgNB), configuration info e.g., NR-Configuration Information (or briefly NR-Config Info), is sent to the UE via a final RRC message from MeNB. 
     Thus, target secondary node configuration info (T-SgNB NR-Config Info) may be (completely or partially) transparent to the MeNB that sends such configuration information to the UE in a final LTE RRC message. 
     LTE-NR Secondary Network Node Change 
     RRC diversity may be envisioned for both the downlink and uplink to address aforementioned challenges e.g. related to Ultra-Reliable and Low Latency Communications (URLLC) and mobility robustness. 
     NR RRM is expected to be different than LTE RRM due to above-discussed beam based mobility. Especially NR RRM measurement configuration, measurement reporting events and triggers may be rather different than those already specified for LTE mobility. It may e.g. be preferable keeping the LTE and NR RRMs self-contained, e.g. to enable a future-proof NR RRM design e.g., when NR stand-alone operation is considered. 
     In the following, it is described an exemplary set of embodiments related to the secondary network node change and the reconfiguration of a new secondary network node where the RRC protocol(s) of the source secondary network node and/or target secondary network node are partially in charge of the secondary network node change. Minimization of the specification of NR related mobility measurement configuration in LTE specifications and vice versa may be achieved by distributing mobility management/control between MeNB  120  and SgNB  110 A-B (or MgNB  120  and SeNB  110 A-B) in case of LTE-NR interworking 
     The disclosure proposes two major options for the secondary network node change and the reconfiguration of a new secondary network node where the RRC protocol(s) of the source secondary network node and/or target secondary network node are partially in charge of the secondary network node change as shown in  FIGS. 6-7 . These options are different from LTE DC, as described above, because, for example, the SgNB Change is initiated by the S-SgNB  110 A instead of the MeNB  120 . Additionally, in both options, the target SgNB configuration may be transparent to the MeNB. It may be desirable for the SgNB change to be initiated by the S-SgNB  110 A since NR mobility is expected to be different than LTE and the mobility algorithms may be beam based mobility. It may be expected that the entity deciding NR mobility may reside in the NR part of the 5G RAN, i.e., within a gNB, which may include knowledge about NR radio resource topology in the neighborhood, current NR radio resource status, and controlling and processing NR related UE measurements. The procedures described below proposes a solution where the LTE and NR related logical nodes of the 5G RAN are distinct, separate logical entities, inter-connected via an interface that is called “X2*.” 
     First, the master network node  120 , such as the MeNB  120  in  FIG. 6 , determines one or more suitable candidates to be the SgNB. This may be based on downlink (DL) measurements or uplink (UL) measurements. 
     In the case of a DL measurement based procedure, the SgNB determines the suitable measurement configuration for the UE including suitable inter-frequencies to measure. In addition, need of measurement gaps can be determined based on the UE capability. The SgNB constructs the measurement (RRC) configuration. The configuration is sent to the UE either directly or via MeNB. The first solution is only possible if the direct SRBs between SgNB and UE are supported. In the latter solution, MeNB sends the final RRC message to the UE. After the UE has measured potential candidates for new SgNB, the UE sends a measurement report to the network. This may be sent to the SgNB directly in case SRB between UE and SgNB is supported. If the measurement report is sent to the MeNB, the MeNB forwards the measurement results to the SgNB via X2 or X2*. 
     In the case of UL measurement based procedure, the decision to change SgNB may be performed in the original SgNB. The UE may be potentially configured with UL signal to be used for mobility. The signal may be similar to SRS. Depending on the solution, the UL signal configuration can be sent via RRC to the MeNB or SgNB directly. The SgNB can directly receive UL signal from the UE, and based on that determine suitable candidate(s) for the SgNB change. In cases where the MeNB receives the UL signal, the MeNB may forward the measurement result to the SgNB. Once the target SgNB is determined, the signaling to change the SgNB takes place as described below in connection with  FIG. 6 . 
     As shown in  FIG. 6 , the SgNB change is initiated by the S-SgNB  110 A sending message  601 , a SgNB Handover Request message, to T-SgNB  110 B without passing it through the MeNB  120 . NR-Config information included within the Handover Request  601  message may be used by the S-SgNB  110 A to request the T-SeNB  110 B to perform certain configuration actions, similar to those performed via LTE SCG-ConfigInfo and/or Handover Request in LTE. Next, the T-SgNB  110 B replies back to the S-SgNB  110 A with message  603 , a SgNB Handover Response message including the NR configuration e.g., NR-Config. NR-Config may include the new radio resource associated with the T-SgNB  110 B. The S-SgNB  110 A then sends message  605  with the NR-Config information to MeNB  120 . Message  605  may be an X2* AP message, called SgNB Change Request in  FIG. 6 , in order to enable the RRC reconfiguration of the UE  105  with the T-SgNB  110 B. The same X2* AP message  605  may include information on the user plane switch so as to be able to successfully execute the SgNB change and activate user plane data flow toward UE  105 . The NR configuration message (e.g., NR-Config), may be used to transfer the radio configuration generated by the T-SgNB  110 B. Upon receiving the NR configuration via message  605 , the MeNB  120  may (i) intercept, and send message  607 , a SgNB change reject to the S-SgNB  110 A, which in turn sends message  609 , SgNB Change Reject to the T-SgNB  110 B, or (ii) proceed by transmitting message  611 , a SgNB Release Request, to the S-SgNB  110 A. In the second case, the MeNB  120  may perform RRC Connection Reconfiguration steps, including transmitting message  613 , a RRCConnectionReconfiguration message, to the UE  105 , the UE  105  transmitting message  615 , a RRCConnectionReconfigurationComplete message, to the MeNB  120 , and the MeNB  120  transmitting message  617 , a SgNB Reconfiguration Complete message, to the T-SgNB  110 B to complete the SgNB transfer procedure. 
       FIG. 7  illustrates a second signaling diagram according to some embodiments. As shown in  FIG. 7 , the SgNB change procedure is initiated by the S-SgNB  110 A, but the signaling goes via the MeNB  120 . The S-SgNB  110 A initiates the SgNB change procedure by transmitting message  701 , a SgNB Change Request with NR Config Info message, to the MeNB  120 . The MeNB  120  may then reject the SeNB change by transmitting message  703 , a SgNB Change Reject message, or proceed with the change by transmitting message  705 , a SgNB Addition Request (include NR-Config Info) message, towards the T-SgNB  110 B. In the latter case, the T-SgNB  110 B may respond to message  705  by transmitting towards the MeNB  120  message  707 , a SgNB Addition Request Acknowledgement message, which includes the NR-Config Info for the T-SgNB  110 B. In response to message  707 , the MeNB  120  may transmit message  711 , a SgNB Change Request Acknowledgement (include NR-Config Info) to the S-SgNB  110 A, as well as transmit message  713 , a SgNB Release Request message, to the S-SgNB  110 A. The MeNB  120  may perform RRC Connection Reconfiguration steps, including transmitting message  715 , a RRCConnectionReconfiguration message, to the UE  105 , the UE  105  transmitting message  717 , a RRCConnectionReconfigurationComplete message, to the MeNB  120 , and the MeNB  120  transmitting message  719 , a SgNB Reconfiguration Complete message, to the T-SgNB  110 B to complete the SgNB transfer procedure. 
     Depending on the implementation and which messages the MeNB  120  can partially or fully understand e.g., SgNB Change Request or SgNB Addition Request Acknowledge, the MeNB  120  may intercept the procedure e.g., proceed with/reject the SeNB change earlier as shown in  FIG. 7  as compared to the other option as shown in  FIG. 6 . However, in some embodiments, the procedure shown in  FIG. 6  may be more desirable where forcing each signal to go through MeNB  120  may increase signaling overhead and latency for the SgNB change procedure. On the other hand, it may also be advantageous to allow a central entity to overlook the overall mobility behavior and respective RRM strategy due to, for example, the fact that mobility of the RRC connection that is controlled by the MeNB needs to be taken into account. Apart from that, the second option shown in  FIG. 7  would be able to reuse existing LTE framework. 
     In some embodiments, the NR configuration message, e.g., NR-Config Info in messages  603 ,  706 , may be an RRC Protocol Data Unit (PDU) transferred between UE RRC entity and NR RRC entity. Yet in another embodiment, such information could be comprised by an information element (IE) similar to SCG-Config in LTE DC. 
     In another option/embodiment, the LTE-NR interworking scenario as shown in  FIGS. 6-7  could be other way around such, that a NR node is the master network node  120  (i.e., MgNB  120 ), and LTE nodes are the source and target secondary network nodes (i.e., S-SeNB  110 A and T-SeNB  110 B and/or S-SgNB and T-SgNB). In some embodiments, the configuration may be transferred directly from the S-SgNB to the UE instead of transferring it via the MeNB. In another embodiment, the involved 5G RAN nodes could be nodes that support both LTE and NR access, hence, each entity could be in the position to comprehend and process RRC messages and perform respective RRM actions. Yet, in another embodiment, the scenario could be the same as shown in  FIGS. 6-7 , and MeNB  120  can in parallel add an SgNB or change an SgNB by following the existing LTE DC procedures, as can be found in 3GPP TS 36.300. 
       FIG. 8  is an exemplary flow diagram according to some embodiments. In preferred embodiments, method  800  is performed by the source secondary network node  110 A as described in connection with  FIG. 10  to transfer a UE context from the source secondary network node  110 A to a target secondary network node  110 B that is different than the source secondary network node  110 B. 
     In step  801 , the source secondary network node  110 A transmits a first message to the target secondary network node  110 B, wherein the target network node  110 B is configured to respond to the first message by transmitting to the source secondary network node  110 A a second message comprising configuration data of the target secondary network node  110 B. 
     In step  803 , the source secondary network node  110 A receives the second message transmitted by the target secondary network node  110 B. 
     In step  805 , after receiving the second message, the source secondary network node  110 A initiates a transfer of the UE context from the source secondary network node  110 A to the target secondary network node  110 B, wherein initiating the transfer of the UE context comprises the source secondary network node  110 A transmitting to a master network node  120  a third message comprising the configuration data of the target secondary network node. 
     In some embodiments, the first message in step  801  may comprise a Handover Request message  601  as shown in  FIG. 6 , the Handover Request message instructing the target secondary network node  110 B to perform one or more configuration actions. In some embodiments, the second message in steps  801  and  803  of method  800  may comprise a Handover Response message, such as the Handover Request Ack message  603  as shown in  FIG. 6 . In some embodiments, the configuration data in the second message may comprise NR-Config Info, which may be one of a RRC PDU or an IE. In some embodiments, the source secondary network node  110 B may receive a fourth message transmitted by the master network node  120  in response to the master network node  120  receiving the third message. The fourth message may be a Release Request, such as message  611  shown in  FIG. 6 . 
       FIG. 9  is an exemplary flow diagram according to some embodiments. In preferred embodiments, method  900  is performed by the master network node  120  as described below in connection with  FIG. 11 . 
     In step  901 , the master network node  120  receives a first message transmitted by the source secondary network node  110 A, the first message comprising a request to initiate a transfer of the UE context from the source secondary network node  110 A to the target secondary network node  110 B. In some embodiments, the first message may comprise a Change Request, such as message  701  as shown in  FIG. 7 . 
     In step  903 , in response to the request, the master network node  120  transmits a second message to the target secondary network node  110 B. 
     In step  905 , the master network node  120  receives a third message from the target secondary network node  110 B, the third message comprising configuration data of the target secondary network node  110 B. In some embodiments, the configuration data of the target secondary network node  110 B may comprise NR-Config Info, which may comprise one of a RRC PDU or an IE. 
     In some embodiments, method  900  may further comprise the master network node  120  transmitting an acknowledgement of the request to the secondary network node  110 A, such as message  711  shown in  FIG. 7 . In some embodiments, method  900  may further comprise the master network node  120  transmitting a release request to the source secondary network node  110 A, such as message  713  shown in  FIG. 7 . In some embodiments, method  900  may further comprise the master network node  120  transmitting a message to the UE  105  in response to receiving the third message, the message comprising an RRC Connection Reconfiguration, (RRCConnectionReconfiguration) message such as message  715  shown in  FIG. 7 . The method  900  may further comprise the master network node  120  receiving a message from the UE  105 , the message comprising an RRC Connection Reconfiguration Complete (RRCConnectionReconfiguration Complete) message such as message  717  shown in  FIG. 7 . In some embodiments, the method  900  may further comprise the master network node  120  transmitting to the target secondary network node  110 B a Reconfiguration Complete message, such as message  719  shown in  FIG. 7 . 
     In connection with  FIGS. 8-9 , in some embodiments, the source secondary network node  110 A comprises a first New Radio Node, the target secondary network node  110 B comprises a second New Radio Node, and the master network  120  node comprises an eNB. In other embodiments, the source secondary network node  110 A comprises a first eNB, the target secondary network node  110 B comprises a second eNB, and the master network node  120  comprises a New Radio Node. 
       FIG. 10  is a block diagram of a source secondary network node  110 A according to some embodiments. As shown in  FIG. 10 , source secondary network node  110 A may comprise: a data processing system (DPS)  1002 , which may include one or more processors  1055  (e.g., a general purpose microprocessor and/or one or more other data processing circuits, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a network interface  1005  for use in connecting source secondary network node  110 A to network  130 ; a radio transceiver  1007  (i.e., a receiver and a transmitter) coupled to an antenna  1022  for use in, for example, wirelessly communicating with UEs and other devices; and local storage unit (a.k.a., “data storage system”)  1012 , which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where source secondary network node  110 A includes a general-purpose microprocessor, a computer program product (CPP)  1041  may be provided. CPP  1041  includes a computer readable medium (CRM)  1042  storing a computer program (CP)  1043  comprising computer readable instructions (CRI)  1044 . CRM  1042  may be a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), memory devices (e.g., random access memory), and the like. In some embodiments, the CRI  1044  of computer program  1043  is configured such that when executed by data processing system  1002 , the CRI causes the source secondary network node  110 A to perform steps described above (e.g., steps described above with reference to the flow charts). In other embodiments, secondary network node  110 A may be configured to perform steps described herein without the need for code. That is, for example, data processing system  1002  may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software. 
       FIG. 11  is a block diagram of a master network node  120  according to some embodiments. As shown in  FIG. 11 , master network node  120  may comprise: a data processing system (DPS)  1102 , which may include one or more processors  1155  (e.g., a general purpose microprocessor and/or one or more other data processing circuits, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a network interface  1105  for use in connecting master network node  120  to network  130 ; a radio transceiver  1107  coupled to an antenna  1122  for use in, for example, wirelessly communicating with UEs and other devices; and local storage unit (a.k.a., “data storage system”)  1112 , which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where master network node  120  includes a general purpose microprocessor, a computer program product (CPP)  1141  may be provided. CPP  1141  includes a computer readable medium (CRM)  1142  storing a computer program (CP)  1143  comprising computer readable instructions (CRI)  1144 . CRM  1142  may be a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), memory devices (e.g., random access memory), and the like. In some embodiments, the CRI  1144  of computer program  1143  is configured such that when executed by data processing system  1102 , the CRI causes the master network node  120  to perform steps described above (e.g., steps described above with reference to the flow charts). In other embodiments, master network node  120  may be configured to perform steps described herein without the need for code. That is, for example, data processing system  1102  may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software. 
     Examples of secondary network node embodiments include a method performed by a source secondary network node to transfer a User Equipment context from the source secondary network node to a target secondary network node that is different than the source secondary network node. The method comprises transmitting, by the source secondary network node, a first message to the target secondary network node. The target network node is configured to respond to the first message by transmitting to the source secondary network node a second message comprising configuration data of the target secondary network node. The method further comprises receiving, at the source secondary network node, the second message transmitted by the target secondary network node. The method further comprises, after receiving the second message, initiating a transfer of the UE context from the source secondary network node to the target secondary network node. Initiating the transfer of the UE context comprises transmitting, by the source secondary network node, to a master network node a third message comprising the configuration data of the target secondary network node. 
     In some embodiments, the first message comprises a Handover Request message, the Handover Request message instructing the target secondary network node to perform one or more configuration actions. In some such embodiments, the second message comprises a Handover Response message. 
     In some embodiments, the configuration data comprises one of: a radio resource control (RRC) protocol data unit (PDU) or an information element (IE). 
     In some embodiments, the method further comprises receiving, at the source secondary network node, a fourth message transmitted by the master network node, the fourth message comprising a Release Request. The master network node is configured to transmit the fourth message after receiving the third message. 
     In some embodiments, the source secondary network node comprises a first New Radio Node, the target secondary network node comprises a second New Radio Node, and the master network node comprises an Evolved Node B. 
     In some embodiments, the source secondary network node comprises a first Evolved Node B, the target secondary network node comprises a second Evolved Node B, and the master network node comprises a New Radio Node. 
     Other embodiments include a source secondary network node, comprising a transmitter, a receiver, a memory, and a data processing system comprising one or more processors. The source secondary network node is configured to perform the method of any one of the secondary network node embodiments just described. 
     Examples of master network node embodiments include a method performed by a master network node to transfer a User Equipment context from a source secondary network node to a target secondary network node that is different than the source secondary network node. The method comprises receiving, at the master network node, a first message transmitted by the source secondary network node. The first message comprises a request to initiate a transfer of the UE context from the source secondary network node to the target secondary network node. The method further comprises, in response to the request, transmitting, by the master network node, a second message to the target secondary network node. The method further comprises receiving, by the master network node, a third message from the target secondary network node, the third message comprising configuration data of the target secondary network node. 
     In some embodiments, the method further comprises transmitting, by the master network node, a fourth message to the source secondary network node, the fourth message comprising an acknowledgement of the request. In some such embodiments, the method further comprises transmitting, by the master network node, a fifth message to the source secondary network node, the fifth message comprising a Release Request. 
     In some embodiments, the method further comprises, in response to receiving the third message, transmitting a sixth message to the User Equipment, the sixth message comprising a RRCConnectionReconfiguration message. The method further comprises receiving a seventh message from the User Equipment, the seventh message comprising a RRCConnectionReconfiguration Complete message. In some such embodiments, the method further comprises in response to receiving the seventh message, transmitting, to the target secondary network node, an eighth message, the eighth message comprising a Reconfiguration Complete. 
     In some embodiments, the first message comprises a Change Request. 
     In some embodiments, the configuration data of the target secondary network node comprises one of a radio resource control (RRC) protocol data unit (PDU) or an information element. 
     In some embodiments, the source secondary network node comprises a first New Radio Node, the target secondary network node comprises a second New Radio Node, and the master network node comprises an Evolved Node B. 
     In some embodiments, the source secondary network node comprises a first Evolved Node B, the target secondary network node comprises a second Evolved Node B, and the master network node comprises a New Radio Node. 
     Other embodiments include a master network node that comprises a transmitter, a receiver, a memory, and a data processing system comprising one or more processors. The master network node is configured to perform the method of any of the example master network node embodiments just described. 
     While various embodiments of the present disclosure are described herein, it should be understood that they have been presented by way of example only. Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of some steps may be re-arranged, and some steps may be performed in parallel.