TECHNICAL FIELD

Embodiments herein relate to a master node, a secondary node and methods performed therein for communication. In particular embodiments herein relate handle communication for a wireless device in a wireless network, which wireless network provides e.g. dual connectivity (DC).

BACKGROUND

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

In LTE, the Radio Resource Control (RRC) protocol is used to configure/setup and maintain the radio connection between a user equipment (UE) and a network node such as an evolved NodeB (eNB). When the UE receives an RRC message from the eNB, it will apply the configuration (we also use the term “compile” to refer to the application of the configuration), and if this succeeds the UE generates an RRC complete message that indicates a transaction identity (ID) of the RRC message that triggered this response.

Since LTE-release 8, three Signaling Radio Bearers (SRBs), namely SRB0, SRB1 and SRB2 have been available for the transport of RRC and Non Access Stratum (NAS) messages between the UE and eNB. A new SRB, known as SRB1bis, was also introduced in rel-13 for supporting Data Over NAS (DoNAS) in Narrowband-Internet of things (NB-IoT).

SRB0 is for RRC messages using a Common Control Channel (CCCH) logical channel, and it is used for handling RRC connection setup, RRC connection resume and RRC connection re-establishment. Once the UE is connected to the eNB, i.e. RRC connection setup or RRC connection reestablishment/resume has succeeded, SRB1 is used for handling RRC messages, which may include a piggybacked NAS message, as well as for NAS messages prior to the establishment of SRB2, all using a Dedicated Control Channel (DCCH) logical channel.

SRB2 is for RRC messages which include logged measurement information as well as for NAS messages, all using DCCH logical channel. SRB2 has a lower priority than SRB1, because logged measurement information and NAS messages may be lengthy and may cause the blocking of more urgent and smaller SRB1 messages.

SRB2 is always configured by Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) after security activation.

E-UTRAN supports Dual Connectivity (DC) operation whereby a multiple Reception/Transmission (Rx/Tx) UE in RRC_CONNECTED mode is configured to utilize radio resources provided by two distinct schedulers, located in two eNBs, i.e. radio base stations, connected via a non-ideal backhaul over the X2 interface, see 3GPP 36.300 v.13.0.0. “Non-ideal backhaul” implies that the transport of messages over the X2 interface between the network nodes may be subject to both packet delays and losses.

eNBs involved in DC for a certain UE may assume two different roles: an eNB may either act as a Master Node (MN), also referred to as Master eNB (MeNB), or as a Secondary Node (SN), also referred to as Secondary eNB (SeNB). In DC a UE is connected to one MN and one SN.

In LTE DC, the radio protocol architecture that a particular bearer uses depends on how the bearer is setup. Three bearer types exist: Master Cell Group (MCG) bearer, Secondary Cell Group (SCG) bearer and split bearers. RRC is located in the MN and SRBs are always configured as MCG bearer type and therefore only use the radio resources of the MN. When a node acts as an SN, the LTE DC solution does not have any UE RRC context of that UE and all such signaling is handled by the MN.FIG. 1shows a LTE DC User Plane (UP) architecture.

In 3GPP, a study item on a new radio interface for 5G has recently been completed and 3GPP has now continued with the effort to standardize this new radio interface, often abbreviated by New Radio (NR). LTE-NR DC, also referred to as LTE-NR tight interworking, is currently being discussed for rel-15.

In this context, the major changes from LTE DC areThe introduction of a split bearer from the SN, known as SCG split bearer. The SN in this case is also referred to as secondary gNB (SgNB), where gNB denotes an NR base station.The introduction of split bearers for RRC.The introduction of a direct RRC from the SN, known as SCG SRB or direct SRB.

FIGS. 2 to 4show the User Plane (UP) and Control Plane (CP) architectures for LTE-NR tight interworking.

It should be appreciated that embodiments herein apply to different scenarios where the MN and SN nodes can apply various radio interface technologies. The MN node can apply e.g. LTE or NR, and the SN node can also use either LTE or NR without departing from the main concept of embodiments herein. Other technologies could also be used over the radio interface. The 3GPP technical report TR 38.304 v.0.0.3 includes various scenarios and combinations where the MN and SN are applying either NR, LTE or both.

For the first phase of 5G standardization and 5G deployment, the most likely scenario is that MN will apply LTE, and the SN will apply the new radio interface, denoted NR, currently being under standardization. Thus, we focus on this scenario and use the term MeNB and SgNB for the rest of this description.

The following terminologies are used throughout this text to differentiate different dual connectivity scenarios:DC: LTE DC, i.e. both MN and SN employ LTE.EN-DC: LTE-NR dual connectivity where LTE is the master and NR is the secondary.NE-DC: LTE-NR dual connectivity where NR is the master and LTE is the secondary.NR-DC (or NR-NR DC): both MN and SN employ NR.Multi-RAT DC (MR-DC): a generic term to describe where the MN and SN employ different RATs, EN-DC and NE-DC are two different example cases of MR-DC.

As already mentioned above, the DC approach introduced for 5G standardization includes a solution for split bearers for SRBs, seeFIGS. 3 and 4. The intent of introducing such “RRC diversity” is to enable e.g. better mobility robustness and improved message delivery between the infrastructure and the UE. For example, it is then possible to send a handover message or any other reconfiguration message over the best link, even if one of either the link or links to the MeNB (or SgNB) has deteriorated significantly. It is also possible to send duplicates of the same message over both MeNB and SgNB to achieve a better success-rate and faster delivery of the concerned message; in case the links are error prone. Such benefits of “RRC diversity” are not available in the current LTE DC solution, and 3GPP has therefore undertaken the challenge to enable such RRC diversity. Having RRC diversity may prove particularly important for ultra-reliable connections with low latency, often called Ultra Reliable Low Latency Communication (URLLC).

As can be seen inFIG. 4, RRC messages generated and/or transmitted from the MN can be sent either via the MeNB, or relayed over an X2 interface to the SgNB. The messages received over the different paths in the UE are then combined to the LTE Packet Data Convergence Protocol (PDCP) and then forwarded to the LTE RRC receiving entity and processed further. In the uplink, the UE generates LTE RRC messages that the UE may transmit either over the NR radio interface towards the SgNB or via the MN node using LTE technology. Messages received in the SgNB are then forwarded over an X2 interface towards the MeNB node.

One of the main reasons behind the introduction of SCG SRB between the UE and SN is that there may be SCG reconfiguration scenarios where SN can configure the UE directly without the need for coordination with the MN. This is for cases such as intra-SN mobility, measurement configurations/reporting related to the intra-SN cells, etc. Intra-SN meaning within SNs. Thus, it has been agreed in 3GPP that SCG SRB will support a (subset) of the functionalities, namely: RRCConnectionReconfiguration, in the DL; and RRCConnectionReconfigurationComplete and MeasurementReport in the UL.

Another control signaling mechanism, in addition to SCG SRB and split SRBs, in LTE-NR tight interworking is using embedded RRC and is also illustrated inFIG. 4. Embedded RRC is employed for two cases:1. When SCG SRB is not available.2. The UE has to be configured with settings that affect both the NR and LTE legs, i.e. co-ordination is required, even if direct SRB is available.

For the first case, the SgNB sends the RRC message to the MeNB via the X2 interface, which the MeNB then embeds in its own RRC message and sends via SRB1, which could be split or not. The UE then extracts the embedded NR RRC message from the container MeNB RRC message and apply the configurations on the NR leg. In the UL direction, the UE embeds the NR RRC messages in an LTE RRC message towards the MeNB, and the MeNB will extract the embedded NR RRC message from this and forwards it to the SgNB.

For the second case, i.e. messages/configurations that require co-ordination between the MeNB and SgNB, e.g. inter(between different)-RAT measurement configurations, settings affecting buffer sizes which the UE has to allocate to the NR and LTE legs without exceeding the total buffering capability of the UE, etc.), the SgNB node can send the NR configurations, the MeNB and SgNB can negotiate the final configurations (since it affects the settings of both legs), and the final configuration for the NR leg is sent to the UE via an LTE RRC message that contains the embedded NR RRC message, wherein the final embedded NR RRC message still being generated by the SN.

The MN initiated SN change procedure is described in TS 37.340 and shown inFIG. 5.

The procedure steps are.1/2. The MN initiates the change of SN by requesting the target SN to allocate resources for the UE by means of the SgNB Addition procedure. The MN may include measurement results related to the target SN. If forwarding is needed, the target SN provides forwarding addresses to the MN.3. If the allocation of target SN resources was successful, the MN initiates the release of the source SN resources. If data forwarding is needed the MN provides data forwarding addresses to the source SN. Either direct data forwarding or indirect data forwarding is used for SCG bearer and SCG split bearer. Only indirect data forwarding is used for MCG Split bearer. Reception 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.4/5. The MN triggers the UE to apply the new configuration. The MN indicates to the UE the new configuration in the RRCConnectionReconfiguration message including the NR RRC configuration message generated by the target SN. The UE applies the new configuration and sends the RRCConnectionReconfigurationComplete message, including the encoded NR RRC response message for the target SN. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.6. If the RRC connection reconfiguration procedure was successful, the MN informs the target SN via SgNBReconfigurationComplete message with the encoded NR RRC response message for the target SN.7. The UE synchronizes to the target SN.8/9. If applicable, data forwarding from the source SN takes place. It may be initiated as early as the source SN receives the SgNB Release Request message from the MN.10-14. If one of the bearer contexts was configured with the SCG or SCG split bearer option at the source SN, path update is triggered by the MN.15. Upon reception of the UE Context Release message, the source SN can release radio and C-plane related resource associated to the UE context. Any ongoing data forwarding may continue.

It should be noted that, in message 1 (SgNB addition request), the MN includes the current SCG configuration of the UE so that the target SN (T-SN) is able to do delta configuration instead of full configuration (i.e. it can change only the configuration that needs to be change, instead of reconfiguring the whole SCG). Currently, the exact details on how the MN acquires the latest SCG configuration is not settled in 3GPP. However, two possible ways have been identified:a) Whenever the SN modifies the SCG configuration (e.g. directly via SCG SRB), it notifies the MN about itb) The MN can explicitly request the latest SCG configuration from the MN at any time

For the MN initiated SN change procedure discussed above, we assume that before message 1 is sent, the MN may acquire the current SCG configuration of the UE by using either method a or b. So the assumption is that before message 1, the MN has acquired the current SCG configuration of the UE.

There currently exist certain challenge(s). In the MN initiated SN change procedure, the Source SN (S-SN) is not aware of the SN change procedure until it receives the release message in step 3.

It is possible that the S-SN might modify the SCG configuration of the UE during the time the MN is adding the target T-SN (i.e. messages 1 and 2). Thus, a situation like this might arise:the MN includes SCGConfiguration_version1 in message 1 towards the T-SN, and the T-SN applies a delta configuration over that, which is then communicated via message 2 and subsequently towards the UE in message 4While this is happening, the SN has changed the SCGConfiguration of the UE to SCGConfiguration_version2The UE tries to apply the delta configuration received in message 4 on top of SCGConfiguration_version2a conflict/error/failure happens e.g., RRC connection reconfiguration failure or SCG failure, and UE performs re-establishment or SCG failure reporting; orUE is able to apply the delta configuration, but since the T-SN is assuming the UE to have SCGConfiguration_version1+delta, while UE actually has the configuration SCGConfiguraiton_version2+delta. As such, eventually, an error or unwanted behavior is likely to occur because the SN is assuming one configuration, while the UE is having another configuration

Though the above scenario is more likely to happen in case the SN was using SCG SRB, i.e. with the MN having no idea regarding the SCG configuration change, it could even happen in the case of embedded SRB utilization because if co-ordination is not required, the SN's SCG reconfiguration is transported to the UE completely transparently by the MN.

SUMMARY

Certain aspects of the present disclosure and their embodiments may provide solutions to the above mentioned or other challenges. Embodiments introduce mechanisms to ensure that a race condition will not happen during MN initiated SN change procedure in e.g. EN-DC. This is achieved by making sure that the SN is aware of ongoing MN initiated SN change, so that SN can avoid modifying the SCG configuration during this time.

There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. According to an aspect of embodiments herein a method performed by a master node for handling communication of a wireless device in a wireless network is herein provided. The master node transmits, to a secondary node (SN), a message before initiating a SN change procedure, which message indicates that an SN change is pending and as such the SN should not perform either a SCG reconfiguration or trigger any SN triggered procedures.

According to another aspect of embodiments herein a method performed by a secondary node for handling communication of a wireless device in a wireless network is herein provided. The secondary node receives the message from a master node or another SN, which message indicates that an SN change is pending and as such the SN should not perform either a SCG reconfiguration or trigger any SN triggered procedures. Upon receiving the message the secondary node refrains from performing a SCG reconfiguration or initiating SN triggered procedures.

Also, a master node for handling communication of a wireless device in a wireless network is herein provided. The master node is configured to transmit, to a SN, a message before initiating a SN change procedure, which message indicates that an SN change is pending and as such the SN should not perform either a SCG reconfiguration or trigger any SN triggered procedures.

Furthermore, a SN for handling communication of a wireless device in a wireless network is herein provided. The SN is configured to receive a message from a master node or another SN, wherein the message indicates that a SN change is pending and as such the SN should not perform either a SCG reconfiguration or trigger any SN triggered procedures. The SN is further configured to, upon receiving the message, refrain from performing a SCG reconfiguration or initiating SN triggered procedures.

Certain embodiments may provide one or more of the following technical advantage(s). Embodiments ensure that MN triggered SN change will not result in race conditions where the SCG configuration of the wireless device is different at the target SN and the wireless device since the secondary node (source), upon reception of the message, refrains from performing a SCG reconfiguration or initiating SN triggered procedures.

