阅读说明：本技术 主基站发起的辅基站释放与辅基站发起的辅基站改变过程之间的竞争条件避免 (Race condition avoidance between primary base station initiated secondary base station release and secondary base station initiated secondary base station change procedures ) 是由 O.N.C.耶尔马兹 S.瓦格尔 A.韦塞利 于 2018-06-14 设计创作，主要内容包括：本文公开了涉及无线通信网络中的无线设备的双连接性(DC)的系统和方法。在一些实施例中,公开了一种辅节点中的方法,所述辅节点用于与主节点一起为无线设备提供DC,使得所述无线设备被配置为利用由无线通信网络中的所述主节点和所述辅节点两者所提供的资源。所述方法包括从所述主节点接收释放请求。所述释放请求是用于释放所述无线设备的无线设备上下文或用于释放用于所述无线设备的资源的请求。所述方法还包括向所述主节点发送释放拒绝。所述释放拒绝是所述辅节点拒绝所述释放请求的指示。(in some embodiments, a method is disclosed in secondary nodes for providing a DC for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network.)

1. a method in a secondary node for providing dual connectivity for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the method comprising:

receiving (1400) a release request from the master node, the release request being a request to release a wireless device context for the wireless device or to release resources for the wireless device; and

sending (1402) a release rejection to the primary node, the release rejection being an indication that the secondary node rejected the release request.

2. The method of claim 1, wherein the release request includes an indication of a reason for the release request.

3. The method of claim 1, further comprising:

determining that the secondary node is permitted to reject the release request prior to sending the release rejection to the primary node.

4. The method of claim 3, wherein:

the release request includes an indication of a reason for the release request; and

the method also includes determining, prior to sending the release denial to the primary node, that the secondary node is permitted to deny the release request based on the reason for the release request.

5. The method of claim 4, wherein the reason for the release request is a mobility related reason.

6. The method of claim 4, wherein the reason for the release request is of or more predefined or preconfigured reasons for allowing the secondary node to reject a release request.

7. The method of claim 6, wherein the or more predefined or preconfigured reasons for allowing the secondary node to reject a release request comprise Secondary Cell Group (SCG) mobility.

8. The method of claim 4, wherein the reason for the release request is not any of or more predefined or preconfigured reasons that do not allow the secondary node to reject a release request.

9. The method of claim 8, wherein the or more predefined or preconfigured reasons for not allowing the secondary node to reject a release request comprise Master Cell Group (MCG) mobility.

10. The method of any of claims 1-9, wherein the release rejection includes an indication of a reason for the release rejection.

11. The method of claim 10, wherein the reason for the release rejection is a mobility-related reason, a load balancing-related reason, or an inactivity-related reason.

12. The method of any of claims 1-11, wherein the primary node and the secondary node have different radio access technologies.

13. The method of claim 12, wherein the primary node is a primary long term evolution, LTE, node and the secondary node is a secondary new radio, NR, node.

14. The method of claim 12, wherein the primary node is a master new radio, NR, node and the secondary node is a secondary long term evolution, LTE, node.

15. The method of any of claims 1-14, wherein receiving the release request is part of:

a secondary node release process initiated by the primary node;

a secondary node change procedure initiated by the primary node;

SCG change process of the auxiliary cell group;

switching between the primary nodes with a secondary node change process; or

Master node to enhanced or evolved node B/NR base station eNB/gNB change procedure.

16. A secondary node for providing dual connectivity for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the secondary node adapted to:

receiving a release request from the master node, the release request being a request to release a wireless device context for the wireless device or to release resources for the wireless device; and

sending a release rejection to the primary node, the release rejection being an indication that the secondary node rejects the release request.

17. The secondary node of claim 16, wherein the secondary node is further adapted to perform the method of any of claims 2-15.

18, computer program comprising instructions that, when executed on at least processors, cause the at least processors to perform the method of any of claims 1-15 to .

19, a carrier containing the computer program of claim 18, wherein the carrier is an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

20, secondary nodes for providing dual connectivity for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the secondary node comprising:

a processing circuit configured to:

receiving a release request from the master node via an interface, the release request being a request to release a wireless device context for the wireless device or to release resources for the wireless device; and

sending a release rejection to the primary node via the interface, the release rejection being an indication that the secondary node rejected the release request.

21. A secondary node for providing dual connectivity for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the secondary node comprising:

a receiving unit operable to receive a release request from the master node via an interface, the release request being a request for releasing a wireless device context of the wireless device or for releasing resources for the wireless device; and

a sending unit operable to send a release rejection to the primary node via the interface, the release rejection being an indication that the secondary node rejected the release request.

22. A method in a primary node for providing dual connectivity for a wireless device with a secondary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the method comprising:

sending a release request to the secondary node, the release request being a request to release a wireless device context for the wireless device or to release resources for the wireless device; and

receiving a release rejection from the secondary node, the release rejection being an indication that the secondary node rejects the release request.

23. The method of claim 22, wherein the release request includes an indication of a reason for the release request.

24. The method of claim 23, wherein the reason for the release request is a mobility related reason.

25. The method of claim 23, wherein the reason for the release request is of or more predefined or preconfigured reasons for allowing the secondary node to reject a release request.

26. The method of claim 25, wherein the or more predefined or preconfigured reasons for allowing the secondary node to reject a release request comprise Secondary Cell Group (SCG) mobility.

27. The method of claim 23, wherein the reason for the release request is not any of or more predefined or preconfigured reasons that do not allow the secondary node to deny release requests.

28. The method of claim 27, wherein the or more predefined or preconfigured reasons for not allowing the secondary node to reject a release request comprise Master Cell Group (MCG) mobility.

29. The method of any of claims 22-28, wherein the release rejection includes an indication of a reason for the release rejection.

30. The method of claim 29, wherein the reason for the release rejection is a mobility-related reason, a load balancing-related reason, or an inactivity-related reason.

31. The method of any of claims 22-30, wherein the primary node and the secondary node have different radio access technologies.

32. The method of claim 31, wherein the primary node is a primary long term evolution, LTE, node and the secondary node is a secondary new radio, NR, node.

33. The method of claim 31, wherein the primary node is a master new radio, NR, node and the secondary node is a secondary long term evolution, LTE, node.

34. The method of any of claims 22-33, wherein the release request is part of:

a secondary node release process initiated by the primary node;

a secondary node change procedure initiated by the primary node;

SCG change process of the auxiliary cell group;

switching between the primary nodes with a secondary node change process; or

Master node to enhanced or evolved node B/NR base station eNB/gNB change procedure.

35. A primary node for providing dual connectivity for a wireless device with a secondary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the primary node adapted to:

sending a release request to the secondary node, the release request being a request to release a wireless device context for the wireless device or to release resources for the wireless device; and

receiving a release rejection from the secondary node, the release rejection being an indication that the secondary node rejects the release request.

36. The master node of claim 35, wherein the master node is further adapted to perform the method of any of claims 23-34.

37, computer program comprising instructions that, when executed on at least processors, cause the at least processors to perform the method of any of claims 22-34 to .

38, a carrier containing the computer program of claim 37, wherein the carrier is an electronic signal, optical signal, radio signal, or computer readable storage medium.

39, primary nodes for providing dual connectivity for a wireless device with a secondary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the primary node comprising:

a processing circuit configured to:

sending a release request to the secondary node via an interface, the release request being a request to release a wireless device context for the wireless device or to release resources for the wireless device; and

receiving a release rejection from the secondary node via the interface, the release rejection being an indication that the secondary node rejects the release request.

40. A primary node for providing dual connectivity for a wireless device with a secondary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network, the primary node comprising:

a sending unit operable to send a release request to the secondary node via an interface, the release request being a request to release a wireless device context of the wireless device or to release resources for the wireless device; and

a receiving unit operable to receive a release rejection from the secondary node via the interface, the release rejection being an indication that the secondary node rejected the release request.

Technical Field

The present disclosure relates to Dual Connectivity (DC) in a wireless communication network, and more particularly, to a primary base station initiated secondary base station release and a secondary base station initiated secondary base station change procedure in a cellular communication network.

Background

All references to //the elements, devices, components, means, steps, etc. are to be interpreted openly as referring to at least instances of the elements, devices, components, means, steps, etc. unless explicitly stated otherwise, the steps of any method disclosed herein need not be performed in the exact order disclosed, unless explicitly described as being after or before another step and/or where it is implied that the steps must be after or before another step.

Various third generation partnership project (3 GPP) documents mentioned herein are publicly available at 29 w.3gpp.org.

The overall requirements for the next generation (NG) architecture (see Technical Report (TR) 23.799, study on architecture of the next generation) and more specifically for the NG access technology (see TR 38.913, study on scenario and requirements of the next generation access technology) will impact the design (from mobility to control plane design and mechanism) of the fifth generation (5G) (see RP-160671, new SID proposal: study on new radio access technology, DoCoMo).

It is essential to design how basic Radio Resource Monitoring (RRM) functions, such as mobility handling, need to be distributed between Long Term Evolution (LTE) and New Radio (NR) Radio Resource Control (RRC) entities; and how related control plane signaling (such as secondary enhanced or evolved node b (senb)/secondary gbb (where gbb refers to NR base station) changes/releases) should be exchanged between the primary and secondary nodes to enable seamless mobility to be efficiently supported.

1 LTE

In LTE Dual Connectivity (DC), due to mutual understandability between primary and secondary nodes (i.e., primary enhanced or evolved node bs (menbs) and senbs), the MeNB is able to maintain RRM measurement configurations of user equipment devices (UEs) in terms of mobility procedures. Furthermore, the MeNB may decide to require the SeNB to provide additional resources (serving cells) for the UE, e.g. based on the received measurement report or traffic condition or bearer type (when it is simple to interpret the received measurement report or traffic condition or bearer type by the RRC entity located at the primary node). Thus, in the case of LTE DC, mobility may be primarily coordinated by the MeNB.

1.1 SeNB Release procedure in LTE DC case

As shown in fig. 1 and 2 based on TS 36.300, the SeNB release procedure may be initiated by the MeNB or by the SeNB and used to initiate release of UE context at the SeNB.

Fig. 1 shows the SeNB release procedure when initiated by the MeNB. Fig. 2 shows the SeNB release procedure when initiated by the SeNB.

1.2 SeNB Change procedure in LTE DC case

As shown in TS 36.300-based 3, the SeNB change procedure may be initiated by the MeNB and used to transfer the UE context from the source SeNB to the target SeNB, and to change the Secondary Cell Group (SCG) configuration in the UE from senbs to senbs.

2 NR

The proposed secondary gbb (SgNB) procedure mainly follows the same principles as in the corresponding LTE SeNB release procedure, in another aspect, also changes are foreseen in enhanced universal terrestrial radio access network DC (EN-DC) procedures, such as in SgNB change procedures, in relation to LTE DC, since SgNB is the main responsible node for managing secondary Node (NR) mobility current stage 3 text in 3GPP Technical Specification (TS) 37.340 is given below.

2.1 Secondary node Change (Master node (MN)/Secondary Node (SN) initiated)

2.1.1 EN-DC

The change of secondary node procedure is initiated by MeNB or SgNB and is used to transfer UE context from source SgNB to target SgNB and to change SCG configuration in UE from sgnbs to another .

The change of secondary node procedure always involves signaling towards the UE through a Master Cell Group (MCG) Signaling Radio Bearer (SRB).

Fig. 4 shows an example signaling flow for MN-initiated SN change:

1/2 the MeNB initiates the change of SgNB by requesting the target SgNB to allocate resources for the UE by means of the SgNB addition procedure. If forwarding is required, the target SgNB provides the MeNB with the forwarding address.

Random Access Channel (RACH) -availability of less access to be studied (FFS).

3. If the allocation of the target SgNB resources is successful, the MeNB initiates the release of the source SgNB resources. If data forwarding is required, the MeNB provides the data forwarding address to the source SgNB. Direct data forwarding or indirect data forwarding is used for SCG bearers. Only indirect data forwarding is used for MCG split bearers. Reception of the SgNB release request message triggers the source SgNB to stop providing user data to the UE and, if applicable, to start data forwarding.

Data forwarding for SCG split bearers remains to be investigated.

The MeNB applies the new configuration and sends a RRCConnectionReconfiguration complete message (including an encoded NR RRC response message for the target SgNB). in case the UE cannot comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs a reconfiguration failure procedure.

6. If the RRC connection reconfiguration procedure is successful, the MeNB informs the target SgNB via a sgnbreconfiguration complete message (NR RRC response message with encoding for the target SgNB).

7. The UE synchronizes to the target SeNB.

8/9, if applicable, data forwarding from the source SgNB takes place. It may be initiated as early as when the source SgNB receives the SgNB release request message from the MeNB.

10-14. if at source SgNB of the bearer context was configured with SCG or SCG split bearer option, a path update is triggered by MeNB.

15. Upon receiving the UE context release message, the source SgNB may release radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

Fig. 5 shows an example signaling flow for a secondary node change initiated by a SN:

1. the source SgNB initiates the SgNB change procedure by sending a SgNB change required message containing a candidate target cell or target node Identifier (ID).

In step 1 it can be indicated whether the cell list is to be investigated.

2/3 the MeNB requests the target SgNB to allocate resources for the UE by means of the SgNB addition procedure. If forwarding is required, the target SgNB provides the MeNB with the forwarding address.

4. If the allocation of the target SgNB resources is successful, the MeNB initiates the release of the source SgNB resources. If data forwarding is required, the MeNB provides the data forwarding address to the source SgNB. Direct data forwarding or indirect data forwarding is used for SCG bearers. Only indirect data forwarding is used for MCG split bearers. Reception of the SgNB release request message triggers the source SgNB to stop providing user data to the UE and, if applicable, to start data forwarding.

Data forwarding for SCG split bearers remains to be investigated.

5/6. MeNB/SgNB triggers UE to apply new configuration. MeNB indicates new configuration to UE in RRCConnectionReconfiguration message (including NR RRC configuration message generated by target SgNB.) UE applies new configuration and sends RRCConnectionReconfiguration complete message (including encoded NR RRC response message for target SgNB.) in case the UE cannot comply with ( part of) the configuration included in RRCConnectionReconfiguration message, it performs reconfiguration failure procedure.

Whether MeNB and/or SgNB triggers the UE to apply the new configuration remains to be studied.

7. If the RRC connection reconfiguration procedure is successful, the MeNB informs the target SgNB via a SN reconfiguration complete message (NR RRC response message with encoding for the target SgNB).

8. The UE synchronizes to the target SgNB.

9/10, if applicable, data forwarding from the source SgNB takes place. It may be initiated as early as when the source SgNB receives the SgNB release request message from the MeNB.

11-15 if at the source SgNB of the bearer context was configured with SCG bearer or SCG split bearer option, a path update is triggered by the MeNB.

16. Upon receiving the UE context release message, the source SgNB may release radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

2.1.1 Multi-radio Access technology Dual connectivity (MR-DC)

The MN-initiated SN change procedure for MR-DC is used to transfer UE context from source SN to target SN and to change SCG configuration in UE from SNs to another SNs.

The secondary node change procedure always involves signaling towards the UE through the MCG SRB.

Note that modifications to the process of fig. 6 may be made to, for example, align the actual Xn and RRC messages and Information Element (IE) names.

1/2 the MN initiates a SN change by requesting the target SN to allocate resources for the UE by means of a SN addition procedure. The MN may include measurements related to the target SN. The target SN provides the MN with a data forwarding address if data forwarding is required.

Note that: the MN may send a SN modification request message (to the source SN) to request the current SCG configuration prior to step 1.

3. If the allocation of the target SN resources is successful, the MN initiates the release of the source SN resources. If data forwarding is required, the MN provides a data forwarding address to the source SN. Direct data forwarding or indirect data forwarding is used for SCG bearers and SCG split bearers. Only indirect data forwarding is used for MCG split bearers. Reception of the SN release request message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.

4/5. MN triggers UE to apply new configuration.mn indicates new configuration to UE in MN RRC reconfiguration message (including target SN RRC configuration message). UE applies new configuration and sends MN RRC reconfiguration complete message (including encoded SN RRC response message for target SN.) in case UE cannot comply with ( part of) configuration included in MN RRC reconfiguration message, it performs reconfiguration failure procedure.

6. If the RRC connection reconfiguration procedure is successful, the MN informs the target SN via a SN reconfiguration complete message (SN RRC message with an encoding for the target SN).

7. The UE synchronizes to the target SN.

8/9, if applicable, data forwarding from the source SN occurs. It may be initiated as early as when the source SN receives a SN release request message from the MN.

10-14. if of the Protocol Data Unit (PDU) session/quality of service (QoS) flows were configured with SCG or SCG split bearer options at the source SN, the path update procedure is triggered by the MN.

The exact procedure of path switching for PDU sessions has yet to be studied.

15. Upon receiving the UE context release message, the source SN may release radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

2.2 SCG Change

2.2.1 EN-DC

During an SCG change, a Media Access Control (MAC) configured for the SCG is reset and a Radio Link Control (RLC) configured for the SCG is re-established regardless of bearer type ( or more) established on the SCG bearer and the SCG split bearer.

When the SCG for the SCG and SCG split bearer changes, whether to reestablish the PDCP configured for the SCG is to be studied.

Under the condition of reconfiguration from the split to the MCG bearing, the RLC configured for the SCG is released; in case of reconfiguration from SCG bearer split to SCG bearer, the RLC configured for MCG is released. During the SCG change, the servant node key (S-KgNB) is refreshed. To perform SCG changes within the same SgNB, SgNB modification procedures as described in section 10.3.1 of 3GPP TS37.340 V0.1.1 are used, and in this case, data forwarding and path switching for Data Radio Bearers (DRBs) on SCGs can be suppressed. To perform SCG changes between different sgnbs, changes in sgnbs are used as described in section 10.5.1 of 3GPP TS37.340 V0.1.1.

2.3 SN Release

2.3.1 EN-DC

The details of RRC signaling are to be studied and are a pending RAN2 agreement.

The secondary node release procedure may be initiated by the MeNB or by the SgNB and is used to initiate the release of the UE context at the SgNB the recipient node of the request cannot reject it.

Fig. 7 shows an example signaling flow for a MN-initiated secondary node release procedure.

1. The MeNB initiates this procedure by sending a SgNB release request message. If data forwarding is requested, the MeNB provides a data forwarding address to the SgNB.

2/3, if needed, the MeNB indicates to the UE that the UE should release the entire SCG configuration in the RRCConnectionReconfiguration message, in case the UE is not able to comply with the (part of the) configuration included in the RRCConnectionReconfiguration message, it performs a reconfiguration failure procedure.

Note that: timely coordination between steps 1 and 2 may minimize gaps in service provisioning if data forwarding is applied. However, this is considered a problem for implementation.

4/5, data forwarding from SgNB to MeNB is performed.

6. If applicable, a path update procedure is initiated.

7. Upon receiving the UE context release message, the SeNB may release radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

Fig. 8 shows an example signaling flow for a SN-initiated secondary node release procedure.

1. The SeNB initiates this procedure by sending a SgNB release request message that does not contain an inter-node message.

2. If data forwarding is requested, the MeNB provides the data forwarding address to the SgNB in a SgNB release confirm message. The SgNB may start data forwarding and stop providing user data to the UE as early as when it receives the SgNB release confirmation message.

3/4, if needed, the MeNB indicates to the UE that the UE should release the entire SCG configuration in the RRCConnectionReconfiguration message, in case the UE is not able to comply with the (part of the) configuration included in the RRCConnectionReconfiguration message, it performs a reconfiguration failure procedure.

Note that: timely coordination between steps 2 and 3 may minimize gaps in service provisioning if data forwarding is applied. However, this is considered a problem for implementation.

5/6, data forwarding from SgNB to MeNB is performed.

7. If applicable, a path update procedure is initiated.

8. Upon receiving the UE context release message, the SgNB may release radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

2.4 inter-master node handoff

2.4.1 EN-DC

Inter-primary node handover with/without MN initiated secondary node change is used to transfer context data from the source MN to the target MN while the context at the SN is maintained or moved SN. the target MN decides to maintain or change the SN (or release the SN as described in section 10.8 of 3GPP TS37.340 V0.1.1) during inter-primary node handover.

Note that: inter-Radio Access Technology (RAT) inter-master node handover with/without SN change (i.e. without transition from EN-DC to NR-NR DC) is not supported in this version of the protocol.

Fig. 9 shows an example signaling flow for an inter-primary node handoff with or without MN-initiated secondary node change.

Note that for inter-primary node handovers without a change in the secondary node, the source SN and the target SN shown in fig. 9 are the same node.

1. The source MN starts the handover procedure by initiating an X2 handover preparation procedure that includes both MCG configuration and SCG configuration. The source MN includes the (source) SN UE X2AP ID, the SN ID, and the UE context in the (source) SN in the handover request message.

Note that: the source MN may send a SgNB modification request message to request the current SCG configuration (to the source SN) before step 1.

2. If the target MN decides to keep the SN, the target MN sends to the SN a SN addition request including the SN UE X2AP ID as a reference to the UE context in the SN once established by the source MN. If the target MN decides to change SN, the target MN sends to the target SN a SgNB addition request that includes the UE context in the source SN that was established by the source MN.

3. The (target) SN replies with an SN add request acknowledgement.

4. The target MN includes a transparent container in the handover request confirm message (to be sent to the UE as an RRC message to perform handover) and may also provide a forwarding address to the source MN. If the target MN and the SN decide to maintain the UE context in the SN in step 2 and step 3, the target MN indicates to the source MN to maintain the UE context in the SN.

5. The source MN sends a SN release request to the (source) SN. If the source MN receives an indication from the target MN, the source MN indicates to the (source) SN to maintain the UE context in the SN. The SN maintains the UE context if an indication is included as the UE context maintained in the SN.

6. The source MN triggers the UE to apply the new configuration.

7/8 the UE synchronizes to the target MN and replies with an RRCConnectionReconfigurationComplete message.

9. The UE synchronizes to the (target) SN.

10. If the RRC connection reconfiguration procedure is successful, the target MN informs the (target) SN via the SgNB reconfiguration complete message.

11/12, data forwarding from the source MN is performed. If the SN is maintained, data forwarding may be omitted for SCG bearers and SCG split bearers. For split bearers, direct data forwarding from the source MN to the SN is not possible.

Data forwarding for the case when the SN is changed is yet to be investigated.

Note that: direct data forwarding may only occur for bearer type changes.

13-16. the target MN initiates S1 a path switch procedure.

Note that: if a new uplink Tunnel Endpoint Identifier (TEID) of the serving gateway (S-GW) is included, the target MN performs MN-initiated SN modification procedures to provide them to the SN.

17. The target MN initiates a UE context release procedure towards the source MN.

18. Upon receiving the UE context release message, the (source) SN may release C-plane related resources associated with the UE context towards the source MN. Any ongoing data forwarding may continue. If the indication is included in the SN release request in step 5, the SN should not release the UE context associated with the target MN.

2.4.25G MR-DC in core network (5 GC) case

MR-DC with 5GC was not completed and the goal was to complete in 2018 at 6 months.

inter-MN handovers with/without MN initiated SN changes are used to transfer UE context data from a source MN to a target MN while the UE context at the SN is maintained or moved SN. the target MN decides to maintain or change the SN (or release the SN as described in section 10.8 of 3GPP TS37.340 V0.1.1) during inter-master handovers.

Fig. 10 shows an example signaling flow for an inter-MN handoff with or without MN-initiated SN change.

Note that fig. 10 may be modified to align with the actual Xn and RRC messages and IE names, for example.

Note that for inter-primary node handovers without a change in the secondary node, the source SN and the target SN shown in fig. 10 are the same node.

1. The source MN starts the handover procedure by initiating an Xn handover preparation procedure that includes both MCG configuration and SCG configuration. The source MN includes the source SN UE XnAP ID, the SN ID, and the UE context in the source SN in the handover request message.

Note that: the source MN may send a SN modification request message to request the current SCG configuration (to the source SN) prior to step 1.

2. If the target MN decides to maintain the source SN, the target MN sends to the SN an SN addition request including the SN UE XnAP ID as a reference to the UE context in the SN once established by the source MN. If the target MN decides to change SN, the target MN sends to the target SN a SN addition request that includes the UE context in the source SN that was established by the source MN.

3. The (target) SN replies with an SN add request acknowledgement.

4. The target MN includes a transparent container in the handover request confirm message (to be sent to the UE as an RRC message to perform handover) and may also provide a forwarding address to the source MN. If the target MN and the SN decide to maintain the UE context in the SN in step 2 and step 3, the target MN indicates to the source MN to maintain the UE context in the SN.

5. The source MN sends a SN release request message to the (source) SN. If the source MN receives an indication from the target MN, the source MN indicates to the (source) SN to maintain the UE context in the SN. The SN maintains the UE context if an indication is included as the UE context maintained in the SN.

6. The source MN triggers the UE to perform handover and apply the new configuration.

7/8 the UE synchronizes to the target MN and replies with an MN RRC Reconfiguration complete message.

9. The UE synchronizes to the (target) SN.

10. If the RRC connection reconfiguration procedure is successful, the target MN informs the (target) SN via a SN reconfiguration complete message.

11/12, data forwarding from the source MN is performed. If the SN is maintained, data forwarding may be omitted for SCG bearers and SCG split bearers. For MCG split bearers, direct data forwarding from the source MN to the SN is not possible.

Data forwarding for the case when the SN is changed is yet to be investigated.

Note that: direct data forwarding may only occur for bearer type changes.

13-16, the target MN initiates a PDU session path switching process.

Note that: if a new uplink TEID for the SN's User Plane Function (UPF) is included, the target MN performs MN-initiated SN modification procedures to provide them to the SN.

The exact procedure of path switching for PDU sessions and whether uplink TEIDs are included are left to be investigated.

17. The target MN initiates a UE context release procedure towards the source MN.

18. Upon receiving a UE context release message from the source MN, the (source) SN may release C-plane related resources associated with the UE context towards the source MN. Any ongoing data forwarding may continue. If the indication is included in the SN release request message in step 5, the SN should not release the UE context associated with the target MN.

2.5 Primary node to eNB/gNB Change

2.5.1 EN-DC

The master node-to-eNB change procedure is used to transfer context data from the source MN/SN to the target eNB.

Fig. 11 shows an example signaling flow for a master node-to-eNB change procedure:

1. the source MN starts the MN-to-eNB change procedure by initiating an X2 handover preparation procedure (including both MCG configuration and SCG configuration).

2. The target eNB includes a field to release the SCG configuration in a Handover (HO) command and may also provide the source MN with a forwarding address.

3. If the allocation of the target eNB resources is successful, the MN initiates a release of the source SN resources towards the source SN. If data forwarding is required, the MN provides a data forwarding address to the source SN. Direct data forwarding or indirect data forwarding is used for SCG bearers. Only indirect data forwarding is used for MCG split bearers. Receipt of the SgNB release request message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.

Whether direct or indirect data forwarding is used for SCG split bearer remains to be investigated.

4. The MN triggers the UE to apply the new configuration. Upon receiving the new configuration, the UE releases the entire SCG configuration.

5/6 the UE synchronizes to the target eNB.

7/8, if applicable, data forwarding from the source SN occurs. It may start as early as when the source SN receives the SgNB release request message from the MN.

9-13. the target eNB initiates S1 a path switch procedure.

14. The target eNB initiates a UE context release procedure towards the source MN.

15. Upon receiving the UE context release message, the S-SN may release radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

2.5.25 MR-DC in case of GC

MR-DC with 5GC was not completed and the goal was completed in 2018 at 6 months.

The MN-to-NG-eNB/gNB change procedure is used to transfer UE context data from the source MN/SN to the target NG-eNB/gNB.

Fig. 12 shows an example signaling flow for a MN to NG-eNB/gNB change procedure note that modifications may be applied to, for example, align the actual Xn and RRC messages and IE names.

1. The source MN starts the MN to NG-eNB/gNB change procedure by initiating an Xn handover preparation procedure (including both MCG configuration and SCG configuration).

2. The target NG-eNB/gNB includes a field to release the SCG configuration in the HO command and may also provide the source MN with a forwarding address.

3. If the resource allocation of the target NG-eNB/gNB is successful, the MN initiates a release of the source SN resources towards the source SN. If data forwarding is required, the MN provides a data forwarding address to the source SN. Direct data forwarding or indirect data forwarding is used for SCG bearers. Only indirect data forwarding is used for MCG split bearers. Receipt of the SN release request message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding.

Whether direct or indirect data forwarding is used for SCG split bearer remains to be investigated.

4. The MN triggers the UE to perform HO and apply the new configuration. Upon receiving the new configuration, the UE releases the entire SCG configuration.

5/6, the UE synchronizes to the target NG-eNB/gNB.

7/8, if applicable, data forwarding from the source SN occurs. It may start as early as when the source SN receives a SN release request message from the MN.

9-13, the target NG-eNB/gNB initiates a PDU session path switching process.

The exact procedure of path switching for PDU sessions has yet to be studied.

14. The target NG-eNB/gNB initiates a UE context release procedure towards the source MN.

15. Upon receiving a UE context release message from the MN, the source SN may release radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

Disclosure of Invention

in some embodiments, a method is disclosed in secondary nodes for providing a DC for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network.

In embodiments, the release request includes an indication of a reason for the release request.

In embodiments the method further comprises determining that the secondary node is permitted to reject the release request before sending the release reject to the primary node, further in embodiments the release request comprises an indication of a reason for the release request, and the method further comprises determining that the secondary node is permitted to reject the release request based on the reason for the release request before sending the release reject to the primary node, further in embodiments the reason for the release request is a mobility related reason, in 1 other embodiments the reason for the release request is of or more predefined or preconfigured reasons allowing the secondary node to reject release requests, further in embodiments the one or more predefined or preconfigured reasons allowing the secondary node to reject release requests comprise Secondary Cell Group (SCG) mobility, in other embodiments the reason for the release request is not the one or more predefined or preconfigured reasons not allowing the secondary node to reject release request, in or SCG mobility embodiments the secondary node does not reject the release request comprises one or more predefined or preconfigured reasons for the primary node group , further in 363623 embodiments the secondary node does not reject the primary node group.

In embodiments , the rejection of the release includes an indication of a reason for the rejection of the release in embodiments , the reason for the rejection of the release is a mobility-related reason, a load balancing-related reason, or an inactivity-related reason.

In embodiments, the primary node and the secondary node have different radio access technologies, further in embodiments, the primary node is a primary Long Term Evolution (LTE) node and the secondary node is a secondary New Radio (NR) node, in other embodiments, the primary node is a primary NR node and the secondary node is a secondary LTE node.

In embodiments, receiving the release request is part of a secondary node release procedure initiated by the primary node, a secondary node change procedure initiated by the primary node, an SCG change procedure, an inter-primary node handover with secondary node change procedure, or a primary node to enhanced or evolved node B (eNB)/NR base station (gNB) change procedure.

Embodiments of secondary nodes for providing a DC for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network are also disclosed, hi embodiments, the secondary node is adapted to receive a release request from the primary node.

In some other embodiments, a secondary node for providing dual connectivity for a wireless device with a primary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communications network includes processing circuitry configured to receive a release request from the primary node via an interface.

Embodiments of a method in primary nodes for providing a DC for a wireless device with a secondary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network are also disclosed, hi embodiments, the method includes sending a release request to the secondary node.

In some embodiments, the reason for the release request is a cause related to mobility in some other embodiments, the reason for the release request is of the 0 or more predefined or preconfigured reasons that allow the secondary node to reject the release request, in some embodiments, the or more predefined or preconfigured reasons that allow the secondary node to reject the release request include SCG mobility in some other embodiments, the reason for the release request is not or any of the or more predefined or preconfigured reasons that do not allow the secondary node to reject the release request, in some embodiments, the or more predefined or preconfigured reasons that do not allow the secondary node to reject the release request include MCG mobility.

In embodiments , the rejection of the release includes an indication of a reason for the rejection of the release in embodiments , the reason for the rejection of the release is a mobility-related reason, a load balancing-related reason, or an inactivity-related reason.

In embodiments, the primary node and the secondary node have different radio access technologies in embodiments, the primary node is a primary LTE node and the secondary node is a secondary NR node in other embodiments, the primary node is a primary NR node and the secondary node is a secondary LTE node.

In embodiments, the release request is part of a secondary node release procedure initiated by the primary node, a secondary node change procedure initiated by the primary node, an SCG change procedure, an inter-primary node handover with secondary node change procedure, or a primary node-to-eNB/gNB change procedure.

Embodiments of master nodes are also disclosed for providing a DC for a wireless device with a secondary node such that the wireless device is configured to utilize resources provided by both the master node and the secondary node in a wireless communication network in embodiments the master node is adapted to send a release request to the secondary node.

In embodiments, a primary node for providing dual connectivity for a wireless device with a secondary node such that the wireless device is configured to utilize resources provided by both the primary node and the secondary node in a wireless communication network includes processing circuitry configured to send a release request to the secondary node via an interface.

Drawings

The accompanying drawings incorporated in and forming a part of the specification illustrate several aspects of the disclosure and, together with the description , serve to explain the principles of the disclosure.

Fig. 1 and 2 illustrate a secondary enhanced or evolved node b (senb) release procedure in case of Dual Connectivity (DC) in Long Term Evolution (LTE);

fig. 3 shows the SeNB change procedure in case of DC in LTE;

fig. 4 shows an example signaling flow for a primary node (MN) initiated Secondary Node (SN) change in case of enhanced universal terrestrial radio access network dual connectivity (EN-DC);

FIG. 5 shows an example signaling flow for SN changes initiated by SNs in the case of EN-DC;

fig. 6 shows an example signaling flow for MN-initiated SN change in case of multi-radio access technology dual connectivity (MR-DC);

fig. 7 shows an example signaling flow for a MN-initiated SN release procedure in the case of EN-DC;

fig. 8 shows an example signaling flow for a SN-initiated SN release procedure in the case of EN-DC;

fig. 9 shows an example signaling flow for inter-MN handover with or without MN-initiated SN change in the case of EN-DC;

fig. 10 shows an example signaling flow for an inter-MN handover with or without MN-initiated SN change in case of MR-DC for a fifth generation core network (5 GC);

fig. 11 shows an example signaling flow for a MN to enhanced or evolved node b (enb) change procedure in the case of EN-DC;

fig. 12 shows an example signaling flow for a MN to lower generation (NG) eNB/New Radio (NR) base station (gNB) change procedure in case of MR-DC for 5 GC;

fig. 13 and 14 illustrate operation of a MN and a SN in DC communication in a wireless communication system to provide SN release in a manner with respect to avoiding race conditions between network procedures, according to embodiments of the present disclosure;

fig. 15 shows another embodiment, where a user equipment device (UE) may request a master enb (MeNB) to abort/revoke the release procedure via a MeNB Radio Resource Control (RRC) message, provided that a secondary gmb (SgNB) has informed the UE that an ongoing SgNB mobility decision was aborted by a MeNB release request;

fig. 16 illustrates an embodiment of MN-initiated SN change, where if allocation of the target SN resource is successful, the MN initiates a release of the source SN resource (including a reason for Secondary Cell Group (SCG) mobility indicated in the SN/SgNB release request) and the source SN may then reject the release;

FIG. 17 shows the same process as that of FIG. 10, except that the source SN decides whether the release request can be denied based on the reason indicated in the release request;

FIG. 18 shows the same process as that of FIG. 12, except that the SN decides whether the release request can be denied based on the reason indicated in the release request;

fig. 19 shows examples of wireless networks according to embodiments of the present disclosure;

fig. 20 illustrates embodiments of a UE in accordance with various aspects described herein;

FIG. 21 is a schematic block diagram illustrating a virtualization environment in which functions implemented by embodiments may be virtualized;

FIG. 22 illustrates a telecommunications network connected to a host computer via an intermediate network according to embodiments of the present disclosure;

fig. 23 is a block diagram generalized of a host computer communicating with a UE via a base station over a partial wireless connection in accordance with embodiments of the present disclosure;

fig. 24 is a flow chart illustrating a method implemented in a communication system according to embodiments of the present disclosure;

fig. 25 is a flow chart illustrating a method implemented in a communication system according to embodiments of the present disclosure;

fig. 26 is a flow chart illustrating a method implemented in a communication system according to embodiments of the present disclosure;

fig. 27 is a flow chart illustrating a method implemented in a communication system in accordance with embodiments of the present disclosure;

FIG. 28 depicts a method according to a particular embodiment of the present disclosure; and

fig. 29 shows a schematic block diagram of an apparatus in a wireless network according to an embodiment of the present disclosure.

Detailed Description

The embodiments set forth below represent information that enables those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

The radio node: as used herein, a "radio node" is a radio access node or wireless device.

examples of radio access nodes include, but are not limited to, base stations (e.g., a New Radio (NR) base station (gNB) in a third Generation partnership project (3 GPP) fifth Generation (5G) NR network or an enhanced or evolved node B (eNB) in a 3GPP Long Term Evolution (LTE) network), high power or macro base stations, low power base stations (e.g., a micro base station, a pico base station, a home eNB, or the like), and relay nodes.

examples of core network nodes include, for example, a Mobility Management Entity (MME), a packet data network gateway (P-GW), a service capability opening function (SCEF), or the like.

Wireless device As used herein, a "wireless device" is any type of device that has access to (i.e., is served by) a cellular communication network by wirelessly transmitting and/or receiving signals to ( or more) radio access node examples of wireless devices include, but are not limited to, user equipment devices (UEs) and Machine Type Communication (MTC) devices in a 3GPP network.

Network node as used herein, a "network node" is any node that is part of a core network or radio access network of a cellular communication network/system.

Note that the description presented herein focuses on 3GPP cellular communication systems, and as such, 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems.

Note that in the description herein, reference may be made to the term "cell"; however, with respect to the 5G NR concept in particular, beams may be used instead of cells, and it is therefore important to note that the concepts described herein are equally applicable to both cells and beams.

of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, however, other embodiments are included within the scope of the subject matter disclosed herein, which should not be construed as limited to only the embodiments set forth herein, but rather these embodiments are provided by way of illustration to convey the scope of the subject matter to those skilled in the art.

The following definitions may apply:

"network procedure" may particularly refer to procedures such as release procedure and change procedure in a Dual Connectivity (DC) context, as described in the remainder of the disclosure;

" th network node" and "second network node" may refer to a primary node (MN) and a Secondary Node (SN) in DC communication, such as described in the remainder of this disclosure;

"reject cause" may refer to a plurality of causes for which a network process initiated by a network node is rejected by another network node, with specific examples being described in the remainder of this disclosure;

" th set of conditions" can be used for a rejection decision, and "second set of conditions" can be used for a validation decision.

In 3GPP TSG-RAN WG2 NR Ad Hoc, the following agreement has been made:

agreement:

1: for an initial configuration of LTE/NR tight interaction, the measurement configuration used by the UE should be configured by the primary node.

For LTE/NR tight interaction, intra-secondary-node mobility (including primary secondary cell (PSCell) changes and secondary cell (SCell) releases/additions) should be managed by the secondary node itself the primary node needs to be informed of intra-secondary-node mobility at least in cases.

For LTE/NR tight interaction, the measurement configuration used by the UE, intra-secondary node mobility should be managed by the secondary node coordination with the primary node is required, at least in cases.

4: the triggering of the Cyclic Prefix (CP) procedure listed below serves as a baseline for the LTE/NR tight interaction:

-secondary node addition procedure: triggered by the master node.

-secondary node release procedure: triggered by both the primary and secondary nodes.

Whether the secondary node or the primary node triggers a change in the secondary node is under investigation.

Intra-secondary mobility: triggered by the secondary node.

Addition/release of SCell within secondary node: triggered by the secondary node.

In 3GPP TSG-RAN WG2#97bis, the following related agreements have been made:

agreement:

1: secondary node addition is used when no SN is configured and is initiated only by the MN.

2: the receiver node released by the SN cannot reject the request.

3: mobility within the SN may trigger a SN modification request by the SN towards the MN.

Which scenarios require MN participation and which scenarios do not require MN participation to be studied.

4: for LTE-NR DC, MN handover may occur without SN node change.

Based on the current state of agreement, in the case of enhanced universal terrestrial radio access network DC (EN-DC), a secondary node release procedure may be initiated by the master enb (menb) or by the secondary gnb (SgNB) and used to initiate the release of UE context at the SgNB is also reached so that the recipient node of the request cannot reject it.

These proposed and/or achieved -induced SgNB release procedures follow the same principles as in the corresponding LTE secondary enb (senb) release procedure in another aspect, potential scenarios of contention conditions are considered herein, as changes in other EN-DC procedures (such as during SgNB changes) are foreseen with respect to LTE DC.

If it is assumed that the release request cannot be rejected by SgNB with MeNB initiated SgNB release, the ongoing SgNB change procedure can be interrupted in cases, e.g. a measurement report triggering an SN change is received just before the SgNB receives the SgNB release request message.

Certain aspects of the present disclosure and embodiments thereof may provide solutions to these and other challenges.

The present disclosure provides sets of embodiments for avoiding race conditions between MeNB initiated SgNB release and SgNB initiated SgNB change procedures therefore, if the request message has some cause, SgNB should be able to reject MeNB initiated SgNB release requests.

embodiments of the present disclosure address ways to avoid race conditions between network procedures, such as MeNB-initiated SgNB release and SgNB change procedures, by the SgNB rejecting a release request depending on the reason (i.e., rejection reason) included in the SgNB release request message and how the SgNB can inform the MeNB about the rejection reason for the newly-introduced rejection.

Various embodiments are presented herein that address or more of the problems disclosed herein.

In embodiments, there are provided methods performed by a second network node in DC network communication for avoiding race conditions between network processes, the method comprising performing a rejection decision to reject a network process initiated by a th network node under a th set of conditions or performing a validation decision to validate a network process initiated by a 38 th network node under a second set of conditions, optionally any or more of the following applies:

1. or more rejection reasons allowing the second node to reject the network process are received by the second node, wherein optionally the or more rejection reasons may be included in a network process request received from the th network node for the second network node;

2. wherein optionally the reject cause may comprise or more of mobility, such as degraded conditions or Radio Link Failure (RLF), or load balancing, or inactivity.

Optionally, the method further comprises sending a confirm/reject decision to the th node via inter-node signaling (such as Xn signaling). optionally, information regarding the decision reason information is also sent to the th network node, either along with or separately from the decision . the method may further comprise one or more of obtaining user data and forwarding the user data to the host computer or wireless device.

In another embodiment, there is provided a method performed by a wireless device for avoiding race conditions between network processes, the method comprising requesting a th network node (such as a primary node in DC network communications) to abort or reverse a release process, the method may further comprise receiving an indication from a second network node (such as a secondary node in DC network communications) that a mobility decision was aborted by the request from the th network node, the method may further comprise of the following, providing user data, and forwarding the user data to a host computer via transmission to the network node.

There is also provided an apparatus, a network node, a computer program and a computer medium adapted to perform the method as described above.

Certain embodiments may provide or more technical advantages such technical advantages are an active solution that enables potential race conditions between two network procedures, such as EN-DC procedures with which a UE may seamlessly continue its service and mobility within 5G coverage.

In addition, since the intended multiple RRC reconfigurations for releasing the old SgNB and adding a new SgNB through the series of procedures (i.e., the SgNB release procedure and the SgNB addition procedure) would be expected, it is contemplated in this disclosure that a SgNB group 2 embodiment is proposed for avoiding such a contention-initiated MegNB release and UE contention-initiated MegNB release condition.

Fig. 13 and 14 illustrate operation of a MN and a SN in DC communication in a wireless communication system to provide SN release in a manner that avoids race conditions between network procedures according to embodiments of the disclosure.

Figure 13 shows examples where the SgNB decides to accept the SgNB release request as shown, MeNB sends the SgNB release request to SgNB (step 1300). as described below, in some embodiments , the SgNB release request includes, for example, an indication of the reason for the SgNB release request, in the form of a reason Information Element (IE). when the SgNB release request is received, the SgNB decides whether to accept or reject the SgNB release request as described below.

In another example, or more reasons why SgNB may not reject SgNB release requests may be pre-configured or pre-configured, in this example, SgNB decides to reject SgNB release requests, and therefore sends SgNB release messages to MeNB (step 1402), the SgNB rejects the SgNB release requests in the form of, for example, a cause IE , discussed herein, the SgNB rejects the SgNB release requests.

In an th embodiment, the SgNB can reject an SgNB-initiated SgNB release request if , among the reasons included in the SgNB release request message, allows the SgNB to reject the decision.

In embodiments, the reason for allowing the SgNB to reject the decision, included in the MeNB initiated SgNB release request, is mobility, i.e. degradation of radio conditions on the NR side or rlf on the NR side, in another aspect, in this embodiment the SgNB will have to confirm the release if the reason included in the request message is load balancing or inactivity.

In other embodiments, it may be mandatory to include a cause IE in the MeNB-initiated SgNB release request if the cause IE includes a reason that allows the SgNB to reject the decision (if necessary).

In embodiments, the confirm/reject decision from the SgNB is sent to the MeNB via Xn (inter-node) signaling, as shown in fig. 13 and 14.

In another embodiment, the Xn message (SgNB release (request) reject/confirm) may also include a cause IE indicating the reason for the reject to help the MeNB understand the root cause of the reject decision and take necessary action for future decisions on the MeNB side.

In further embodiments, the UE may request MeNB interruption/withdrawal of the release procedure via MeNB RRC message, provided that the SgNB has informed the UE that the ongoing SgNB mobility decision was interrupted by the MeNB release request. This embodiment is shown in fig. 15.

In embodiments, MeNB and SgNB may be replaced by primary gnb (mgnb) and SeNB, respectively.

examples of such a situation are in the case where the SN release is initiated by the MN (e.g., due to mobility) and the SN is to trigger a SN change, as discussed above.

Embodiments are described herein that minimize disadvantages due to ambiguity of potential race conditions between MN-initiated procedures and SN-initiated procedures. Thus, the SN should be able to reject or should accept/validate the SN release request sent by the MN, depending on the reason indicated in the SN release message. The validation/rejection decision (from the SN) is sent to the MN via Xn (inter-node) signaling.

The proposed embodiments enable an optimal solution of potential race conditions between EN-DC processes. In this way, the UE can continue its service and mobility within the 5G coverage in an optimal manner. Also unnecessary signaling and procedures (due to contention conditions) will be minimized on the network side (and on the UE side, since RRC reconfiguration will be minimized).

Although a negative response, i.e., rejection, is preferable in cases, a positive response, i.e., acknowledgement/confirmation, may be optimal in cases, despite the fact that a race condition exists.