NETWORK NODE AND METHOD FOR HANDLING SECONDARY CELL GROUP OPERATION MODE IN A WIRELESS COMMUNICATION NETWORK - Patent application

Abstract

A first network node and a method thereof for handling an operation mode change of a second network node for a communication device in a wireless communication network are disclosed. The communication device is configured with Multi-Radio Dual Connectivity (MR-DC) where the first network node has a first cell group and the second network node has a second cell group. The first network node receives a request from the second network node for a change in operation mode and / or a change in configuration of the second network node (913) and determines whether to accept or reject the request for the change in operation mode and / or the change in configuration (914). If it is determined that the change in operation mode of the second cell group and / or the change in the second cell group configuration is accepted, the first network node transmits a message to the communication device including a reconfiguration or a command to change the second cell group configuration and / or the operation mode of the second cell group (915), or if it is determined that the request for the change in operation mode is rejected, transmits a response to the second network node with an indication of the reason for the rejection (917).

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE Embodiments herein relate to network nodes and methods for handling operation modes of communication devices operating in dual connectivity with a Master Cell Group (MCG) and a Secondary Cell Group (SCG) in a wireless communication network. [Background technology]

[0002] In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STAs), and / or user equipment (UEs), communicate with one or more core networks (CNs) via a radio access network (RAN). The RAN covers a geographical area that is divided into service areas or cell areas, sometimes called beams or beam groups, and each service area or cell area is served by a radio network node, such as a radio access node, e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may be denoted as a "Node B" or an "eNode B" or a "gNB". A service area or cell area is a geographical area in which radio coverage is provided by a radio network node. The radio network node communicates with wireless communication devices within range of the radio network node over an air interface operating on radio frequencies.

[0003] The Universal Mobile Telecommunications System (UMTS) is a third-generation (3G) telecommunications network that evolved from the second-generation (2G) Global System for Mobile Communications (GSM). The specification for the Evolved Packet System (EPS), also known as fourth-generation (4G) networks or Long Term Evolution (LTE), has been completed within the Third Generation Partnership Project (3GPP), and this work will continue in future 3GPP releases, for example, to specify fifth-generation (5G) New Radio (NR) networks and future releases.

[0004] In 3GPP Rel-12, LTE Capability Dual Connectivity (DC) was introduced to allow a UE to be connected in two cell groups, each controlled by an LTE access node, eNB, labeled Master eNB (MeNB) and Secondary eNB (SeNB). The UE still has only one RRC connection with the network node. In 3GPP, Dual Connectivity (DC) solutions have since evolved and are now specified for NR as well as between LTE and NR. With the introduction of 5G, the term Multi-Radio Dual Connectivity (MR-DC) (see also 3GPP TS37.340) was defined as a generic term for all dual connectivity options that include at least one NR access node. Using the generalized terminology in MR-DC, the UE is connected in a Master Cell Group (MCG) controlled by a Master Node (MN) and a Secondary Cell Group (SCG) controlled by a Secondary Node (SN).

[0005] Furthermore, in MR-DC, when dual connectivity is configured for a UE, carrier aggregation may also be used within each of the two cell groups, i.e., MCG and SCG. In this case, within the MCG controlled by the master node (MN), the UE may use one PCell and one or more SCells. Also, within the SCG controlled by the secondary node (SN), the UE may use one primary SCell (PSCell), also known as a primary SCG cell in NR, and one or more SCells. This combined case, i.e., dual connectivity combined with carrier aggregation in MR-DC, is shown in FIG. 1, where MN 110, SN 120, UE 130, MCG 140, SCG 150, PCell 160 in MCG 140, PSCell 170 in SCG 150, and multiple SCells are shown. In NR, the primary cell of the master cell group or secondary cell group may sometimes be referred to as a special cell (SpCell). Therefore, an SpCell in an MCG is a PCell, and an SpCell in an SCG is a PSCell.

[0006] There are various ways to deploy 5G networks with or without cooperation with LTE, also called E-UTRA and evolved packet core (EPC). In principle, NR and LTE can be deployed without any cooperation, indicated by NR standalone (SA) operation, also known as option 2, i.e., gNBs in NR can connect to a 5G core network (5GC), while eNBs in LTE can connect to an EPC without any interconnection between the two, also known as option 1.

[0007] On the other hand, the first supported version of NR uses dual connectivity, denoted as EN-DC (E-UTRAN-NR dual connectivity), also known as option 3, as shown in FIG. 2. In such deployment, dual connectivity between NR and LTE is applied, where the UE 210 is connected to the LTE access node LTE MeNB 220 by the LTE air interface LTE Uu 221 and to the NR access node NR SgNB 230 by the NR air interface NR Uu 231. Furthermore, in EN-DC, the LTE access node acts as a master node, in this case known as master eNB (MeNB), controlling the master cell group (MCG), and the NR access node acts as a secondary node, in this case sometimes also known as secondary gNB (SgNB), controlling the secondary cell group (SCG). The SgNB may not have a control plane connection to the EPC 240 of the core network, the connection is instead provided by the MeNB, in this case NR. This is also called "non-standalone NR" or "NSA NR" for short. In this case, the functionality of the NR cells is limited and used for connected mode UEs as booster and / or diversity legs, but it should be noted that while the UE is switched on, UEs in RRC_IDLE state that do not have any established RRC connection cannot camp on these NR cells.

[0008] With the introduction of 5GC, other options may also become available. As mentioned above, option 2 supports standalone NR deployments where a gNB is connected to 5GC. Similarly, LTE can also be connected to 5GC using option 5, also known as eLTE, E-UTRA / 5GC, or LTE / 5GC, and the node can be referred to as ng-eNB. In these cases, both NR and LTE are considered part of the NG-RAN, and both ng-eNB and gNB can be referred to as NG-RAN nodes.

[0009] Note that there are other variations of dual connectivity between LTE and NR that are being standardized as part of NG-RAN connected to 5GC. Under the MR-DC umbrella: · EN-DC (Option 3): LTE is the master node and NR is the secondary node (EPC CN is adopted, as shown in Figure 2). · NE-DC (Option 4): NR is the master node and LTE is secondary (5GCN is adopted). · NGEN-DC (Option 7): LTE is the master node and NR is the secondary (5GCN is adopted). · NR-DC (variant of option 2): As shown in Figure 3, dual connectivity is adopted where both the Master Node (MN) controlling the MCG and the Secondary Node (SN) controlling the SCG are NR 5GCNs.

[0010] Since the transition of these options may be different for different operators, it is possible to have deployments with multiple options in parallel in the same network, for example, there may be an eNB base station supporting options 3, 5 and 7 in the same network as an NR base station supporting 2 and 4. In combination with the dual connectivity solution between LTE and NR, it is also possible to support carrier aggregation (CA) in each cell group, i.e., MCG and SCG, and dual connectivity between nodes on the same RAT, e.g., NR-NR DC. For LTE cells, the result of these different deployments is the coexistence of LTE cells associated with eNBs connected to EPC, 5GC, or both EPC and 5GC.

[0011] As mentioned above, DC is standardized for both LTE and E-UTRA-NR DC (EN-DC). LTE DC and EN-DC are designed differently with regards to which node controls what. Basically there are two options: 1) Converged solutions such as LTE-DC, 2) Decentralized solutions such as EN-DC.

[0012] Figure 4 shows schematic control plane architectures such as LTE DC, EN-DC, and NR-DC. The main difference here is that in EN-DC and NR-DC, the SN has a separate NR RRC entity. This means that the SN can control the UE, possibly without the MN's knowledge, but the SN often needs to coordinate with the MN. In LTE-DC, the RRC decisions always come from the MN, i.e. from the MN to the UE. However, it should be noted that the SN still decides the configuration of the SN, since only the SN itself has knowledge about what kind of resources, capabilities, etc. it has.

[0013] Regarding EN-DC and NR-DC, the main changes compared to LTE DC are as follows: · Introduction of split Data Radio Bearers (DRBs) from the SN (known as SN terminated split DRBs). · Introduction of Split Signaling Radio Bearer (SRB) for RRC. · Introduction of Direct SRB from SN (also known as SCG SRB or SRB3).

[0014] Figure 5 shows the user plane protocol architecture in MR-DC (EN-DC) with EPC from the network node perspective, where the network node can configure either E-UTRA Packet Data Convergence Protocol (PDCP) or NR PDCP for MN terminated MCG DRBs, but NR PDCP is always used for all other DRBs.

[0015] Figure 6 shows the user plane protocol architecture in MR-DC with 5GC (NGEN-DC, NE-DC, and NR-DC) from the perspective of the network nodes. In MR-DC with 5GC, NR PDCP is always used for all data radio bearer (DRB) types. In NGEN-DC, E-UTRA radio link control / medium access control (RLC / MAC) is used in the MN, but NR RLC / MAC is used in the SN. In NE-DC, NR RLC / MAC is used in the MN, but E-UTRA RLC / MAC is used in the SN. In NR-DC, NR RLC / MAC is used in both the MN and SN.

[0016] SCG power saving mode: To improve network energy efficiency and UE battery life in MR-DC, Rel-17 work items plan to introduce efficient SCG / SCell activation / deactivation. This may be especially important for MR-DC configurations with NR SCG, since NR UE power consumption is evaluated in 3GPP contribution RP-190919 to be 3-4 times higher than LTE in some cases.

[0017] 3GPP defines the concept of dormant SCells (in LTE) and dormant-like behavior of SCells (for NR).

[0018] In LTE, when a SCell is in a dormant state, such as an inactive state, the UE does not need to monitor the corresponding physical downlink control channel (PDCCH) or PDSCH and cannot transmit in the corresponding uplink. However, unlike the inactive state, the UE is required to perform and report channel quality indicator (CQI) measurements. A PUCCH SCell, i.e., a SCell configured with a PUCCH, cannot be in a dormant state.

[0019] In NR, dormant-like behavior for SCells is realized using the concept of dormant bandwidth parts (BWPs). See FIG. 7, which is an illustration of dormant-like behavior for SCells in NR. One dormant BWP may be configured for the SCell, which is one of the dedicated BWPs configured by the network node via RRC signaling. If the active BWP of an activated SCell is a dormant BWP, the UE stops monitoring the PDCCH on the SCell, but continues to perform channel state information (CSI) measurements, automatic gain control (AGC), and beam management, if configured. Downlink control information (DCI) is used to control entering / exiting a dormant BWP for one or more SCells or one or more SCell groups, and is sent to a special cell (SpCell) of the cell group to which the SCell belongs, i.e., to the PCell if the SCell belongs to the MCG, or to the PSCell if the SCell belongs to the SCG. An SpCell, ie, a PCell of a PSCell, and a PUCCH SCell, cannot be configured with a dormant BWP.

[0020] However, only the SCell can be made dormant (in LTE) or operate in dormant-like behavior (NR). Also, in both LTE and NR, only the SCell can be deactivated. Therefore, when the UE is configured with MR-DC, it is not possible to fully benefit from the power saving option of dormant or dormant-like behavior, since the PSCell cannot be configured with that feature. Instead, the existing solution can release for power saving and add as needed when traffic demand requires SCG. However, traffic is likely to be bursty, and adding and releasing SCG involves a significant amount of RRC signaling and inter-node messaging between the MN and the SN, which causes significant delays.

[0021] In 3GPP rel-16, there was some discussion on putting the PSCell into a dormant state, also called SCG Suspension. Further discussion was done in RAN-2 108 to clarify further study (FFS). Several solutions were proposed in Rel-16, but these have different problems.

[0022] RAN2#113bis-e has the following agreement regarding SCG deactivation: TIFF0007681128000001.tif152170

[0023] In the following, the terms "suspended SCG", "SCG in power saving mode", "SCG inactive state", or "deactivated SCG" are used interchangeably. The term "suspended SCG" may also be referred to as "deactivated or inactive SCG", or "dormant SCG". The terms "resume SCG", "SCG in normal operation mode", "SCG active state", and "SCG in non-power saving mode" are used interchangeably. The term "resume SCG" may also be referred to as "activated SCG" or "active SCG". The operation of an SCG operating in resumed or active mode may also be referred to as normal SCG operation or legacy SCG operation. An example of the operation is UE signal reception / transmission procedures, e.g., receiving a signal message, transmitting a signal message, etc. The terms "communication device" and "UE" are used interchangeably. The terms "network node", "gNB", "eNB", and "gNodeB" are used interchangeably. Summary of the Invention

[0024] As part of developing the embodiments herein, problems are identified and first discussed.

[0025] A change in the SCG operation mode can be initiated by the SN, ie, SN-initiated, or by the MN, ie, MN-initiated.

[0026] SN-initiated changes: MN can reject and / or accept When a change in the SCG operation mode is initiated by the SN, the MN may need to decide whether the request is accepted or rejected. However, especially if the request is rejected, the SN does not know the reason for the rejection. One problem is that the relevant input to the SCG activation / deactivation decision for rejecting an SN-initiated request in the MN may come from the UE. This may be, for example, information that the UE is overheating or that the UE's battery is low. This information is typically sent to the MN as part of the UE assistance information procedure and is not available to the SN. Not knowing the rejection may prevent the SN from taking a subsequent action, for example, deciding to release the SCG and / or to wait for a while before being able to send another request. For example, assume that the SCG is deactivated. Also, the MN knows, e.g. via UE assistance, that the UE is overheating. If the SN requests activation of the SCG, the MN rejects the request from the SN to activate the SCG, but the SN does not know why.

[0027] MN-initiated changes: SN can reject and / or accept In case the change of SCG operation mode is initiated by the MN, e.g. due to some internal algorithm in the MN, it is the SN that may need to decide if the request is accepted or rejected. However, especially if the request is rejected, the MN is not aware of the reason for the rejection, which may be internal to the SN and / or related to the SCG configuration. One problem is that the relevant input to the SCG activation / deactivation decision for rejecting an MN-initiated request in the SN may come from the UE, e.g. from UE assistance information via SRB3. This may be, for example, information that the UE is overheating or that the UE battery is low. In the case of SRB3, this information is sent to the SN as part of the UE assistance information procedure and is not available to the MN. Not knowing the rejection may prevent the MN from taking a subsequent action, e.g. deciding to release the SCG and / or to wait for a while before being able to send another request.

[0028] It is therefore an object of the embodiments herein to provide an improved method for handling SCG operation mode changes in a wireless communication network.

[0029] According to an aspect of an embodiment herein, this object is achieved by a first network node, e.g., MN, for handling an SCG operation mode by providing a rejection reason to a second network node, e.g., SN, and a method therein. The rejection reason may be, for example, a cause value for rejecting a request for a change of SCG mode to the UE. The first network node may send information, e.g., an ACTIVITY NOTIFICATION message, to the second network node that enables the second network node to determine the SCG operation mode.

[0030] The first network node receives a request from a second network node to change an operation mode of the SCG.

[0031] The first network node sends a response to the second network node, where the change in the SCG operating mode is either accepted or rejected.

[0032] If the SCG operating mode change is rejected, the response includes an indication of the specific reason for the rejection.

[0033] If the change in the SCG operating mode is accepted, the first network node sends a message to the communication device including a reconfiguration or command to change the SCG operating mode.

[0034] According to one aspect of an embodiment of the present specification, this object is achieved by a second network node, e.g., an SN, for handling an SCG operation mode by requesting a first network node, e.g., an MN, to change the SCG operation mode, and a method therein.

[0035] The second network node may receive information that enables the second network node to determine an SCG operation mode, for example an activity notification message received by the second network node.

[0036] The second network node sends a request to the first network node for a change of SCG operation mode.

[0037] The second network node receives a response from the first network node, where the change of the SCG operation mode may be accepted or rejected by the first network node.

[0038] If the change of the SCG operating mode is rejected, the response from the first network node includes an indication of the reason for the rejection.

[0039] According to some embodiments herein, the first network node may be operating as a Master Node (MN) for a UE configured with MR-DC having a Master Cell Group (MCG) and a Secondary Cell Group (SCG). The request for a change in SCG operation mode may be an SN-initiated request that may be rejected by the MN.

[0040] According to some embodiments herein, the second network node may be operating as a secondary node (SN) for a UE configured with MR-DC. The request for an SCG operation mode change may be an SN-initiated request that may be rejected by the MN.

[0041] According to some embodiments herein, the first network node may be operating as a secondary node (SN) for a UE configured with MR-DC. The request for an SCG operation mode change may be an MN-initiated request that may be rejected by the SN.

[0042] According to some embodiments herein, the second network node may be operating as a Master Node (MN) for a UE configured with MR-DC. The request for a change in SCG operation mode may be an MN-initiated request that may be rejected by the SN.

[0043] In other words, according to the embodiment of the present specification, when the MN rejects the request for SCG (de)activation, it notifies the SN of the detailed reason.When the SN rejects the request for SCG (de)activation, it notifies the MN of the detailed reason.

[0044] Advantages of the embodiments herein include the following: To help the SN understand the reason for rejection of SCG (de)activation and be adequately prepared for its own resource allocation. Enabling the SN to take further actions depending on the exact cause value, e.g., freeing SCG resources.

[0045] A similar advantage exists in the case of MN.

[0046] The rejection reason is important for the SN to make a decision on further possible actions, e.g., whether or when to request again a change in the SCG operation mode and / or whether or when to release the SCG and / or whether or when to change the PSCell. For example, if the reason for the rejection of the SCG activation is overheating of the UE, the SN should wait before sending the activation request again. On the other hand, if the reason for the rejection of the SCG deactivation is that the MN expects more data, the SN can resend the deactivation request once the data has been transmitted.

[0047] Accordingly, embodiments herein provide an improved method for handling a Master Cell Group (MCG) and a Secondary Cell Group (SCG) mode of operation for a communications device operating in a dual connection with a Master Cell Group (MCG) and a Secondary Cell Group (SCG) of a network node in a wireless communications network.

[0048] Example embodiments herein will be described in more detail with reference to the accompanying drawings. [Brief description of the drawings]

[0049] [Figure 1] FIG. 1 is a schematic block diagram illustrating dual connectivity combined with carrier aggregation in MR-DC. [Diagram 2] FIG. 1 is a schematic block diagram showing E-UTRAN-NR dual connection. [Diagram 3] A schematic block diagram showing NR-DC, in which both the master node controlling the MCG and the secondary node controlling the SCG are NR. [Figure 4] FIG. 1 is a schematic block diagram illustrating a control plane architecture for dual connectivity in LTE DC, EN-DC, and NR-DC. [Diagram 5] A schematic block diagram showing network side protocol termination options for MCG, SCG, and split DRB in MR-DC (EN-DC) with EPC. [Figure 6] A schematic block diagram showing network side protocol termination options for MCG, SCG, and split DRB in MR-DC (NGEN-DC, NE-DC, and NR-DC) with 5GC. [Figure 7] FIG. 1 is a schematic block diagram illustrating dormancy-like behavior for SCell in NR. [Figure 8] FIG. 1 is a schematic block diagram illustrating a wireless communication network. [Figure 9] 4 is a signal flow diagram illustrating an exemplary embodiment of a method performed by a first network node according to embodiments herein. [Figure 10] 11 is a flowchart illustrating an example embodiment of a method performed by a second network node, according to embodiments herein. [Figure 11] 11 is a signal flow diagram illustrating another example according to embodiments herein. [Figure 12] 1 is a schematic block diagram illustrating an exemplary embodiment of a communication device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0050] FIELD OF THE DISCLOSURE The embodiments herein generally relate to communication networks. Figure 8 is a schematic diagram illustrating a communication network 800. The communication network 800 may be a wireless communication network comprising one or more RANs and one or more CNs. The communication network 800 may use several different technologies, such as Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, NR, Wideband Code Division Multiple Access (WCDMA), GSM / Enhanced Data Rates for GSM Evolution (GSM / EDGE), WiMax, or Ultra Mobile Broadband (UMB), to name a few possible implementations.

[0051] In the wireless communication network 800, one or more wireless communication devices 830, 831, such as UEs, mobile stations, or wireless terminals, communicate with one or more core networks (CNs) via one or more radio access networks (RANs). Those skilled in the art should understand that a "wireless communication device" is a non-limiting term meaning any terminal, wireless communication terminal, user equipment, machine type communication (MTC) device, device-to-device (D2D) terminal, or node, such as a smartphone, laptop, mobile phone, sensor, relay, mobile tablet, or even a small base station communicating within a cell.

[0052] Network nodes such as a first network node 811 and a second network node 812 operate in the wireless communication network 800. The first network node 811 and the second network node 812 can be any of RAN nodes such as gNB, eNB, en-gNB, ng-eNB, gNB, etc. The first network node 811 provides wireless coverage over a geographical area, service area 11, also sometimes referred to as a beam or beam group, where the beam group covers a service area of ​​a first radio access technology (RAT), such as 5G, LTE, Wi-Fi, etc. The second network node 812 provides wireless coverage over a geographical area, service area 12, also sometimes referred to as a beam or beam group, where the beam group covers a service area of ​​a first or second radio access technology (RAT), such as 5G, LTE, Wi-Fi, etc. It should be noted that the network nodes can be RAN nodes, CN nodes, or OAM nodes.

[0053] The first and second network nodes 811 and 812 may be transmitting and receiving points, e.g., radio access network nodes such as wireless local area network (WLAN) access points or access point stations (AP STAs), access controllers, base stations, e.g., NodeB, gNB, evolved Node B (eNB, eNode B), base transceiver stations, wireless remote units, access point base stations, base station routers, transmission configurations of radio base stations, standalone access points, or any other network units capable of communicating with wireless communication devices in a service area served by each of the first and second network nodes 811 and 812, e.g., depending on the radio access technology and terminology used. The first network node 811 and the second network node 812 may be referred to as source network node and target network node, respectively, and may communicate with the wireless communication devices 830, 831 by downlink (DL) transmissions to and uplink (UL) transmissions from the wireless communication devices 830, 831.

[0054] As shown in FIG. 1, the first and second network nodes 1211, 1212 may each be either a master node (MN) having a master cell group MCG, or a secondary node (SN) having a secondary cell group SCG.

[0055] The description herein describes terms such as SCG and PSCell as one of the cells associated with the SCG, which may be a PSCell defined in the NR specifications, e.g., RRC TS38.331, or a primary SCG cell (PSCell), which is defined as a special cell (SpCell) of the SCG, for example, as follows: - Secondary Cell Group: For a UE configured with dual connectivity, a subset of serving cells consisting of a PSCell and zero or more secondary cells (SCells). - Special cell: In case of dual connectivity operation, the term special cell refers to a PCell of an MCG or a PSCell of an SCG, otherwise the term special cell refers to a PCell. - Primary SCG Cell (PSCell): In case of dual connectivity operation, the SCG cell which performs random access when the UE performs a reconfiguration procedure with synchronization.

[0056] For brevity, the description herein primarily refers to and illustrates examples in which the second cell group is a secondary cell group (SCG) that is deactivated or suspended or in a power saving mode of operation for a UE configured with multi-radio dual connectivity (MR-DC). However, the method is equally applicable to cases in which the second cell group is a master cell group (MCG) for a UE configured with dual connectivity (e.g., MR-DC), where the MCG may be suspended while the SCG is operating in normal mode.

[0057] The description herein describes the UE stopping monitoring the PDCCH on the SCG cells, i.e., stopping monitoring the PDCCH of the PSCells and SCells of the SCG, when the second cell group is deactivated, e.g., when the SCG is deactivated upon receiving an indication from a network node. The solution is mainly described using the second cell group as an example, which is a secondary cell group in which the UE configured with MR-DC is configured, and the SCG is in a deactivated operation mode in the UE when the UE performs the actions disclosed in the method. However, the method is also applicable in the case where the second cell group is assumed to be a deactivated Master Cell Group (MCG), and thus the UE stops monitoring the PDCCH on the MCG and continues to monitor the PDCCH on the SCG.

[0058] Accordingly, the description herein primarily refers to and illustrates examples in which the first cell group is a Master Cell Group (MCG) for a UE configured with Multi-Radio Dual Connectivity (MR-DC). However, the method is equally applicable when the first cell group is a Secondary Cell Group (SCG) that is deactivated or suspended or in a power saving mode of operation for a UE configured with Multi-Radio Dual Connectivity (MR-DC).

[0059] According to an embodiment herein, there is provided a method performed by a first network node 811, e.g., a MN or a SN, for handling SCG operation mode change in a wireless communication network 800. The method is described in detail with reference to Figure 9, where SCG activation / deactivation is initiated by the SN and actions or steps performed by the first network node 811 are shown. The method includes the following operations, which may be performed in any suitable order:

[0060] Action 911 This action is optional. The MN, i.e. the first network node 811, may receive a UE assistance information message from a UE, e.g. the first communication device 830. This message contains information that the UE wants to relay to the network node for information about the UE status. This message may contain assistance information, e.g. regarding UE overheating, UE power saving. Information regarding UE power saving may be maximum aggregated bandwidth, maximum number of component carriers, maximum number of MIMO layers, etc.

[0061] Action 912 This action is optional. The first network node 811 may send an activity notification message to an SN, for example the second network node 812. This message contains the information that there is user plane traffic on a particular session or that there is no user plane traffic on a particular session.

[0062] Action 913 The first network node 811 receives a request from a second network node 812, for example an SN or MN, to change the operation mode of the SCG.

[0063] The request may be an S-NODE MODIFICATION REQUIRED, with a request for the SCG to be activated or deactivated.

[0064] The request may be an S-NODE MODIFICATION REQUEST, with a request for an SCG to be activated or deactivated.

[0065] In other words, the request includes an indication of a change in the operating mode for the SCG that the second network node 812 proposes to, for example, deactivate or activate the SCG.

[0066] According to some embodiments herein, the second network node 812 may request the first network node 811 to change the SCG in a deactivated mode to an activated mode of operation.

[0067] According to some embodiments herein, the second network node 812 may request the first network node 811 to change the SCG in an activated mode to a deactivated mode of operation.

[0068] Action 914 The first network node 811 decides whether to accept or reject the request for a change in the SCG operation mode, for example based on received UE assistance information or current UE traffic conditions.

[0069] Action 915 If the change in SCG configuration and / or the change in SCG operation mode is accepted, the first network node 811 sends a message to the UE including a reconfiguration or a command to change the SCG configuration and / or the SCG operation mode.

[0070] Action 916 The first network node 811 receives a response from the UE, for example an RRC reconfiguration complete message.

[0071] If the changes in the SCG settings and the SCG operation mode are not accepted, the above actions 915 and 916 are not performed and the first network node 811 performs the following actions instead: If the changes in the SCG settings are accepted but the change in the SCG operation mode is not accepted, the first network node 811 performs the above actions 915 and 916 and further performs the following actions:

[0072] Action 917 The first network node 811 sends a response to a second network node 812, eg, an SN or MN, where the change of SCG mode is either accepted or rejected.

[0073] In one alternative, the first network node 811 may not accept the requested change of the SCG operation mode but may accept other changes to the SCG configuration. In this case, rejection of the requested operation mode may be indicated by the first network node 811 sending an acknowledgement message, e.g., an S-NODE MODIFICATION CONFIRM or an S-NODE MODIFICATION REQUEST ACKNOWLEDGE, including an indication that the SCG operation mode change is rejected and a reason for the rejection, e.g., UE overheating, UE power saving preferences, expected new data, etc.

[0074] In another alternative, the first network node 811 does not accept the requested change of the SCG operation mode or any other change to the SCG configuration. In this case, the rejection is indicated by the first network node 811 sending an S-NODE MODIFICATION REFUSE or S-NODE MODIFICATION REQUEST REJECT message. Possibly, this can be indicated by a new cause value or multiple cause values ​​in the message, e.g. UE overheating, UE power saving preferences, new data expected, etc. Additionally, this can indicate that the reason for not accepting the SCG configuration was due to not accepting the change of operation mode, i.e. that if the second network node 812 sends another S-NODE request modification or S-NODE modification request with a different SCG operation mode, it will be accepted.

[0075] Further examples of cause values ​​upon rejection of activation may be, for example, lack of resources, UE out of coverage of PSCell / SCG, etc. Further examples of cause values ​​upon rejection of deactivation may be, for example, the network node is not expecting much data, releasing and / or deactivating / suspending the UE soon, which may include an indication to release resources and / or suspend resources, etc.

[0076] According to an embodiment herein, there is provided a method performed by a second network node 812, e.g., a MN or a SN, for handling SCG operation mode change in a wireless communication network 800. The method is described in detail with reference to Figure 10, where SCG activation / deactivation is initiated by a SN, e.g., a second network node 811, and actions or steps performed by the second network node 812 are shown. The method includes the following operations, which may be performed in any suitable order.

[0077] Action 1010 This action is optional. The second network node 812 may receive an activity notification message from the first network node 811. The second network node 812 may decide to change an operation mode of a secondary cell group (SCG) configuration, for example from deactivated to activated or from activated to deactivated, based on, for example, the received activity notification, based on measurement reports received from the UE, and / or based on further inputs such as traffic requests.

[0078] Action 1020 The second network node 812 sends a request to the first network node 811 to change the SCG operation mode from activated to deactivated or from deactivated to activated, for example a SN modification request.

[0079] Action 1030 The second network node 812 receives a response from the first network node 811, where the modification of the SCG operation mode can be accepted or rejected.

[0080] In one alternative, the second network node 812 may receive a response from the first network node 811, in which the modification of the SCG operation mode is rejected, but other modifications of the SCG may be accepted. The reason for the rejection of the operation mode change is indicated in an acknowledgement message, e.g., an S-NODE MODIFICATION CONFIRM or an S-NODE MODIFICATION REQUEST ACKNOWLEDGE, that includes an indication that the SCG operation mode change is rejected and the reason for the rejection, e.g., UE overheating, UE power saving preferences, new data expected, etc.

[0081] In another alternative, the second network node 812 may receive a response from the first network node 811 that the modification of the SCG operation mode is rejected. The rejection may be indicated in an S-NODE MODIFICATION REFUSE or an S-NODE MODIFICATION REQUEST REJECT, possibly with a new cause value or multiple cause values, e.g., UE overheating, UE power saving preferences, new data expected, etc.

[0082] Further examples of cause values ​​upon rejection of activation may be, for example, lack of resources, UE out of coverage of PSCell / SCG, etc. Further examples of cause values ​​upon rejection of deactivation may be, for example, that the network node is not expecting much data and will release and / or deactivate / suspend the UE soon, which may include an indication to release resources and / or suspend resources.

[0083] The above-described methods for the first and second network nodes 811, 812 for handling SCG operation mode changes assume that the SCG activation / deactivation is initiated by the SN. However, the above-described methods may be equally applicable to situations where the SCG activation / deactivation is initiated by the MN. Figure 11 shows such an example where the SCG activation / deactivation is initiated by the MN and the actions taken in the MN and SN when the change in SCG configuration and operation mode is not accepted. Actions 1111, 1113, 1114, 1117 correspond to the above-described actions 911, 913, 914, 917 shown in Figure 9.

[0084] According to an embodiment herein, a method is provided for handling SCG operation mode change in a wireless communication network 800, performed by a communication device 830. The communication device 830 sends UE assistance information to the MN. The communication device 830 receives a reconfiguration or command from the MN for a change in SCG configuration and / or a change in SCG operation mode, e.g., from activation to deactivation or from deactivation to activation, and sends a response, e.g., an RRC reconfiguration complete message, to the MN.

[0085] To perform the method in the first / second network node 811 / 812, the first / second network node 811 / 812 includes modules shown in Fig. 12. The first / second network node 811 / 812 includes a receiving module 1210, a sending module 1220, a determining module 1230, a processing module 1240, a memory 1250, etc.

[0086] The first / second network node 811 / 812 is configured to perform any one of the actions 911-917, 1010-1030 described above.

[0087] The methods according to the embodiments herein may be implemented through one or more processors, such as the processor 1260 in the network node 811 / 812, with computer program code for performing the functions and actions of the embodiments herein. The above-mentioned program code may also be provided as a computer program product, for example in the form of a computer readable medium or data carrier 1280 carrying the computer program code 1270 shown in FIG. 12, when loaded into the network node 811 / 812, for performing the embodiments herein. One such carrier may be in the form of a CD-ROM disk. However, it is realizable on other data carriers, such as a memory stick. The computer program code may further be provided as pure program code on a server or cloud and downloaded to the network node 811 / 812.

[0088] Some exemplary embodiments are listed below.

[0089] Embodiment 1: A method performed by a first network node 811 for handling an SCG operation mode change in a wireless communication network 800, the method comprising: receiving a request from a second network node for a change in an SCG mode of operation; determining whether to accept or reject a request to change the SCG operating mode; if it is decided to reject the request for the change of the SCG operation mode, sending a response to the second network node together with an indication of the reason for the rejection. A method comprising:

[0090] Embodiment 2: A method performed by a second network node 812 for handling an SCG operation mode change in a wireless communication network 800, the method comprising: Sending a request to a first network node for a change in an SCG operation mode; receiving a response from the first network node, if it is determined by the first network node to reject the request for the change of the SCG operating mode, together with an indication of the reason for the rejection; A method comprising:

Claims

1. 1. A method performed in a first network node (811) for handling a second network node operation mode change for a communication device (830) in a wireless communication network (800), the communication device (830) being configured with Multi-Radio Dual Connectivity (MR-DC), the first network node (811) having a first group of cells and the second network node (812) having a second group of cells, the method comprising: receiving (913) a request from the second network node (812) for a change in an operation mode for the second cell group and a change in a configuration of the second cell group; determining whether to accept or reject the request to change the operating mode and the settings (914); If it is decided to reject the request for the change of the operational mode, sending (917) a response to the second network node (812) with an indication of the reason for the rejection. Including, If it is determined that the requested change in operational mode for the second cell group is rejected but the change in the setting of the second cell group is accepted, sending (917) a response to the second network node (812) with an indication is performed by sending an acknowledgement message to the second network node (812) including an indication indicating that the change in operational mode is rejected and the reason for the rejection.

2. The method of claim 1, wherein the request to change the operating mode for the second cell group includes an indication that the change in operating mode is a change from a deactivated mode to an activated mode for the second cell group, or a change from an activated mode to a deactivated mode.

3. 2. The method of claim 1, wherein if it is determined that the requested change in operation mode and any other changes to the configuration of the second cell group are not acceptable, sending (917) a response with an indication to the second network node (812) is performed by sending a rejection or denial message to the second network node (812) including one or more cause values.

4. The method of claim 3 , wherein the rejection of the change in configuration of the second cell group is due to a failure to accept a change in an operating mode of the second cell group.

5. The method of claim 1, further comprising the first network node receiving an assistance information message from the communication device, the assistance information message including information regarding a state of the communication device.

6. The method of claim 5 , wherein the condition of the communication device (830) comprises one of the following: overheating, power conservation.

7. 6. The method of claim 5, wherein determining whether to accept or reject the request to change the operational mode and the setting (914) is based on aiding information or traffic conditions of the communication device (830).

8. 1. A method performed in a second network node (812) for handling an operation mode change for a communication device (830) in a wireless communication network (800), the communication device (830) being configured with Multi-Radio Dual Connectivity (MR-DC), the first network node (811) having a first group of cells and the second network node (812) having a second group of cells, the method comprising: sending (1020) a request to the first network node (811) for a change of operation mode for the second cell group and a change of configuration of the second cell group; receiving (1030) from the first network node (811) a response having an indication of a reason for refusal if it is determined by the first network node (811) that the request for the change of the operating mode and the change of the settings is rejected; Including, If the first network node (811) determines that the change in operating mode requested for the second cell group is rejected but the change in the settings of the second cell group is accepted, the reason for the rejection is indicated in an acknowledgement message received from the first network node (811).

9. 9. The method of claim 8, wherein if it is determined by the first network node (811) that the requested change in operating mode and any other changes to the configuration of the second cell group are not acceptable, the reason for rejection is indicated in a rejection or refusal message including one or more cause values ​​received from the first network node (811).

10. The method of claim 1 or 8, wherein for the communication device (830) configured with MR-DC having a Master Cell Group (MSG) and a Secondary Cell Group (SCG), the first network node (811) is operating as a Master Node (MN) and the second network node (812) is operating as a Secondary Node (SN).

11. The method of claim 1 or 8, wherein for the communication device (830) configured with MR-DC having a Master Cell Group (MSG) and a Secondary Cell Group (SCG), the first network node (811) is operating as a Secondary Node (SN) and the second network node (812) is operating as a Master Node (MN).

12. The reason for rejecting a change from a deactivated mode to an activated mode is: a) overheating of the communication device (830); b) power saving preferences of said communications device (830); c) Lack of resources; d) the communication device (830) is out of coverage of the second cell group; The method according to claim 1 or 8, wherein the method is any one of the following:

13. The reason for rejecting a change from an activated mode to a deactivated mode is: a) new data is expected; b) the second network node is about to release and / or deactivate / suspend The method according to claim 1 or 8, wherein the method is any one of the following:

14. A first network node (811) for handling a second network node operation mode change for a communication device (830) in a wireless communication network (800), the communication device (830) being configured with Multi-Radio Dual Connectivity (MR-DC), the first network node (811) having a first cell group and a second network node (812) having a second cell group, the first network node (811) comprising: receiving a request from the second network node (812) for a change in an operation mode for the second cell group and a change in a configuration of the second cell group; determining whether to accept or reject the request to change the operating mode and the setting; if it is decided to reject the request for the change of the operating mode, sending a response to the second network node (812) together with an indication of the reason for the rejection. configured to: If it is determined that the change in the operating mode requested for the second cell group is rejected but the change in the setting of the second cell group is accepted, the first network node (811) sends a response to the second network node (812) together with an indication, which is executed by sending an acknowledgement message to the second network node (812) including an indication indicating that the change in the operating mode is rejected and the reason for the rejection.

15. A first network node (811) according to claim 14, adapted to carry out the method according to any one of claims 2 to 7.

16. A second network node (812) for handling an operation mode change for a communication device (830) in a wireless communication network (800), the communication device (830) being configured with Multi-Radio Dual Connectivity (MR-DC), the first network node (811) having a first group of cells, the second network node (812) having a second group of cells, the second network node (812) comprising: sending a request to the first network node (811) for a change of operation mode for the second cell group and a change of configuration of the second cell group; receiving a response from the first network node (811) having an indication of the reason for the refusal if it is determined by the first network node (811) that the request for the change of the operating mode and the change of the settings is rejected; configured to: If the first network node (811) determines that the change in operating mode requested for the second cell group is rejected but the change in the settings of the second cell group is accepted, the reason for the rejection is indicated in an acknowledgement message received from the first network node (811), a second network node (812).

17. A second network node (812) according to claim 16, configured to perform the method according to claim 9.

18. 1. A method for handling an operation mode change for a communication device (830) in a wireless communication network (800), the communication device (830) being configured with Multi-Radio Dual Connectivity (MR-DC), a first network node (811) having a first group of cells, and a second network node (812) having a second group of cells, the method comprising: sending (1020) by the second network node (812) to the first network node (811) a request for a change of an operation mode for the second cell group and a change of a configuration of the second cell group; receiving (913) the request from the second network node (812), by the first network node (811); determining (914) whether to accept or reject the request for the change of the operating mode and the change of the settings by the first network node (811); sending (917) by the first network node (811) a response to the second network node (812) together with an indication of the reason for the refusal if it is decided to reject the request for the change of the operating mode. Including, If it is determined that the requested change in operational mode for the second cell group is rejected but the change in the setting of the second cell group is accepted, sending (917) a response to the second network node (812) with an indication is performed by sending an acknowledgement message to the second network node (812) including an indication indicating that the change in operational mode is rejected and the reason for the rejection.

19. 1. A communications system for handling an operation mode change for a communications device (830) in a wireless communications network (800), the communications device (830) being configured with Multi-Radio Dual Connectivity (MR-DC), a first network node (811) having a first group of cells and a second network node (812) having a second group of cells, the communications system comprising: sending, by the second network node (812), a request to the first network node (811) for a change of operation mode for the second cell group and a change of configuration of the second cell group; receiving, by the first network node (811), the request from the second network node (812); determining, by the first network node (811), whether to accept or reject the request for the change of the operation mode and the change of the settings; sending, by said first network node (811) to said second network node (812), a response together with an indication of the reason for the refusal if it is decided to reject said request for the change of said operating mode. configured to: If it is determined that the requested change in operating mode for the second cell group is rejected but the change in the setting of the second cell group is accepted, sending a response to the second network node (812) together with an indication is performed by sending an acknowledgement message to the second network node (812) including an indication indicating that the change in operating mode is rejected and the reason for the rejection.

Images