Managing a cell group in dual connectivity

Abstract

A network node of a radio access network (RAN) in communication with a user equipment (UE) in dual connectivity (DC) with a master node (MN) and a secondary node (SN) can implement a method for managing deactivation of a secondary cell group (SCG). The method includes detecting (1802) that a condition to deactivate the SCG is met. The method also includes determining (1804) whether the UE supports deactivation of the SCG, and causing (1806) the SN to deactivate or release the SCG at the SN based on the determination.

Description

Technical Field

[0001] This disclosure generally relates to wireless communications, and more specifically, to deactivating and activating connections on cell groups such as secondary cell groups (SCGs). Background Technology

[0002] The purpose of providing this background description is to present the overall context of this disclosure. The operations of the currently named inventors, to the extent described in this background section, and aspects that may not qualify as prior art at the time of filing, are neither expressly nor implicitly acknowledged as prior art to this disclosure.

[0003] In some cases, a user equipment (or user equipment, often abbreviated as "UE") can simultaneously utilize the resources of multiple network nodes (e.g., base stations) interconnected via backhaul. When these network nodes support the same radio access technology (RAT) or different RATs, this type of connection is referred to as dual connectivity (DC) or multi-radio DC (MR-DC), respectively. Typically, when a UE operates in a DC or MR-DC, one base station operates as the primary node (MN), while another base station operates as the secondary node (SN). For example, the backhaul may support X2 or Xn interfaces.

[0004] The MN can provide control plane and user plane connections to the core network (CN), while the SN typically only provides user plane connections. Cells associated with the MN define the primary cell group (MCG), and cells associated with the SN define the secondary cell group (SCG). The UE, along with the base stations MN and SN, can use signaling radio bearers (SRBs) to exchange radio resource control (RRC) messages and non-access stratum (NAS) messages.

[0005] Several types of SRBs can be used when a UE operates in a DC. SRB1 and SRB2 resources allow the UE and MN to exchange MN-related RRC messages and embed SN-related RRC messages, and can be referred to as MCG SRBs. SRB3 resources allow the UE and SN to exchange SN-related RRC messages and can be referred to as SCG SRBs. Decoupled SRBs allow the UE to directly exchange RRC messages with the MN using the radio resources of the MN, SN, or both. Furthermore, the UE and base station (e.g., MN and SN) use data radio bearers (DRBs) to transmit data on the user plane. A DRB that terminates at the MN and uses only the lower-layer resources of the MN can be referred to as an MCG DRB; a DRB that terminates at the SN and uses only the lower-layer resources of the SN can be referred to as an SCG DRB; and a DRB that terminates at either the MN or SN but uses the lower-layer resources of both the MN and SN can be referred to as a decoupled DRB. A DRB that terminates at the MN but uses only the lower-layer resources of the SN can be referred to as an MN-terminated SCG DRB. A DRB that terminates at SN but only uses lower-level resources of MN can be referred to as an SN-terminated MCG DRB.

[0006] Operating in the DC with both the MN and SN places high power demands on the UE. Furthermore, the amount of data the UE must exchange with the SN varies over time. For example, initially, the UE may have no data to exchange with the SN. As a result, the UE may consume significant power to support links with SNs that are not actively used by the UE. However, shortly afterward, the UE may have data to exchange with the SN. Therefore, when there is low data activity from the UE, releasing the SN may be inefficient, as the RAN may quickly request the restoration of the released SN.

[0007] One way to address this inefficiency is for the UE and RAN to deactivate the SCG, which causes the SN and UE to suspend communication via the SCG without releasing it. However, some UEs may not support SCG deactivation. If the RAN instructs a UE that does not support SCG deactivation to deactivate the SCG, the UE will not comply with the instruction. Furthermore, the UE may not be able to interpret instructions from the RAN, potentially causing the UE to unnecessarily trigger the RRC connection re-establishment process.

[0008] Furthermore, even in scenarios where the UE supports SCG deactivation, it is unclear how the RAN will determine whether to deactivate or release the SCG. Summary of the Invention

[0009] Network nodes of the RAN and / or UE can use the techniques disclosed herein to manage SCG deactivation. For example, as described above, the RAN may not know whether the UE supports SCG deactivation (and / or activation). Therefore, the UE can send capability information to the RAN indicating whether the UE supports SCG deactivation. The capability information can explicitly indicate that the UE supports both SCG deactivation and SCG activation, or the RAN can determine that the UE supports SCG activation based on the UE's support for SCG deactivation.

[0010] In some scenarios, the MN and SN can communicate with the UE via different RATs. For example, in an (NG)EN-DC, the MN can be a MeNB or Mng-eNB supporting the 4G LTE RAT, and the SN can be an SgNB supporting the 5G NR RAT. In this scenario, if the UE sends a single Capability Information Element (IE) formatted according to a specific RAT, the MN or SN may not be able to interpret the IE. For example, the UE may indicate support for SCG deactivation in a UE-EUTRA-Capability IE in EUTRA RRC ASN.1 format. However, even if the MN receives and forwards the IE to the SN, the SN will not be able to interpret the UE-EUTRA-Capability IE because the gNB cannot interpret EUTRA RRC ASN.1 messages. The SN will therefore be unable to initiate SCG deactivation for the UE. Similarly, if the UE wants to indicate support for SCG deactivation in a UE-MRDC-Capability IE in NR RRC ASN.1 format, the MN will not be able to interpret the IE and will be unable to initiate SCG deactivation.

[0011] Therefore, depending on the scenario, the UE can send capability information to the RAN, including (i) a single capability IE indicating whether the UE supports SCG deactivation (e.g., NR-MRDC-Capability IE if both MN and SN are gNBs), or (ii) two capability IEs formatted according to two different RATs (e.g., UE-EUTRA-Capability IE and NR-MRDC-Capability IE). The MN or SN can then identify whether the UE supports deactivation based on the capability information.

[0012] If the RAN network node (e.g., MN or SN) determines that the conditions for deactivating the SCG are met, the network node can determine whether the UE's capability information indicates that the UE supports deactivating the SCG. The network node can receive capability information from the UE, another base station, or the CN. For example, if the network node is the SN, it can receive capability information from the MN. The MN can forward capability information that can be read by the SN to the SN (e.g., NR-MRDC-Capability IE if the SN is a gNB).

[0013] In scenarios where the UE supports deactivating the SCG, the network node causes the SN to deactivate the SCG. Optionally, in scenarios where the UE does not support deactivating the SCG, the network node causes the SN to release the SCG. If the network node is the SN and the UE supports deactivating the SCG, the SN can deactivate or release the SCG at the SN. The SN can send a message to the MN, notifying the MN to deactivate or release the SCG, and including an indication that the UE should deactivate or release the SCG; the MN can then send this indication to the UE. If the network node is the MN, the MN can send a message to the SN to deactivate or release the SCG, and can also send an instruction to the UE to deactivate or release the SCG.

[0014] While the examples discussed below primarily concern deactivating the SCG, the UE and / or RAN can use similar techniques to determine whether to activate the SCG. For example, a network node can detect that conditions for SCG activation (e.g., by detecting data activity on the SCG used by the UE) have been met. In response, the network node can determine whether the UE's capability information indicates that the UE supports SCG activation. If so, the network node can trigger SN activation of the SCG. Otherwise, the network node refrains from activating the SCG. For example, instead of activating the SCG, the network node can perform an SN addition procedure.

[0015] An example embodiment of these technologies is a method for managing the deactivation of a secondary cell group (SCG) in a network node of the RAN, the network node communicating with a UE, the UE being in a DC with both the MN and SN. The method can be executed by processing hardware and includes detecting whether conditions for deactivating the SCG are met. The method also includes determining whether the UE supports deactivating the SCG, and based on this determination, causing the SN to deactivate or release the SCG at the SN.

[0016] Another example embodiment of these technologies is a network node that includes processing hardware and is configured to implement the methods described above.

[0017] Another example embodiment of these technologies is a method for managing the deactivation and activation of a secondary cell group (SCG) in a UE, which communicates with a radio access network (RAN) via a primary node (MN) and a secondary node (SN) in dual connectivity (DC). This method can be executed by processing hardware and includes providing the RAN with information indicating whether the UE supports deactivating the SCG. The method also includes receiving an instruction from the RAN that the UE wants to deactivate or release the SCG, and deactivating or releasing the SCG at the UE according to the instruction.

[0018] Another example embodiment of these technologies is a UE that includes processing hardware and is configured to implement the methods described above. Attached Figure Description

[0019] Figure 1A This is a block diagram of an example wireless communication system in which one or more base stations and / or user equipment (UE) can implement the techniques disclosed herein for deactivating and activating SCG between the UE and SN;

[0020] Figure 1B This is another block diagram of an example system in which the radio access network (RAN) and UE can implement the techniques disclosed herein for deactivating and activating SCGs associated with the SN;

[0021] Figure 1C It is possible Figure 1A or Figure 1B A block diagram of an example base station operating in the system, including centralized units (CU) and distributed units (DU);

[0022] Figure 2 This is a block diagram of an example protocol stack. Based on this example protocol stack, Figure 1A or Figure 1B The UE can communicate with the base station;

[0023] Figure 3A This is a sequence of SCG example messages where the primary node (MN) causes the secondary node (SN) to deactivate or release the SCG for the UE;

[0024] Figures 3B-3C This is an example message sequence in which the SN deactivates or releases the SCG used by the UE;

[0025] Figure 3D This is an example message sequence in which the MN receives an RRC recovery request message and, in response to the message, causes the SN to deactivate or release the SCG used by the UE;

[0026] Figure 4A It is similar to Figure 3B An example message sequence, but in which the CU of the SN determines whether to deactivate or release the SCG;

[0027] Figure 4B It is similar to Figure 3B An example message sequence, but in which the DU of SN determines whether to deactivate or release SCG;

[0028] Figure 5A It is similar to Figure 4A An example message sequence, but in which the portion from a single base station acts as MN and SN;

[0029] Figure 5B It is similar to Figure 4B An example message sequence, but in which the portion from a single base station acts as MN and SN;

[0030] Figures 6A-6B This is a flowchart of an example method that can be implemented by the UE to request the SCG to be deactivated or activated;

[0031] Figure 7 This is a flowchart of an example method that can be implemented by the UE for sending (i) a first UE SCG deactivation capability readable by the MN and (ii) a second UE SCG deactivation capability readable by the SN to the RAN;

[0032] Figure 8 This is a flowchart of an example method that can be implemented by the UE to send a UE SCG deactivation capability that is readable by both the MN and SN to the RAN;

[0033] Figure 9 This is a flowchart of an example method for sending an indication to the RAN whether the UE supports the UE SCG deactivation capability for different DC band combinations;

[0034] Figure 10 This is a flowchart of an example method that can be implemented by MN to determine whether to cause SN to deactivate or release SCG;

[0035] Figure 11 This is a flowchart of an example method that can be implemented by SN to determine whether to deactivate or release SCG;

[0036] Figure 12 This is a flowchart of an example method that can be implemented by the CU of the SN to determine whether to cause the DU of the SN to deactivate or release the SCG;

[0037] Figure 13 This is a flowchart of an example method that can be implemented by the DU of the SN to determine whether to deactivate or release the SCG;

[0038] Figure 14 This is a flowchart of an example method for deactivating and releasing cell groups (CGs) that can be implemented by the RAN;

[0039] Figure 15 This is a flowchart of an example method for deactivating SCG, which can be implemented by SN;

[0040] Figure 16A This is a flowchart of an example method that can be implemented by the RAN to determine whether to reactivate the SCG in response to a CN-to-BS interface message;

[0041] Figure 16B This is a flowchart of an example method that can be implemented by the RAN to determine whether to reactivate the SCG in response to receiving a data packet from the CN;

[0042] Figure 17 This is a flowchart of an example method that can be implemented by MN to determine whether to reactivate SCG in response to an RRC recovery request message;

[0043] Figure 18 It can be made by Figures 1A-1C A flowchart illustrating an example method for managing SCG deactivation implemented by a network node; and

[0044] Figure 19 It can be made by Figure 1A-Figure 1B The flowchart shows an example method for managing the deactivation of SCG implemented by the UE. Detailed Implementation

[0045] As discussed in detail below, for example, network nodes of the radio access network (RAN) communicating with the UE can implement the techniques disclosed herein to manage multiple radio dual connectivity (MR-DC) in scenarios involving distributed base station architectures and scenarios involving suspension and resumption of dual connectivity. Before discussing these techniques, refer to Figure 1A-Figure 1B Consider example communication systems that can implement these technologies.

[0046] Figure 1A An example wireless communication system 100 is depicted, including a UE 102, a base station (BS) 104A, a base station 106A, and a core network (CN) 110. Base stations 104A and 106A can operate in a RAN 105 connected to the same core network (CN) 110. For example, CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth-generation (5G) core (5GC) 160.

[0047] In addition to other components, EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. SGW 112 is typically configured to transmit user plane packets related to audio calls, video calls, internet traffic, etc., and MME 114 is configured to manage authentication, registration, paging, and other related functions. PGW 116 provides connectivity from the UE to one or more external packet data networks, such as the Internet and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. 5GC 160 includes a User Plane Function (UPF) 162 and Access and Mobility Management (AMF) 164, and / or Session Management Function (SMF) 166. Generally, UPF 162 is configured to transmit user plane packets related to audio calls, video calls, internet traffic, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0048] like Figure 1A As shown, base station 104A supports cell 124A, and base station 106A supports cell 126A. Base station 106A may additionally support cell 125A. Cells 124A and 126A may partially overlap, allowing UE 102 to communicate in the DC of base stations 104A and 106A, which operate as a primary node (MN) and secondary node (SN), respectively. Cells 125A and 126A may partially overlap, allowing UE 102 to communicate in the CA or DC of base station 106A, which operates as a primary node (MN) and secondary node (SN), respectively. To directly exchange messages during DC scenarios and other scenarios discussed below, base station 104A (also referred to herein as MN104A) and base station 106A (also referred to herein as SN 106A) may support X2 or Xn interfaces. Typically, CN 110 can connect to any suitable number of base stations supporting 5G New Radio (NR) cells and / or EUTRA cells.

[0049] like Figure 1A As shown, base station 104A supports cell 124A, and base station 106A supports cell 126A. Cells 124A and 126A can partially overlap, allowing UE 102 to communicate in the DC with base stations 104A and 106A, which operate as the primary node (MN) and secondary node (SN), respectively. To directly exchange messages during DC scenarios and other scenarios discussed below, MN 104A and SN 106A can support X2 or Xn interfaces. Typically, CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells. See below for reference. Figure 1B This section discusses an example configuration for connecting the EPC 110 to an additional base station.

[0050] Base station 104A is equipped with processing hardware 130, which may include one or more general-purpose processors, such as CPUs, and non-transitory computer-readable memory that stores machine-readable instructions executable on one or more general-purpose processors and / or special-purpose processing units (e.g., application-specific integrated circuits (ASICs) or digital signal processors (DSPs)). Figure 1A The processing hardware 130 in the example implementation includes an MN RRC controller 132, which is configured to manage or control RRC configuration and RRC procedures. For example, the MN RRC controller 132 may be configured to support RRC message passing associated with RRC connection establishment procedures, RRC connection recovery procedures, RRC connection reconstruction procedures, RRC reconfiguration procedures, procedures for MR-DC, CA, or other suitable functions, and / or support necessary operations when the base station 104A operates as an MN (described below). The processing hardware 130 may include an SCG controller 134, which is configured to manage or control the deactivation and / or activation of the SCG between the UE 102 and the SN.

[0051] Base station 106A is equipped with processing hardware 140, which may also include one or more general-purpose processors, such as a CPU, and non-transitory computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors and / or dedicated processing units (e.g., ASICs or DSPs). The processing hardware 140 in the example implementation includes an SN RRC controller 142 configured to manage or control RRC configuration and RRC procedures. The processing hardware 140 may include an SCG controller 144 configured to manage, control, or execute the deactivation and / or activation of the SCG between UE 102 and the SN. Typically, because the base station can operate as an MN or SN in different scenarios, RRC controllers 132 and 142 can implement similar sets of functions, and each supports both MN and SN operations.

[0052] Still referencing Figure 1A UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors, such as CPUs, and non-transitory computer-readable memory that stores machine-readable instructions executable on one or more general-purpose processors and / or dedicated processing units. Figure 1AThe processing hardware 150 in the example implementation includes a UE RRC controller 152, which is configured to manage or control RRC configuration and / or RRC procedures. For example, according to any implementation described below, the UE RRC controller 152 may be configured to support RRC message passing associated with RRC connection establishment procedures, RRC connection restoration procedures, RRC connection reconstruction procedures, and / or procedures for MR-DC, CA, or other suitable functions. The processing hardware 150 may include an SCG controller 154, which is configured to manage, control, or perform deactivation and / or activation of the SCG between the UE 102 and the SN.

[0053] More specifically, RRC controllers 132, 142, and 152 may implement at least some of the techniques discussed below (refer to various messages and flowcharts) to manage RRC configuration. SCG controllers 134, 144, and 154 may implement at least some of the techniques discussed below (refer to various messages and flowcharts) to manage SCG deactivation and / or activation.

[0054] In operation, UE 102 can use radio bearers (e.g., DRB or SRB) that terminate at different times at MN 104A or SN 106A. UE 102 can receive radio bearer configurations from MN 104A or SN 106A. When communicating on radio bearers in the uplink (from UE 102 to the base station) and / or downlink (from the base station to UE 102) directions, UE 102 can apply one or more security keys. In some cases, UE 102 can use different RATs to communicate with base stations 104A and 106A. Although the examples below may involve specific RAT types, 5G NR, or EUTRA, in general, the techniques disclosed herein can also be applied to other suitable radio access and / or core network technologies.

[0055] Figure 1B An example wireless communication system 100 is depicted in which communication devices can implement these technologies. The wireless communication system 100 includes a UE 102, base stations 104A, 104B, 106A, 106B, and a core network (CN) 110. The UE 102 is initially connected to base station 104A. Base stations 104B and 106B may have similar processing hardware to base station 106A. The UE 102 is initially connected to either base station 104A or 106A.

[0056] like Figure 1BAs shown, base station 104A supports cell 124A, base station 104B supports cell 124B, base station 106A supports cell 126A, and base station 106B supports cell 126B. Cells 124A and 126A can partially overlap, as can cells 124A and 126B, allowing UE 102 to communicate with base station 104A (operating as MN) and base station 106A (operating as SN) in the DC, and to communicate with base station 104A (operating as MN) and base station 106B (operating as SN) after completing the SN change. More specifically, when UE 102 is in the DC with base station 104A and base station 106A or 106B, base station 104A operates as MeNB, Mng-eNB, or MgNB, while base station 106A or 106B operates as SgNB or Sng-eNB. Cells 124A and 124B can partially overlap, allowing UE 102 to communicate with base station 104A, and to communicate with base station 104A during handover.

[0057] Typically, the wireless communication network 100 may include any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 may connect to any suitable number of base stations supporting NR cells and / or EUTRA cells. Although the examples below specifically relate to particular CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general, the techniques disclosed herein can also be applied to other suitable radio access and / or core network technologies, such as sixth-generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

[0058] Figure 1C Exemplary distributed or decentralized implementations of any one or more base stations 104A, 104B, 106A, 106B are depicted. In this implementation, base station 104A, 104B, 106A, or 106B includes a centralized unit (CU) 172 and one or more DUs 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s) and / or dedicated processing units. For example, CU 172 may include... Figure 1A The processing hardware is 130 or 140.

[0059] Each DU 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors and / or dedicated processing units. For example, the processing hardware may include a Media Access Control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures), and a Radio Link Control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 106A) operates as an MN or SN. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0060] In some implementations, CU 172 may include a logical node CU-CP 172A, which hosts the control plane portion of the Packet Data Convergence Protocol (PDCP) protocol of CU 172. CU 172 may also include (multiple) logical nodes CU-UP 172B, which host the user plane portion of the PDCP protocol and / or Service Data Adaptation Protocol (SDAP) protocol of CU 172. CU-CP 172A may send control information (e.g., RRC messages, F1 application protocol messages), and CU-UP 172B may send data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0061] A CU-CP 172A can be connected to multiple CU-UP 172Bs via the E1 interface. The CU-CP 172A selects the appropriate CU-UP 172B for the service requested by UE 102. In some implementations, a single CU-UP 172B can be connected to multiple CU-CP 172As via the E1 interface. A CU-CP 172A can be connected to one or more DU 174s via the F1-C interface. A CU-UP 172B can be connected to one or more DU 174s via the F1-U interface under the control of the same CU-CP 172A. In some implementations, a DU 174 can be connected to multiple CU-UP 172Bs under the control of the same CU-CP 172A. In such implementations, the connection between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using bearer context management functions.

[0062] Figure 2 An example protocol stack 200 is shown in a simplified manner, according to which the UE 102 can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104A, 104B, 106A, 106B).

[0063] In example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208, and in some cases, a channel to the NR PDCP sublayer 210. Similarly, the NRPHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data delivery services to the Serving Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2 (Not shown in the image) provides data transmission services. In some implementations, UE 102 supports, for example... Figure 2 The EUTRA and NR stacks shown are designed to support handover between EUTRA and NR base stations and / or support DCs via the EUTRA and NR interfaces. Additionally, as... Figure 2 As shown, UE 102 can support NR PDCP 210 through EUTRA RLC 206A layering, as well as SDAP sublayer 212 through NR PDCP sublayer 210.

[0064] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 receive packets that can be referred to as Service Data Units (SDUs) (e.g., from the Internet Protocol (IP) layer, directly or indirectly layered through PDCP layers 208 or 210), and output packets that can be referred to as Protocol Data Units (PDUs) (e.g., to RLC layers 206A or 206B). Except where the difference between SDU and PDU is relevant, for simplicity, this disclosure refers to both SDU and PDU as “packets”.

[0065] For example, on the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide SRBs to exchange RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0066] When UE 102 operates in EN-DC, base station 104A operates as MeNB, and base station 106A operates as SgNB, wireless communication system 100 can provide UE 102 with an MN termination bearer using EUTRA PDCP sublayer 208, or an MN termination bearer using NR PDCP sublayer 210. Wireless communication system 100 can also provide UE 102 with an SN termination bearer in various scenarios, using only NR PDCP sublayer 210. The MN termination bearer can be an MCG bearer, a split bearer, or an MN termination SCG bearer. The SN termination bearer can be an SCG bearer, a split bearer, or an SN termination MCG bearer. The MN termination bearer can be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN termination bearer can be an SRB or a DRB.

[0067] Next, refer to Figures 3A-5B Discussion in Figure 1A Several example scenarios are provided for base stations operating in the system to activate or deactivate the SCG between the SN of UE 102 and RAN 105. Generally speaking, Figures 3A-5B Similar events are labeled with similar reference figures (e.g., event 380A is similar to events 380B-C, 480A-B, and 580A-B; event 322A is similar to events 322B-C, 422A-B, and 522A-B), and the differences will be discussed in the appropriate places below. Apart from the differences shown in the figures and discussed below, any alternative implementations discussed with respect to specific events (e.g., those used for message passing and processing) can be applied to events labeled with similar reference figures in other figures.

[0068] First refer to Figure 3A In scenario 300A, base station 104A operates as the MN and base station 106A operates as the SN. Initially, UE 102 transmits 302A uplink (UL) PDUs and / or downlink (DL) PDUs with MN 104A. MN 104A can transmit PDUs from UE 102, base station 104B, or CN 110 (base station 104B and CN 110 are not in...). Figure 3A(As shown in the diagram) UE 102 obtains a first UE capability and a second UE capability. In some implementations, the first UE capability may be a first Radio Access Technology (RAT) Capability Information Element (IE) (e.g., UE-EUTRA-Capability IE), which includes a first plurality of UE capabilities for communicating with MN 104A via the first RAT, and the second UE capability may be a second RAT Capability IE (e.g., UE-NR-Capability or UE-MRDC-Capability IE), which includes a second plurality of capabilities for communicating with SN 106A via the second RAT. For example, MN 104A may be a base station supporting 4G LTE RAT (e.g., eNB or ng-eNB), and SN 106A may be a base station supporting 5G NR RAT (e.g., gNB). Therefore, MN 104A can interpret the first UE capability formatted according to the 4G LTE RAT, and SN 106A can interpret the second UE capability formatted according to the 5G NR RAT. (See reference...) Figure 8 As discussed in further detail, in some implementations, UE 102 may provide a single UE capability to the RAN, rather than a first UE capability and a second UE capability. For example, in these implementations, both MN 104A and SN 106A can interpret the same UE capability field or IE because both MN 104A and SN 106A support the same RAT (e.g., both MN 104A and SN 106A are gNBs).

[0069] Later, MN 104A can send an SN Addition Request message (304A) to base station 106A, including the capability of a second UE, to configure base station 106A as an SN for UE 102 (i.e., enable dual connectivity for UE 102 with MN 104A and SN 106A). For example, MN 104A can determine to configure base station 106A as an SN based on multiple measurements received from UE 102. In another example, at event 302A, UE 102 may be in a DC with MN 104A and SN 106B. In this case, MN 104A can determine to configure base station 106A as an SN in response to an indication from SN 106B requiring an SN change (e.g., an SN Change Required message), and SN 106B can send this indication to MN 104A. In response to the SN AdditionRequest message, SN 106A sends an SN Addition Request Acknowledge message (306A) to MN 104A, including the SN configuration. Upon receiving the SN Addition Request Acknowledge message, MN 104A sends an RRC reconfiguration message (308A) to UE 102, including the SN configuration, and in response, UE 102 sends an RRC reconfiguration complete message (310A) to MN 104A. UE 102 then operates in DC 312A with MN 104A and SN 106A. After receiving the RRC reconfiguration complete message (310A), MN 104A may send an SN ReconfigurationComplete message to SN 106A to indicate that UE 102 has received the SN configuration. In some implementations, in response to the SN configuration, the UE may include the SN RRC reconfiguration complete message in the RRC reconfiguration message (310A). Subsequently, MN 104A can include the SN RRC reconfiguration complete message in the SNReconfiguration Complete message.

[0070] Events 302A, 304A, 306A, 308A, and 310A are in Figure 3A This is collectively referred to as DC configuration process 380A. Events 308A and 310A are in... Figure 3A This is collectively referred to as the RRC reconfiguration process 309A.

[0071] In some implementations, at event 312A, UE 102 communicates with SN 106A using SN configuration. To communicate with SN 106A, in response to receiving the SN configuration, UE 102 performs a random access procedure with SN 106A. More specifically, UE 102 performs a random access procedure with SN 106A on a cell (e.g., cell 126A) according to the random access configuration in the SN configuration. After completing the random access procedure, UE 102 in the DC can communicate with the 312A UL PDU and / or DL ​​PDU via radio bearers that may include SRBs and / or DRBs. MN 104A and / or SN 106A may be configured to the radio bearers of UE 102, for example, at event 302A or at events 306A and / or 308A. UE 102, located in the DC, communicates with SN 106A via 312A UL PDU and / or DL ​​PDU on the SCG. SN 106A configures the SCG for communication with UE 102. UE 102, also located in the DC, communicates with MN 104A on the MCG using the MN configuration and with SN 106A on the SCG using the SN configuration. In the MN configuration, MN 104A is configured to include the MCG of at least one serving cell operated by MN 104A. In the SN configuration, SN 106A is configured to include the SCG of at least one serving cell operated by SN 106A.

[0072] For example, the random access procedure can be a four-step random access procedure or a two-step random access procedure. In different implementations and / or scenarios, the random access procedure can be a contention-based random access procedure or a contention-free random access procedure. In some implementations and / or scenarios, UE 102 may include a UE identifier known to SN 106A in "Message 3" of a four-step random access procedure or in Message A of a two-step random access procedure, allowing SN 106A to identify UE 102 using the UE identifier. In some implementations, the UE identifier is a Radio Network Temporary Identifier (RNTI) (e.g., C-RNTI) assigned by SN 106A in the SN configuration. In other implementations, SN 106A identifies UE 102 based on a dedicated random access preamble received by SN 106A from UE 102 during the random access procedure. SN 106A may assign the dedicated random access preamble in the SN configuration.

[0073] In some implementations, the MN configuration includes multiple configuration parameters, and UE 102 receives one or more configuration parameters from MN 104A in one or more RRC messages. In other implementations, the SN configuration includes multiple configuration parameters, and UE 102 receives one or more configuration parameters from SN 106A, for example via MN 104A or on an SRB (e.g., SRB3) configured to exchange RRC messages between UE 102 and SN 106A, either via MN 104A or SN 106A.

[0074] Subsequently, MN 104A detects that the conditions for deactivating the SCG have been met. In some implementations, such as scenario 300A, the detection conditions include determining for UE 102 that 314A has data inactivity on the SCG. In one implementation, MN 104A determines that UE 102 has data inactivity based on messages received from SN 106A regarding UE 102. For example, SN 106A can detect data inactivity for UE 102 and, in response, send an Activity Notification message with an indication of inactivity for UE 102 to MN 104A. MN 104A can then determine that UE 102 has data inactivity based on the received Activity Notification message. In another implementation, MN 104A can detect data inactivity for UE 102 if it does not receive any data packets to be sent to UE 102 via SN 106A within a predetermined time period.

[0075] In other implementations, MN 104A detects this condition or determines that there is data inactivity on the SCG based on UE preferences received by MN104A from UE 102. For example, UE 102 may send UE assistance information (e.g., a UEAssistanceInformation message) to MN 104A, indicating that the UE (temporarily) prefers single connectivity, for example, due to power saving or overheating. Detection conditions may include receiving UE assistance information. Additionally or optionally, in response to the UE assistance information, MN 104A may determine that there is data inactivity on the SCG for UE 102.

[0076] Upon detecting a condition or in response to detecting a condition (e.g., in response to determining that UE 102 of 314A has data inactivity on the SCG), MN 104A determines whether UE 102 of 316A supports SCG deactivation based on a first UE capability. As described above, the first UE capability is formatted according to the RAT supported by MN 104A (e.g., UE-EUTRA-Capability IE if MN 104A is an eNB or ng-eNB supporting the 4G LTE RAT). In some implementations, the first UE capability includes a capability field or IE to indicate that UE 102 supports SCG deactivation. If the first UE capability includes a capability field, MN 104A determines that UE 102 supports SCG deactivation. If the first UE capability does not include a capability field, MN 104A determines that UE 102 does not support SCG deactivation.

[0077] If the first UE capability indicates that UE 102 supports SCG deactivation, then MN 104A sends a 318A SNModification Request message to SN 106A, causing SN 106A to deactivate the SCG of UE 102. In response to the SN Modification Request message, SN 106A sends a 320A SN Modification Request Confirmation message to MN 104A. In some implementations, MN 104A includes indications (e.g., fields or information elements (IEs)) in the SN Modification Request message to cause SN 106A to deactivate the SCG.

[0078] In response to the determination that UE 102 supports SCG deactivation (316A), after MN 104A sends a 318A SN ModificationRequest message, or after MN 104A receives a 322A SN Modification Request acknowledgment message, MN 104A sends a 322A RRC reconfiguration message to cause UE 102 to deactivate the SCG. In response to the RRC reconfiguration message, UE 102 deactivates the SCG (324A) used for communication with SN 106A and sends a 326A RRC reconfiguration complete message to MN 104A. After deactivating the SCG, UE 102 maintains its radio connection with MN 104A. Upon receiving the RRC reconfiguration complete message, MN 104A may send a 328A SN message (e.g., an SN Reconfiguration Complete message) to SN 106A to indicate that UE 102 has deactivated the SCG. In some implementations, MN 104A may generate an indication (e.g., a field or information element (IE)) to deactivate the SCG and include this indication in the RRC reconfiguration message 322A sent by MN 104A. In some implementations, UE 102 does not include the SN RRC message in the RRC reconfiguration message 326A, and MN 104A does not include the SN RRC message in the SN message 328A. In other implementations, SN 106A may include an SCG deactivation command message to deactivate the SCG in the SN Modification Request Acknowledge message, and MN 104A further includes the SCG deactivation command message in the RRC reconfiguration message 322A. In this case, SN 106A includes the field or IE for deactivating the SCG in the SCG deactivation command message, and MN 104A does not generate the field or IE for deactivating the SCG. In response to the SCG deactivation command message, UE 102 includes the SCG deactivation completion message in the RRC reconfiguration completion message 326A. In some implementations, the SCG deactivation command message and the SCG deactivation completion message can be the SN RRC reconfiguration message and the SN RRC reconfiguration completion message, respectively.

[0079] In response to receiving the 318A SN Modification Request message, after sending the 320A SNModification Request Acknowledge message, or after receiving the 328A SN message, SN 106A may deactivate the 330A SCG for communication with UE 102. For example, SN 106A may activate the 330A SCG after receiving the SN message or after a predetermined time following the receipt of the 318A SN Modification Request message, thus preventing SN 106A from deactivating the SCG at SN 106A until UE 102 activates the SCG at UE 102 (324A).

[0080] If MN 104A determines that UE 102 does not support SCG deactivation (316A), then MN 104A can determine that UE 102 should release the SCG. In response to this determination, MN 104A sends a 332A SN Release Request message to SN 106A. In response, SN 106A sends a 334A SN Release Request Acknowledge message to MN 104A. In response to the determination to release the SCG, either after sending the SN Release Request message or after receiving the SN Release Request Acknowledge message, MN 104A sends a 336A RRC reconfiguration message to UE 102 to cause UE 102 to release the SCG. MN 104A may include an SCG release field or IE in the RRC reconfiguration message 336A sent by MN to indicate that UE 102 should release the SCG. In response to an RRC reconfiguration message or the SCG release field / IE, UE 102 releases the 338A SCG and sends a 340A RRC reconfiguration complete message to MN 104A. Upon receiving the RRC reconfiguration complete message, MN 104A can send a 342A UE Context Release message to SN 106A. In response to the UE Context Release message, SN 106A releases the 344SCG (i.e., releases the UE context of UE 102).

[0081] In some implementations, the MN 104A may include an indication to deactivate the SCG in the SN Modification Request message 318A sent by the MN 104A. In other implementations, the MN 104A may include an indication to suspend the lower layer in the SN Modification Request message 318A sent by the MN 104A to deactivate the SCG. In this case, the MN 104A may or may not include an indication to deactivate the SCG in the SN Modification Request message 318A sent by the MN 104A.

[0082] In some implementations, the MN configuration includes configuration parameters in an RRCReconfiguration message, RRCReconfiguration-IEs, or CellGroupConfig information element (IE) conforming to 3GPP TS 38.331. In one implementation, the MN configuration can be an RRCReconfiguration message, RRCReconfiguration-IEs, or CellGroupConfig IE conforming to 3GPP TS 38.331. In other implementations, the MN configuration can include configuration parameters in a RadioResourceConfigDedicatedIE, an RRCConnectionReconfiguration message, or RRCConnectionReconfiguration-IEs. In one implementation, the MN configuration can be a RadioResourceConfigDedicated IE, an RRCConnectionReconfiguration message, or RRCConnectionReconfiguration-IEs conforming to 3GPP TS 36.331.

[0083] The SN configuration may include multiple configuration parameters that configure radio resources for UE 102 to communicate with SN 106A via SN 106A's PSCell (e.g., cell 126A or a cell other than cell 126A) and zero or more SCells. For example, the SN configuration may include multiple PHY configurations, multiple MAC configurations, and / or multiple RLC configurations. The SN configuration may or may not include multiple measurement configurations.

[0084] In some implementations, the SN configuration includes configuration parameters in an RRCReconfiguration message, RRCReconfiguration-IEs, or CellGroupConfig IE conforming to 3GPP TS 38.331. In one implementation, the SN configuration may be an RRCReconfiguration message, RRCReconfiguration-IEs, or CellGroupConfig IE conforming to 3GPP TS 38.331. In other implementations, the SN configuration may include configuration parameters in an SCG-ConfigPartSCG-r12 IE. In some implementations, the SN configuration may be an RRCConnectionReconfiguration message, RRCConnectionReconfiguration-IEs, or ConfigPartSCG-r12 IE conforming to 3GPP TS 36.331.

[0085] If MN 104A is a gNB, the RRC reconfiguration message and the RRC reconfiguration completion message are respectively the RRCReconfiguration message and the RRCReconfigurationComplete message. If MN 104A is an eNB or ng-eNB, the RRC reconfiguration message and the RRC reconfiguration completion message are respectively the RRCConnectionReconfiguration message and the RRCConnectionReconfigurationComplete message. If SN 106A is a gNB, the SN RRC reconfiguration message and the SN RRC reconfiguration completion message are respectively the RRCReconfiguration message and the RRCReconfigurationComplete message. If SN 106A is an eNB or ng-eNB, the SN RRC reconfiguration message and the SN RRC reconfiguration completion message are respectively the RRCConnectionReconfiguration message and the RRCConnectionReconfigurationComplete message.

[0086] In some implementations, similar to event 316A, before sending the SN Addition Request message 304A to SN 106A, MN 104A can determine whether UE 102 supports SCG deactivation based on a first UE capability. If the first UE capability indicates that UE 102 supports SCG deactivation, MN 104A can include an instruction instructing SN 106A to deactivate the SCG in the SN Addition Request message 304A. Therefore, SN 106A deactivates the SCG in response to the deactivation instruction. In this case, MN 104A instructs UE 102 to deactivate the SCG in the RRC reconfiguration message 308A. Alternatively, SN 106A instructs UE 102 to deactivate the SCG in the SN configuration. In response to the SCG deactivation instruction, UE 102 does not activate the SCG, and in response to the RRC reconfiguration message 306A, no random access procedure is performed. In other words, even if UE 102 receives the SN configuration for adding PSCell, UE 102 will keep SCG in a deactivated state.

[0087] Go to Figure 3B Scenario 300B is generally similar to Scenario 300A, except that SN 106A, instead of MN 104A, determines the deactivation of the SCG. Initially, MN 104A, SN 106A, and UE 102 communicate with each other during DC configuration procedure 380B. During DC configuration procedure 380B, SN 106A receives a second UE capability from MN 104A. The second UE capability is formatted according to the RAT supported by SN 106A (e.g., if SN 106A is a gNB supporting 5G NR RAT, the second UE capability could be UE-NR-Capability IE or UE-MRDC-Capability IE). Later, SN 106A detects that the conditions for deactivating the SCG are met. Similar to event 314A in Scenario 300A, detecting the conditions in Scenario 300B includes determining 313B that there is data inactivity for the SCG on the SCG. Upon detecting or in response to the detection of this condition, SN 106A determines whether UE 102 supports SCG deactivation. In contrast to event 316A, SN 106A determines whether UE 102 supports SCG deactivation based on a second UE capability. In some implementations, the second UE capability includes a capability field or IE to indicate that UE 102 supports SCG deactivation. If the second UE capability includes a capability field, SN 106A determines that UE 102 supports SCG deactivation. If the second UE capability does not include a capability field, SN 106A determines that UE 102 does not support SCG deactivation.

[0088] If the second UE capability indicates that UE 102 supports SCG deactivation, SN 106A sends a 321B SNModification Required message to MN 104A. In the SN Modification Required message, SN 106A may notify MN 104A that the SCG is to be deactivated. In response, MN 104A sends a 322B RRC reconfiguration message to UE 102. In some implementations, SN 106A generates an indication instructing UE 102 to deactivate the SCG and includes this indication in the SN Modification Required message. MN 104A can then include this indication generated by SN 106A in the RRC reconfiguration message 322B sent by MN 104A. For example, SN 106A may generate an SN RRC message (e.g., an SN RRC reconfiguration message) that includes this indication and include the SN RRC message in the SN Modification Required message. In this example, at event 322B, MN 104A includes the SN RRC message in the RRC reconfiguration message. In other implementations, MN 104A may generate an instruction instructing UE 102 to deactivate the SCG and include that instruction in the RRC reconfiguration message 322B sent by MN 104A.

[0089] In response to receiving the 322B RRC reconfiguration message, UE 102 deactivates the SCG 324B used for communication with SN 106A and sends the 326B RRC reconfiguration complete message to MN 104A. After receiving either the 327B SN ModificationRequired message or the 326B RRC reconfiguration complete message, MN 104A sends the 327B SNModification Confirm message to SN 106A. In response to determining that UE 102 supports SCG deactivation (315B), SN 106A may deactivate the SCG 330B used for communication with UE 102 after sending the 321B SNModification Require message or after receiving the 327B SN Modification Confirm message. For example, SN 106A can activate 330B SCG after receiving 327B SNModification Confirm message or after a predetermined time after sending 321B SN Modification Required message, so that SN 106A does not activate 330B SCG at SN 106A until UE102 activates 324B SCG at UE 102.

[0090] Events 321B, 322B, 324B, 326B, and 327B are in Figure 3B This is collectively referred to as the SCG deactivation process 382B.

[0091] If SN 106A determines that UE 102 does not support SCG deactivation (315B), then SN 106A can determine that UE 102 releases the SCG. In response to this determination, SN 106A sends a 331B SN Release Required message to MN 104A. In response, MN 104A can send a 333B SN Release Confirm message to SN 106A. Similar to event 336A, MN 104A also sends a 336B RRC reconfiguration message to UE 102, which includes an indication that UE 102 releases the SCG. In response to the RRC reconfiguration message or the SCG release field or IE in the RRC reconfiguration message, UE 102 releases the 338B SCG and sends a 340B RRC reconfiguration complete message to MN 104A. After receiving the 340B RRC reconfiguration complete message, MN 104A can send a 342B UE Context Release message to SN 106A. In response to the UE Context Release message, SN106A releases 344B SCG.

[0092] Events 331B, 333B, 336B, 338B, 340B, and 342B are in Figure 3B This is collectively referred to as the SCG release process 386B.

[0093] Next reference Figure 3CScenario 300C is generally similar to Scenario 300B, except that SN 106A communicates directly with UE 102 to deactivate the SCG. After determining that UE 102 supports SCG deactivation (315C), SN 106A directly sends a 323C RRC reconfiguration message to UE 102 (e.g., via SRB3), which includes an instruction to UE 102 to deactivate the SCG. In response, UE 102 deactivates the 324C SCG and sends a 325C RRC reconfiguration complete message to SN 106A. After determining that UE 102 supports deactivation (315C), either after sending the 323C RRC reconfiguration message or after receiving the 325C RRC reconfiguration complete message from UE 102, SN 106A deactivates the 330C SCG. For example, SN 106A can activate 330C SCG at a predetermined time after sending the 323CSN Modification Required message or after receiving the 325C RRC Reconfiguration Complete message, so that SN 106A does not activate the SCG at 330C SN 106A until UE 102 activates the SCG at 324C UE 102.

[0094] In some implementations, after determining that UE 102 supports SCG deactivation, SN 106A sends a 321CSN Modification Required message to MN 104A, notifying MN 104A that the SCG is to be deactivated. In response, MN 104A sends a 327C SN Modification Confirm message to SN 106A. In some alternative implementations, at event 321C, SN 106A may send another SN message to SN, notifying MN 104A that the SCG is to be deactivated, instead of the SN Modification Required message. Events 321C, 327C, 323C, 324C, and 325C are collectively referred to in this disclosure as SCG deactivation procedure 384C.

[0095] Optionally, if SN 106A determines that UE 120 does not support SCG deactivation, SN 106A can initiate SCG release procedure 386C and release SCG 344C at SN.

[0096] Go to Figure 3DScenario 300D is generally similar to Scenario 300A, except that a portion of Scenario 300D can occur when the radio connection between UE 102 and RAN 105 is suspended (e.g., when UE 102 is in an inactive or idle state of a protocol that controls radio resources between UE 102 and RAN 105, such as the RRC_INACTIVE or RRC_IDLE state of the RRC protocol). After DC configuration procedure 380D, MN 104A determines 374D to configure the UE into an inactive state (e.g., RRC_INACTIVE or RRC_IDLE). MN 104A then sends an RRC suspension message 376D to UE 102 to cause UE 102 to transition to an inactive state. When UE 102 transitions to an inactive state 377D, UE 102 can suspend the MCG and SCG, i.e., deactivate the MCG and SCG. In some implementations, MN 104A also sends a 375D SN Request message to SN 106A to notify SN 106A that UE 102 is transitioning to an inactive state. In response to the RRC hangup message, UE 102 transitions to the inactive state using 377D.

[0097] Subsequently, UE 102 determines to restore the suspended radio connection with RAN 105 and sends a 352D RRC recovery request to MN 104A. Depending on the implementation, in response to receiving the 352D RRC recovery request, MN 104A can determine that the conditions for deactivating the SCG are met. For example, in some implementations, UE 102 reactivates both the MCG and SCG after sending the 352D RRC recovery request, and / or RAN 105 reactivates both the MCG and SCG after receiving the 352D RRC recovery request. However, in other implementations, after receiving or sending the RRC recovery request, UE 102 and / or RAN 105 only reactivate (i.e., restore) the MCG. In implementations where the SCG is reactivated, MN 104A can determine whether to deactivate or release the SCG.

[0098] In response to receiving a 352D RRC recovery request, MN 104A can determine that the conditions for deactivating the SCG have been met. For example, in an implementation where UE 102 reactivates the SCG after sending the 352D RRC recovery request message, MN 104A can determine to deactivate the SCG, or release the SCG if UE 102 does not support SCG deactivation. In an implementation where UE 102 does not reactivate the SCG, MN 104A can still determine to notify UE 102 to keep the SCG in a deactivated state.

[0099] Therefore, upon receiving the 352D RRC recovery request message, MN 104A determines whether UE 102 supports SCG deactivation based on the first UE capability. If so, MN 104A sends a 354D RRC recovery message to UE 102, which includes an indication that UE 102 wants to deactivate the SCG or allows the SCG to remain deactivated. In response, UE 102 enters the connected state, and if the SCG is activated at UE 102, it deactivates the SCG using the 324D method and sends a 356D RRC recovery complete message to MN 104A. Furthermore, after receiving the 352D RRC recovery request, if the SCG has been reactivated, MN 104A sends a 318D SN Modification Request message to SN 106A, including an indication to deactivate the SCG. SN 106A then sends a 320DSN Modification Request Acknowledge message to MN 104A. Furthermore, after receiving the 356D RRC recovery complete message, MN 104A can send a 328D SN message (e.g., SN Reconfiguration Complete message) to SN 106A to indicate that UE 102 has deactivated the SCG. After receiving the 318D SN Modification Request message, after sending the 320D SN Modification Request Acknowledge message, or after receiving the 328D SN message, SN 106A can deactivate the 330SCG.

[0100] If MN 104A determines that UE 102 does not support SCG deactivation (316D), then MN 104A causes SN 106A and UE 102 to release the SCG. MN 104A sends a 332D SN Release Request message to SN 106A, and in response, SN 106A can send a 334D SN Release Request Acknowledge message to MN 104A. Additionally, MN 104A sends a 337D RRC recovery message including an indication to release the SCG. In response, UE 102 releases the SCG (338D) and sends a 339D RRC recovery complete message to MN 104A. MN 104A can then send a 342d UE Context Release message to SN 106A to cause SN 106A to release the SCG (344D).

[0101] In some alternative implementations, after receiving the 352D RRC recovery request message, MN 104A determines that the MCG and SCG should remain deactivated. For example, MN 104A makes this determination in response to a recovery trigger value in the RRC recovery request message. For example, a recovery trigger value (e.g., rna-Update) could instruct UE 102 to send an RRC recovery request to update the RAN notification area (RNA). In response to this determination and the RRC recovery request message, at event 354D, MN 104A can send a second RRC suspension message to UE 102 instead of an RRC recovery message. In response to the second RRC suspension message, UE 102 allows the MCG and SCG to remain deactivated.

[0102] In other alternative implementations, after receiving a 352D RRC recovery request message, MN 104A determines to reactivate the MCG and SCG. For example, MN 104A makes this determination in response to a recovery trigger value in the RRC recovery request message. For instance, a recovery trigger value (e.g., mo-Data) could instruct UE 102 to send an RRC recovery request for data communication. In another example, the recovery trigger value could instruct UE 102 to request the reactivation of the MCG and SCG, i.e., to restore the MCG and SCG. In response to this determination, MN 104A can send a 318D SN Modification Request message to SN 106A to reactivate or restore the SCG, rather than deactivate it. In response, SN 106A sends an SN ModificationRequest Acknowledge message to MN 104A, including the SN configuration. Upon receiving the SN configuration, at event 354D, MN 104A includes the SN configuration in the RRC recovery message, and MN 104A can send the 354D RRC recovery message to UE 102. Neither MN 104A nor SN 106A includes an indication to deactivate the SCG in the RRC recovery message. In response to the RRC recovery message, UE 102 enters the connected state, activates or restores the MCG and SCG, and communicates with MN 104A and SN 106A located in the DC.

[0103] If MN 104A is a gNB, then the (second) RRC hangup message, RRC recovery request message, RRC recovery message, and RRC recovery completion message are respectively RRCRelease message, RRCResumeRequest message, RRCResume message, and RRCResumeComplete message. If MN 104A is an eNB or ng-eNB, then the RRC recovery request message, RRC recovery message, and RRC recovery completion message are respectively RRCConnectionRelease message, RRCConnectionResumeRequest message, RRCConnectionResume message, and RRCConnectionResumeComplete message.

[0104] Figures 4A-4B Typically similar to Figure 3B However, SN 106A includes CU and DU. Therefore, Figures 4A-4B The events in the scene depicted and similar to those in the story Figure 3B The events discussed are labeled using similar figure-eight notation.

[0105] First go to Figure 4AIn scenario 400A, base station 104A operates as the MN, and base station 106A operates as the SN, including CU172 and DU174. Initially, UE 102 communicates with MN 104A using the MN configuration 402A. MN 104A can obtain UE 102's first and second UE capabilities from UE 102, another base station (e.g., base station 104B), or CN 110. To configure base station 106A as UE 102's SN, MN 104A sends an SNAddition Request message 404A including the second UE capability to CU 172 of SN 106A. CU 172 can then send a UE ContextSetup Request message 446A including the second UE capability to DU 174. In response to the UE Context Setup Request message, DU 174 sends a UE Context Setup Response message 448A including the DU configuration. The DU configuration includes configuration parameters that UE 102 can use to communicate with DU 174. CU 172 can send the DU configuration (406A) to MN 104A in an SN Addition Request Acknowledge message. Similar to RRC reconfiguration procedure 309A, MN 104A can send the DU configuration to UE 102 in RRC reconfiguration procedure 409A. UE 102 can then communicate (412A) in the DC with MN 104A and SN 106A. To communicate with SN 106A, UE 102 uses the DU configuration to communicate with DU 174 and can communicate with CU 172 via DU 174.

[0106] Events 402A, 404A, 446A, 448A, 406A, 409A, and 412A are in Figure 4A This is collectively referred to as DC Configuration Process 480A.

[0107] At a later time, CU 172 detects that the conditions for deactivating the SCG have been met. In scenario 400A, the detection conditions include determining 413A that there is data inactivity on the SCG for UE 102, similar to determination 314A. In response to the detection of the condition, CU 172 determines whether UE 102 supports SCG deactivation based on a second UE capability. If so, CU 172 executes the 483ASCG deactivation procedure to cause UE 102 to deactivate the SCG. The SCG deactivation procedure 483A can be similar to the SCG deactivation procedure 382B or SCG deactivation procedure 384C. CU 172 also sends a 462A CU-DU message to DU 174 to cause DU 174 to deactivate the SCG. In response to receiving the 472CU-DU message, DU 174 deactivates the SCG 430A. In some implementations, DU 174 also sends a 464A DU-CU message to CU 172 in response to the CU-DU message.

[0108] Events 462A, 464A and 430A are collectively referred to in this disclosure as CU-initiated SCG deactivation process 490A.

[0109] If CU 172 determines that UE 102 does not support SCG deactivation, then CU 172 determines to release the SCG. CU 172 sends a 431A SN Release Required message to MN104A. In response, MN 104A sends a 433A SNRelease Confirm message to CU 172 and an RRC reconfiguration message to UE 102 including an indication to release the SCG. Furthermore, after determining 415A, CU 172 also sends a 466A UE Context Modification Request message to DU 174 to instruct DU 174 to stop sending to UE 102. DU 174 can confirm the UE context modification request by sending a 468A UE ContextModification Response message to CU 172.

[0110] After receiving the 436A RRC reconfiguration message, UE 102 releases the 438A SCG and sends a 440ARRC reconfiguration complete message to MN 104A. MN 104A then sends a 442A UE Context Release message to CU 172. In response, CU 172 sends a 470A UE Context Release Command message to DU 174, causing DU 174 to release the SCG. DU 174 then releases the 444A SCG and sends a 472A UE Context Release Complete message to CU 172. Events 470A, 472A, and 444A occur in... Figure 4A This is collectively referred to as the CU-initiated SCG release process 492A.

[0111] In some implementations, CU 172 can generate an SN configuration that includes the DU configuration and send an SN Addition Request Acknowledge message containing the SN configuration to 406A. In some implementations, the DU configuration can be a CellGroupConfig IE or a ConfigPartSCG-r12 IE.

[0112] Go to Figure 4BScenario 400B is similar to Scenario 400A, but the determination of whether to deactivate or release the SCG is made by DU 174 instead of CU 172. After DC configuration procedure 480B, DU 174 detects that the conditions for deactivating the SCG have been met. In Scenario 400B, DU 174 determines for UE 102 411B that there is data inactivity on the SCG. In response, DU 174 determines whether UE 102 supports SCG deactivation based on a second UE capability. If so, DU 174 sends a DU-to-CU message 461B to CU 172. In some implementations, the DU-to-CU message is a request to deactivate the SCG. CU 172 can determine whether to approve or reject the request. In such an implementation, if CU 172 approves the request, then CU 172 (i) initiates an SCG deactivation procedure 483B to cause UE 102 to deactivate the SCG, similar to procedure 483A, and (ii) sends a 462B CU-to-DU message to DU 174, which includes a command instructing DU 174 to deactivate the SCG. In response, DU 174 sends a DU-to-CU message 464B to CU 172 confirming the CU-to-DU message and deactivates the SCG 430B. In other implementations, the DU-to-CU message 461B sent by DU 174 includes an instruction to deactivate the SCG. CU 172 may send a 463B CU-to-DU message to DU 174 to confirm the instruction and initiate an SCG deactivation procedure 483B to cause UE 102 to deactivate the SCG. In such an implementation, CU 172 does not send a 462B DU-to-CU message. After sending the 461B DU to the CU message or after receiving the 463B acknowledgment from the CU 172, the DU 174 deactivates the 430B SCG.

[0113] If DU 174 determines that UE 102 does not support SCG deactivation, then DU 174 sends a 465B UEContext Release Request message to CU 172. CU 172 can then initiate an SCG release procedure 486B, causing UE 102 and DU 174 to release the SCG at UE 102 and SN 106A, respectively.

[0114] Figures 5A-5B They are usually similar to Figures 4A-4B However, a portion of a single base station is used as both MN and SN, but SN 106A includes CU and DU. Therefore, Figures 5A-5B The events in the scene depicted and similar to those in the story Figures 4A-4B The events discussed are labeled using similar figure-eight notation.

[0115] First go to Figure 5AIn scenario 500A, base station 106A operates as both MN and SN, where MN includes the CU (e.g., CU 172) and the first DU (e.g., DU174A among one or more DU 174). Figure 5A In the diagram, it is referred to as the main DU (M-DU) 174A. The SN includes the same CU of base station 106A and a second different DU (e.g., one or more DUs 174B in DU 174). Figure 5A It is referred to as the auxiliary DU (S-DU) 174B in China. Scenario 500A is generally similar to Scenario 400A, except that base station 106A includes MN and SN.

[0116] Initially, UE 102 communicates with M-DU 174A and CU 172 502A. CU 172 can obtain UE 102's first and second UE capabilities from UE 102, another base station (e.g., base station 104B), or CN 110. To configure the SN for UE 102, CU 172 sends a UE Context Setup Request message 546A, including the second UE capabilities, to S-DU 174B. In response to the UE Context Setup Request message, S-DU 174B sends a UE ContextSetup Response message 548A, including the S-DU configuration. The S-DU configuration includes configuration parameters that UE 102 can use to communicate with S-DU 174B. CU 172 can send the S-DU configuration 507A to M-DU 174A in an RRC reconfiguration message, and M-DU 174A then sends the message 508A to UE 102. In response, UE 102 sends a 510A RRC reconfiguration complete message to M-DU 174A, which in turn sends the same message 511A to CU 172. UE 102 can then communicate in the DC of both M-DU 174A and S-DU 174B 512A. UE 102 can be configured to communicate with CU 172 via M-DU 174A or via S-DU 174B using the S-DU configuration.

[0117] Events 502A, 546A, 548A, 507A, 508A, 510A, 511A, and 512A are in Figure 5A This is collectively referred to as DC Configuration Process 580A.

[0118] At a later time, CU 172 detects that the conditions for deactivating the SCG have been met. In scenario 500A, the detection conditions include determining that UE 102 has data inactivity on the SCG (513A). In response to the detected conditions, CU 172 determines whether UE 102 supports SCG deactivation based on a second UE capability. If so, CU 172 sends a 522A-1RRC reconfiguration message to M-DU 174A, which includes an indication that UE 102 should deactivate the SCG, and M-DU 174A sends the 522A-2 message to UE 102. In response, UE 102 deactivates the SCG (524A) and sends a 526A-1RRC reconfiguration complete message to M-DU 174A, and M-DU 174A sends the 526A-2 message to CU 172. Events 522A-1, 522A-2, 524A, 526A-1, and 526A-2 are in Figure 5A These are collectively referred to as events. CU 172 also executes the 583A SCG deactivation procedure to cause UE 102 to deactivate the SCG. Similar to event 490A, CU 172 also executes the CU-initiated SCG deactivation procedure 590A to cause S-DU 174B to deactivate the SCG.

[0119] If CU 172 determines that UE 102 does not support SCG deactivation, then CU 172 determines to release the SCG. CU 172 sends a 536A-1RRC reconfiguration message to M-DU174A, which includes an indication that UE 102 should release the SCG. M-DU 174A sends a 536A-2RRC reconfiguration message to UE 102. In response, UE 102 releases the SCG (538A) and sends a 540A-1RRC reconfiguration complete message to M-DU 174A, which in turn sends a 540A-2RRC reconfiguration complete message to CU 172. CU 172 also initiates a CU-initiated SCG release procedure 592A to cause S-DU 174B to release the SCG. Events 536A-1, 536A-2, 538A, 540A-1, 540A-2, and 592A occur in... Figure 5A This is collectively referred to as the SCG release process 586A.

[0120] Go to Figure 5B Scenario 500B is similar to Scenario 500A, but the determination of whether to deactivate or release the SCG is made by S-DU 174B instead of CU 172. Scenario 500B is also similar to Scenario 400B, but the base station 106A operates as both MN and SN.

[0121] Following DC configuration procedure 580B, S-DU 174B detects that the conditions for deactivating the SCG have been met. In scenario 500B, S-DU 174B determines for UE 102 511B that there is data inactivity on the SCG. In response, S-DU 174B determines whether UE 102 supports SCG deactivation based on a second UE capability. If so, S-DU 174B sends a DU-to-CU message 561B to CU 172. Events 561B, 563B, 562B, and 564B are similar to events 461B, 463B, 462B, and 464B, respectively. Similar to scenario 400B, CU 172 initiates SCG deactivation procedure 583B to cause UE 102 to deactivate the SCG, and S-DU 174B deactivates the SCG 530b.

[0122] If S-DU 174B determines that UE 102 does not support SCG deactivation, then S-DU 174B sends a 565B UEContext Release Request message to CU 172. CU 172 can then initiate an SCG release procedure 586B to cause UE 102 and S-DU 174B to release the SCG at UE 102 and SN, respectively.

[0123] Figure 6A-19 It is a flowchart depicting a method that a UE (e.g., UE 102) or a node of the RAN (e.g., RAN 105) can perform to manage the deactivation and activation of the SCG between the UE and the RAN.

[0124] Figure 6A This is a flowchart of an example method 600A for requesting the deactivation or activation of an SCG, which can be implemented in a UE (e.g., UE 102). Initially, in block 602A, the UE communicates with the MN and SN of the RAN (e.g., RAN 105) via the MCG and SCG respectively (e.g., events 312A, 380B, 380C, 380D, 412A, 480B, 512A, 580B). Later, in block 604A, the UE detects data inactivity on the SCG. Optionally, if the SCG has been deactivated, the UE can detect data activity on the SCG in block 604A. In block 606A, the UE determines whether it has received a first message from the RAN, which includes a configuration enabling the UE to request SCG deactivation (or, if the SCG has been deactivated, then SCG activation). For example, the first message could be an RRC reconfiguration message received by UE 102 in event 308A.

[0125] If the UE has already received such configuration, then in box 608A, the UE sends a second message to the RAN to request the deactivation of the SCG (or activation if the SCG has already been deactivated). The RAN can determine whether to deactivate (or activate) the SCG based on the second message. Therefore, refer to the message sequence. Figures 3A-5B The conditions for deactivating the SCG can include receiving a second message. Therefore, receiving a second message from the UE can trigger the RAN to determine whether to deactivate or release the SCG. If the UE does not receive a configuration enabling the UE to request SCG deactivation, then in block 610A, the UE restricts the transmission of the second message.

[0126] Figure 6B This is a flowchart of an example method 600B for requesting the deactivation or activation of an SCG, which can be implemented in a UE (e.g., UE 102). Method 600B is generally similar to method 600A. Specifically, blocks 602B, 604B, 606B, and 608B are similar to blocks 602A, 604A, 606A, and 606A, respectively. If the UE determines in block 606B that it has not received a configuration enabling the UE to request SCG deactivation, the UE sends a third message to the MN in block 611B, which causes the MN to release the SCG. For example, the third message could be an SCG failure information message (e.g., an SCG Failure Information message) indicating SCG failure. Receiving the third message from the UE can trigger the RAN to determine the release of the SCG.

[0127] Figure 7This is a flowchart of example method 700, which a UE (e.g., UE 102) can implement to notify the RAN (e.g., the RAN) whether the UE supports SCG deactivation. At block 702, the UE communicates with the RAN (e.g., events 302A, 380B, 380C, 380D, 402A, 480B, 502A, 580B). At block 704, the UE sends a first UE capability to the RAN indicating support for SCG deactivation and activation, where the MN can use the first UE capability to determine whether to initiate SCG deactivation or activation for the UE. For example, if the MN is an ng-eNB or eNB, the first UE capability can be a UE-EUTRA-Capability IE in EUTRA RRC ASN.1 format that can be interpreted by the MN. At block 706, the UE sends a second UE capability to the RAN indicating support for SCG deactivation and activation, where the SN can use the second UE capability to determine whether to initiate SCG deactivation or activation for the UE. For example, if the SN is a gNB, the second UE capability can be an NR-MRDC-Capability IE or a UE-NR-Capability IE in SN-interpretable NR RRC ASN.1 format. In some implementations, the first and second UE capabilities can explicitly indicate whether the UE supports SCG deactivation and activation. In other implementations, the first and second UE capabilities each indicate whether the UE supports SCG deactivation, and the RAN can determine that the UE also supports SCG activation based on the UE's support for SCG deactivation. Generally, unless otherwise specified, a UE capability indicating support for SCG deactivation implies to the RAN that the UE also supports SCG activation.

[0128] In some implementations, the UE may send a single message (e.g., a UECapabilityInformation message) to the RAN that includes both first and second UE capabilities. In other implementations, the UE may send a first message (e.g., a UECapabilityInformation message) and a second message (e.g., a UECapabilityInformation message) to the RAN that respectively include the first and second UE capabilities.

[0129] Figure 8This is a flowchart of an example method 800 that a UE (e.g., UE 102) can implement to notify the RAN (e.g., RAN 105) whether the UE supports SCG deactivation. At block 802, the UE communicates with the RAN (e.g., events 302A, 380B, 380C, 380D, 402A, 480B, 502A, 580B). At block 804, the UE sends to the RAN a UE capability indicating support for SCG deactivation and activation, where both the MN and SN can use the UE capability to determine whether to initiate SCG deactivation or activation for the UE. For example, if both the MN and SN are gNBs, the UE capability can be an NR-MRDC-Capability IE or a UE-NR-Capability IE in NR RRC ASN.1 format, which can be interpreted by the MN and SN. The MN or SN can use the UE capability to determine whether the UE supports SCG deactivation. Therefore, refer to the message sequence. Figures 3A-5B In events 314A, 315B, 315C, 316D, 415A, 417B, 515A, and 517B, the MN or SN can use the UE capability, rather than the first or second UE capability, to determine whether the UE supports SCG deactivation. In some implementations, the UE can send a single message including the UE capability (e.g., a UECapabilityInformation message) to the RAN.

[0130] Figure 9 This is a flowchart of example method 900, which a UE (e.g., UE 102) can implement to notify the RAN (e.g., RAN 105) whether the UE supports SCG deactivation for different DC band combinations. At block 902, the UE communicates with the RAN (e.g., events 302A, 380B, 380C, 380D, 402A, 480B, 502A, 580B). At block 904, the UE sends a UE capability to the RAN indicating support for SCG deactivation and activation for a specific DC band combination. Therefore, the UE capability indicates that the UE supports SCG deactivation when communicating in a DC with an MN on a first band and an SN on a second band, where the first and second bands together define the specific DC band combination. For example, the UE capability could indicate that the UE supports SCG deactivation when communicating in a DC with an MN on band 1 or n1 and an SN on band n78. In another example, the UE capability indicates that the UE supports SCG deactivation when communicating with the MN on band 2 or n2 and the DC on the SN on band n260.

[0131] In some implementations, the UE does not support SCG deactivation when communicating in the DC band of the MN on the third band and the SN on the fourth band. In this example, the UE capability does not indicate support for SCG deactivation in the DC band combination of the third and fourth bands. In some implementations, the second band is in the first frequency range and the fourth band is in the second frequency range. For example, the first and second frequency ranges can be frequency range 1 and frequency range 2 as defined in 3GPP specification 38.101.

[0132] Figure 10 This is a flowchart of an example method 1000 for determining whether to cause SN deactivation or SCG release, which can be implemented by an MN (e.g., base station 104A or 106A operating as MN) of a RAN (e.g., RAN 105). At block 1002, the MN communicates with a UE (e.g., UE 102) operating in the DC of the MN and SN of the RAN via the MCG and SCG respectively (e.g., events 312A, 380B, 380C, 380D, 412A, 480B, 512A, 580B). At block 1004, the MN detects data inactivity on the SCG for the UE (e.g., events 314A, 313B, 313C, 413A, 411B, 513A, 511B). At block 1006, the MN determines whether the UE supports SCG deactivation (e.g., event 316A). In some implementations, the MN also determines whether the SN supports SCG deactivation. However, in most implementations, the MN does not need to explicitly check whether the SN supports SCG deactivation, because the MN knows the SN's capabilities by default.

[0133] If the UE and SN support SCG deactivation, then in block 1008, the MN sends an SCG deactivation command to the UE to cause the UE to deactivate the SCG at the UE (e.g., event 322A). In block 1010, the MN sends a first MN-SN message to the SN to cause the SN to deactivate the SCG at the SN (e.g., event 318A). If the MN and SN are implemented within the same base station, the MN may omit sending the MN-SN message.

[0134] If the UE or SN does not support SCG deactivation, then in box 1012, the MN sends an SCG release command to the UE to cause the UE to release the SCG (e.g., event 336A). In box 1014, the MN sends a second MN-SN message to the SN to cause the SN to release the SCG (e.g., event 332A). If the MN and SN are implemented in the same base station, the MN may omit sending the MN-SN message.

[0135] Figure 11This is a flowchart of an example method 1100 for determining whether to deactivate or release an SCG, which can be implemented by an SN (e.g., base station 104A or 106A operating as an SN) of a RAN (e.g., RAN 105). In block 1102, the SN communicates with the UE operating in the DC of the RAN and the SN via the MCG and SCG respectively (e.g., events 312A, 380B, 380C, 380D, 412A, 480B, 512A, 580B). In block 1104, the SN detects data inactivity on the SCG for the UE (e.g., events 313B, 313C). In block 1106, the SN determines whether the UE supports SCG deactivation (e.g., events 315B, 315C). In some implementations, the SN also determines whether the MN supports SCG deactivation. However, in most implementations, the SN does not need to explicitly check whether the MN supports SCG deactivation because the SN is aware of the MN's capabilities by default.

[0136] If the UE and MN support SCG deactivation, then in block 1108, the SN sends a first SN-to-MN message to the MN (e.g., event 321B). In response, the MN sends an SCG deactivation command to the UE to cause the UE to deactivate the SCG (e.g., event 322B). In some implementations, the SN may directly send the SCG deactivation command to the UE (e.g., event 323C). If the UE or SN does not support SCG deactivation, then in block 1112, the SN sends a second SN-to-MN message to the MN (e.g., event 331B). In response, the MN sends an SCG release command to the UE to cause the UE to release the SCG (e.g., event 336B).

[0137] Figure 12 This is a flowchart of an example method 1200 for determining whether to trigger SN's DU deactivation or SCG release, which can be implemented by the SN's CU (e.g., CU 172). In block 1202, the CU communicates with the UE operating in the DC of the MN and S-DU via the MCG and SCG (e.g., 412A, 480B, 512A, 580B), respectively. In block 1204, the CU detects data inactivity on the SCG for the UE (e.g., events 413A, 513A). In block 1206, the CU determines whether the UE supports SCG deactivation (e.g., events 415A, 515A). In some implementations, the CU also determines whether the S-DU supports SCG deactivation.

[0138] If the UE and S-DU support SCG deactivation, then in block 1208, the CU sends a first CU-DU message to the S-DU to cause the S-DU to deactivate the SCG (e.g., events 462A, 590A). In block 1210, the S-DU sends an SCG deactivation message to the UE via the M-DU or S-DU to cause the UE to deactivate the SCG (e.g., events 483A, 522A-1). If the UE or S-DU does not support SCG deactivation, then in block 1212, the CU sends a second CU-DU message to the S-DU to cause the S-DU to release the SCG (e.g., events 470A, 592A). In block 1214, the CU sends an SCG release command to the UE via the M-DU or S-DU to cause the UE to release the SCG (e.g., events 431A, 536A-1).

[0139] Figure 13 This is a flowchart of an example method 1300 for determining whether to deactivate or release the SCG, which can be implemented by the DU (e.g., DU 174) of the SN (i.e., S-DU). In block 1302, the S-DU communicates with the UE operating in the DC of the MN and S-DU via the MCG and SCG (e.g., 412A, 480B, 512A, 580B), respectively. In block 1304, the S-DU detects data inactivity on the SCG for the UE (e.g., events 411B, 511B). In block 1306, the S-DU determines whether the UE supports SCG deactivation (e.g., events 417B, 517B). In some implementations, the S-DU also determines whether the CU of the S-DU supports SCG deactivation.

[0140] If the UE and CU support SCG deactivation, then in box 1308, the S-DU sends a first DU-CU message to the CU, indicating that the SCG should be deactivated or requesting deactivation of the SCG (e.g., events 461B, 561B). In box 1310, the S-DU may send an SCG deactivation command to the UE to cause the UE to deactivate the SCG. More specifically, the SCG deactivation command originates from the CU, and the S-DU may forward the SCG deactivation command to the UE. If the UE or CU does not support SCG deactivation, then in box 1312, the S-DU sends a second DU-CU message to the CU, indicating or requesting the release of the SCG (e.g., events 465B, 565B). In box 1314, the S-DU may send an SCG release command to the UE, instructing the UE to release the SCG. More specifically, the SCG release command originates from the CU, and the S-DU may forward the SCG release command to the UE.

[0141] Figure 14This is a flowchart of an example method for deactivating and releasing a CG, which can be implemented by a RAN (e.g., RAN 105). In block 1402, the RAN communicates with a UE (e.g., UE 102) operating in a DC connected to both the first and second RAN nodes via a first CG and a second CG, respectively. For example, the first and second RAN nodes can be MN and SN, communicating with the UE via MCG and SCG, respectively. In block 1404, the RAN determines that a first condition for deactivating the first CG is met. For example, the RAN can determine that there is data inactivity on the first CG. If the UE supports deactivating the first CG, then in block 1406, in response to determining that the first condition is met, the RAN sends a CG deactivation command to the UE to deactivate the CG. In some implementations, if the UE supports deactivating the first CG, the RAN enables detection of the first condition. If the UE does not support deactivating the first CG, the RAN does not enable detection of the first condition.

[0142] In some implementations, at block 1408, the RAN node sends a first message to one of the first or second RAN nodes to deactivate the first CG. For example, if the first RAN node determines that a first condition is met, the first RAN node may deactivate the first CG at its location. The first RAN node may omit sending a message to the second RAN node, or it may send a message to the second RAN node to indicate that the first CG should be deactivated or to request deactivation of the first CG. If the second RAN node determines that the first condition is met, the second RAN node may send a first message to the first RAN node to cause the first RAN node to deactivate the first CG.

[0143] In block 1410, the RAN determines that the second condition for releasing the first CG has been met. In response, in block 1412, the RAN sends a CG release command to the UE to release the first CG. In some implementations, in block 1414, the RAN node sends a second message to one of the first or second RAN nodes to release the first CG. For example, if the first RAN node determines that the second condition is met, the first RAN node may release the first CG on its own. The first RAN node may omit sending a message to the second RAN node, or it may send a message to the second RAN node indicating that the first CG should be deactivated or requesting its release. If the second RAN node determines that the second condition is met, the second RAN node may send a second message to the first RAN node to cause the first RAN node to release the first CG.

[0144] Figure 15This is a flowchart of an example method for deactivating the SCG, which can be implemented by an SN (e.g., base station 106A operating as an SN). In block 1502, the SN communicates with a UE (e.g., UE 102) operating in the MN and DC of the RAN via the MCG and SCG, respectively (e.g., events 312A, 380B, 380C, 380D, 412A, 480B, 502A, 580B). In block 1504, the SN generates an SN RRC message for the UE, wherein the SN RRC message includes a first indication for deactivating the SCG for the UE. In block 1506, the SN generates an SN message including the SN RRC message and a second indication to the MN indicating that the SCG has been deactivated. In block 1508, the SN sends an SN message to the MN to cause the MN to send an SN RRC message to the UE and notify the MN of the SCG deactivation via the second indication (e.g., events 321B, 483A, 483B).

[0145] Figure 16A This is a flowchart of an example method 1600A for determining whether to reactivate an SCG in response to a CN-to-BS interface message, which can be implemented by a RAN (e.g., RAN 105). In block 1602A, the RAN communicates with a UE operating in a DC with the RAN's MN and SN. In block 1604A, the RAN deactivates the SCG used for communicating with the UE. In block 1606A, the RAN receives a CN-to-BS interface message from a CN (e.g., CN 110). In block 1608A, the RAN determines whether the CN-to-BS interface message requests the configuration of radio resources (i) for a first Evolved Radio Access Bearer (E-RAB), Quality of Service (QoS) stream, or PDU session, or (ii) for a second E-RAB, QoS stream, or PDU session. The data rate of the first E-RAB, QoS stream, or PDU session may be higher than the data rate of the second E-RAB, QoS stream, or PDU session. For example, a first E-RAB, QoS stream, or PDU session can be used for a service or data stream with a higher data rate (e.g., Internet service), while a second E-RAB, QoS stream, or PDU session can be used for a service or data stream with a lower data rate (e.g., IMS voice call).

[0146] If the CN-to-BS interface message requests the configuration of radio resources for a first E-RAB, QoS flow, or PDU session, the RAN reactivates the SCG in box 1610A. Optionally, if the CN-to-BS interface message requests the configuration of radio resources for a second E-RAB, QoS flow, or PDU session, the RAN restricts the reactivation of the SCG in box 1612A.

[0147] Figure 16BThis is a flowchart of an example method 1600B for determining whether to reactivate an SCG in response to a data packet, which can be implemented by a RAN (e.g., RAN 105). Specifically, blocks 1602A, 1604A, 1610A, and 1612A are similar to blocks 1602B, 1604B, 1610B, and 1612B, respectively. In block 1607B, the RAN receives a data packet from a CN (e.g., CN 110). In block 1609B, the RAN determines whether the data packet is associated with (i) a first radio bearer (RB), E-RAB, QoS stream, or PDU session, or (ii) a second RB, E-RAB, QoS stream, or PDU session. The data rate of the first RB, E-RAB, QoS stream, or PDU session may be higher than the data rate of the second RB, E-RAB, QoS stream, or PDU session. For example, a first RB, E-RAB, QoS stream, or PDU session can be used for a service or data stream with a higher data rate (e.g., Internet service), while a second RB, E-RAB, QoS stream, or PDU session can be used for a service or data stream with a lower data rate (e.g., IMS voice call).

[0148] If the data packet is associated with a first RB, E-RAB, QoS flow, or PDU session, the RAN reactivates the SCG in box 1610B. Optionally, if the data packet is associated with a second RB, E-RAB, QoS flow, or PDU session, the RAN restricts the reactivation of the SCG in box 1612B. In some implementations, the first RB and the second RB can be RBs of different types. For example, the first RB can be an SN-terminated RB, and the second RB can be an MN-terminated RB. In another example, the first RB can be an SCG RB, and the second RB can be an MCG RB.

[0149] Figure 17This is a flowchart of an example method 1700 for determining whether to reactivate the SCG in response to an RRC recovery request message. This method can be implemented by an MN (e.g., base station 104A or 106A operating as the MN). In block 1702, the MN communicates with the UE operating in the DC of the MN and SN of the RAN via the MCG and SCG respectively (e.g., events 312A, 380B, 380C, 380D, 412A, 480B, 512A, 580B). In block 1704, the MN sends an RRC suspension message to the UE (e.g., event 376D). In block 1706, the MN receives an RRC recovery request message from the UE (e.g., event 352D). In block 1708, the UE determines whether the RRC recovery request message includes a specific trigger value. If the RRC recovery request message includes the specific trigger value, then in block 1710, the MN activates the SCG. If the RRC recovery request message does not include the specific trigger value, then in block 1712, the MN restricts the activation of the SCG.

[0150] The trigger values ​​of an RRC recovery request message indicate the triggering of an RRC recovery request. Example trigger values ​​include “emergency,” “highPriorityAccess,” “mt-Access,” “mo-Signalling,” and “mo-Data.” Furthermore, different trigger values ​​may be associated with processes having different data rates. A first set of trigger values ​​with a higher data rate triggers MN to activate the SCG, while a second set of trigger values ​​with a lower data rate triggers MN to limit SCG activation. For example, if the RRC recovery request message includes trigger values ​​from the first set, then MN activates the SCG in box 1710. As another example, if the RRC recovery request message includes a specific trigger value corresponding to data (e.g., mo-Data) from the mobile station (mobile-originating), then MN activates the SCG in box 1710.

[0151] Figure 18 This is a flowchart of an example method for managing the deactivation of SCGs. This method can be... Figures 1A-1CThis is implemented by network nodes (e.g., base station 104A, base station 106A, CU 172, or DU 174). At block 1802, the network node detects that the conditions for deactivating the UE's SCG have been met (e.g., events 314A, 313B, 313C, 352D, 413A, 411B, 513A, 511B). At block 1804, the network node determines whether the UE supports deactivating the SCG (e.g., events 316A, 315B, 315C, 316D, 415A, 417B, 515A, 517B). In box 1806, the network node causes the SN to deactivate or release the SCG at the SN based on this determination (e.g., events 318A, 328A, 332A, 342A, 330B, 344B, 330C, 344C, 318D, 328D, 332D, 342D, 462A, 470A, 461B, 465B, 590A, 592A, 561B, 565B).

[0152] Figure 19 This is a flowchart of an example method for managing the deactivation of SCGs. This method can be... Figure 1A-Figure 1B This is implemented by the UE (e.g., UE 102). In block 1902, the UE provides the RAN with information indicating whether the UE supports the ability to deactivate the SCG (e.g., events 302A, 380B, 380C, 380D, 402A, 480B, 502A, 580B). In block 1904, the UE receives an indication that the UE wants to deactivate or release the SCG (e.g., 322A, 336A, 322B, 336B, 323C, 386C, 354D, 337D, 483A, 436A, 483B, 486B, 552A-2, 536A-2, 583B, 586B). In box 1906, the UE deactivates or releases the SCG at the UE location according to the instruction (e.g., events 324A, 324B, 338B, 324C, 386C, 324D, 338D, 483A, 438A). 483B, 486B, 524A, 538A, 583A, 586B.

[0153] The following list of examples reflects various embodiments explicitly contemplated by this disclosure:

[0154] Example 1. A method for managing the deactivation of a secondary cell group (SCG) in a network node of a radio access network (RAN), the network node communicating with a user equipment (UE), the UE being in dual connectivity (DC) with a primary node (MN) and a secondary node (SN), the method comprising: detecting, by processing hardware of the network node, that a condition for deactivating the SCG is met; determining, by the processing hardware, whether the UE supports deactivating the SCG; and, based on the determination, causing the processing hardware to deactivate or release the SCG at the SN.

[0155] Example 2. According to the method of Example 1, wherein: the determination includes determining that the UE supports deactivating the SCG; and the initiation includes initiating the SN to deactivate the SCG.

[0156] Example 3. According to the method described in Example 2, the method further includes: sending an instruction from the processing hardware to the UE that the UE wants to deactivate the SCG.

[0157] Example 4. According to the method of Example 1, wherein: the determination includes determining that the UE does not support deactivating the SCG; and the initiation includes initiating the SN to release the SCG.

[0158] Example 5. According to the method described in Embodiment 4, the method further includes: sending an instruction from the processing hardware to the UE that the UE wants to release the SCG.

[0159] Example 6. The method according to any of the preceding examples further includes: obtaining UE capability information by processing hardware, wherein the determination is based on the capability information.

[0160] Example 7. According to the method of Example 6, obtaining capability information includes: obtaining capability information formatted according to the radio access technology (RAT) supported by the network node.

[0161] Example 8. The method according to Example 7, wherein: the capability information is first capability information; the RAT is a first RAT; the method further includes obtaining second capability information formatted according to a second RAT different from the first RAT; and the determination includes determining whether the UE supports deactivating the SCG, taking into account the first capability information and disregarding the second capability information.

[0162] Example 9. The method according to Example 8, wherein: the network node is MN; and the method further includes: providing second capability information to SN by processing hardware.

[0163] Example 10. The method according to Example 6 or 7, wherein: the network node is SN; and obtaining capability information includes receiving capability information from MN.

[0164] Example 11. The method according to any of Examples 1-8, wherein: the network node is MN; and the initiation includes sending a request to SN to deactivate or release SCG.

[0165] Example 12. The method according to any of Examples 1-8, wherein: the network node is SN; and the causing includes deactivating or releasing SCG at SN.

[0166] Example 13. The method according to Example 12 further includes: sending a message from the processing hardware to the MN notifying the MN that the SCG has been deactivated.

[0167] Example 14. The method according to any of Examples 1-8, wherein: the network node is a central unit (CU) of a distributed base station operating as an SN; and the initiation includes sending a message to the distributed unit (DU) of the distributed base station instructing the DU to deactivate or release the SCG.

[0168] Example 15. The method according to any of Examples 1-8, wherein: the network node is a distributed unit (DU) of a distributed base station operating as an SN; and the initiation includes deactivating or releasing the SCG at the DU.

[0169] Example 16. The method according to Example 15, wherein the initiation includes: sending a request to the CU to deactivate or release the SCG at the DU; and deactivating or releasing the SCG in response to receiving a response to the request from the CU.

[0170] Example 17. The method according to any of the preceding examples, wherein the detection includes: detecting that the SCG is inactive based on monitoring data activity on the SCG.

[0171] Example 18. The method according to any of Examples 1-16, wherein the detection includes: receiving a request to restore radio connection from the UE when the UE is in an inactive state operation associated with a protocol for controlling radio resources.

[0172] Example 19. The method according to any of Examples 1-16, wherein the detection includes: receiving a message from the UE requesting deactivation of the SCG.

[0173] Example 20. The method according to any of Examples 1-16, wherein the detection includes: receiving a message from the UE indicating SCG failure.

[0174] Example 21. The method according to any one of Examples 1-8, the method further comprising: receiving from the core network (CN) a request by processing hardware to configure radio resources for the data stream of the UE; and determining, by processing hardware, whether to reactivate the SCG based on the data rate of the data stream.

[0175] Example 22. The method according to Example 21, wherein the data stream is associated with at least one of a radio bearer (RB), an evolved radio access bearer (E-RAB), a quality of service (QoS) stream, or a protocol data unit (PDU) session.

[0176] Example 23. The method according to any one of Examples 1-8, the method further comprising: when the UE is operating in an inactive state associated with a protocol for controlling radio resources, receiving from the UE a request to restore the radio connection by processing hardware; and determining, by processing hardware, whether to reactivate the SCG based on a trigger value included in the request.

[0177] Example 24. A network node of a radio access network (RAN) includes processing hardware and is configured to implement the method according to any one of Examples 1-23.

[0178] Example 25. A method for managing the deactivation and activation of a secondary cell group (SCG) in a user equipment (UE), the UE communicating with a radio access network (RAN) via a primary node (MN) and a secondary node (SN) in dual connectivity (DC), the method comprising: providing the RAN with capability information indicating whether the UE supports deactivating the SCG through the UE's processing hardware; receiving from the RAN an indication from the RAN that the UE wants to deactivate or release the SCG; and deactivating or releasing the SCG at the UE according to the indication by the processing hardware.

[0179] Example 26. The method according to Example 25, wherein providing capability information includes: providing capability information formatted according to the Radio Access Technology (RAT) supported by the MN and SN.

[0180] Example 27. The method according to Example 25, wherein providing capability information includes: providing first capability information formatted according to a first RAT supported by MN; and providing second capability information formatted according to a second RAT supported by SN, which is different from the first RAT.

[0181] Example 28. The method according to Example 25, wherein providing capability information includes: providing capability information indicating whether the UE supports deactivating the SCG for a specific DC band combination.

[0182] Example 29. The method according to any of Examples 25-28, wherein providing capability information includes: providing capability information indicating that the UE does not support deactivating the SCG, wherein: receiving the indication includes receiving an indication from the UE to release the SCG; and deactivating or releasing the SCG includes releasing the SCG.

[0183] Example 30. The method according to any one of Examples 25-28, wherein providing capability information includes: providing capability information indicating that the UE supports deactivating the SCG, wherein: receiving the indication includes receiving an indication from the UE to deactivate the SCG; and deactivating or releasing the SCG includes deactivating the SCG.

[0184] Example 31. The method according to Example 30 further includes: detecting that the SCG is inactive by the processing hardware based on monitoring data activity on the SCG; and determining by the processing hardware whether the UE is configured to request deactivation of the SCG.

[0185] Example 32. The method according to Example 31 further includes: if the UE is configured to request deactivation of the SCG, then before receiving the instruction, the processing hardware sends a request to the RAN to deactivate the SCG.

[0186] Example 33. The method according to Example 31 further includes: if the UE is not configured to request deactivation of the SCG, then the processing hardware sends a message indicating SCG failure before receiving the indication.

[0187] Example 34. A user equipment (UE) includes processing hardware and is configured to implement the method according to any one of Examples 25-33.

[0188] Other precautions

[0189] The following additional considerations apply to the foregoing discussion.

[0190] In some implementations, "message" is used, and can be replaced by "information element (IE)". In some implementations, "IE" is used, and can be replaced by "field". In some implementations, "configuration" can be replaced by "multiple configurations" or configuration parameters included in the MN or SN configuration described above. For example, "SN configuration" can be replaced by "multiple SN configurations". SN configuration can be replaced by cell group configuration and / or radio bearer configuration. In some implementations, "deactivate SCG" can be replaced by "suspend SCG", and "activate SCG" can be replaced by "resume SCG" or "reactivate SCG". In some implementations, "lower layer" can be replaced by "protocol layer".

[0191] User equipment implementing the technologies disclosed herein (e.g., UE 102) can be any suitable device capable of wireless communication, such as a smartphone, tablet, laptop, mobile game console, point-of-sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or other personal media device, wearable device such as a smartwatch, wireless hotspot, femtocell base station, or broadband router. Furthermore, in some cases, the user equipment can be embedded in electronic systems, such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Additionally, the user equipment can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user equipment may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0192] Some embodiments described in this disclosure include logic or multiple components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing a specific operation and can be configured or arranged in a particular manner. A hardware module may include permanently configured dedicated circuitry or logic (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC), digital signal processor (DSP)) to perform certain operations. A hardware module may also include programmable logic or circuitry (e.g., included in a general-purpose processor or other programmable processor) temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., software-configured) may be driven by cost and time considerations.

[0193] When implemented in software, these technologies can be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

Claims

1. A method for managing the deactivation of a secondary cell group (SCG) in a network node of a radio access network (RAN), the network node communicating with a user equipment (UE), the user equipment (UE) being in dual connectivity (DC) with a primary node (MN) and a secondary node (SN), the method comprising: The network node's processing hardware detected that the conditions for deactivating the SCG were met; Whether the UE supports deactivating SCG is determined by the processing hardware; as well as Based on the determination made by the processing hardware, the SN is deactivated or the SCG at the SN is released.

2. The method according to claim 1, wherein: The determination includes determining that the UE supports deactivating SCG; and The cause includes causing SN to deactivate SCG.

3. The method according to claim 1, wherein: The determination includes determining that the UE does not support deactivating SCG; and The cause includes causing SN to release SCG.

4. The method according to any one of the preceding claims further includes: Based on the determination, the processing hardware sends an instruction to the UE to deactivate or release the SCG.

5. The method according to any one of the preceding claims further comprises: The UE's capability information is obtained from the processing hardware. The determination is based on the capability information.

6. The method according to claim 5, wherein obtaining capability information includes: Obtain capability information formatted according to the Radio Access Technology (RAT) supported by the network node.

7. The method according to claim 6, wherein: The capability information is the first capability information; The RAT is the first RAT; The method further includes obtaining second capability information formatted according to a second RAT, which is different from the first RAT; and The determination includes taking into account the first capability information and disregarding the second capability information, determining whether the UE supports deactivating the SCG.

8. The method according to claim 7, wherein: The network node is MN; and The method further includes: The processing hardware provides secondary capability information to the SN.

9. The method according to claim 5 or 6, wherein: The network node is SN; and Acquiring capability information includes receiving capability information from the MN.

10. A network node of a radio access network (RAN), including processing hardware and configured to implement the method according to any one of the preceding claims.

11. A method for managing the deactivation and activation of a secondary cell group (SCG) in a user equipment (UE), the UE communicating with a radio access network (RAN) via a primary node (MN) and a secondary node (SN) in dual connectivity (DC), the method comprising: The UE's processing hardware provides the RAN with information indicating whether the UE supports the capability to deactivate the SCG, the provision including: Provides first capability information in a first RAT format supported by MN and provides second capability information in a second RAT format supported by SN; The processing hardware receives from the RAN an instruction from the UE to deactivate or release the SCG; and The processing hardware deactivates or releases the SCG at the UE according to the instructions.

12. The method of claim 11, wherein providing capability information comprises: Provides information indicating whether the UE supports the ability to deactivate the SCG for a specific DC band combination.

13. The method of claim 11 or 12, wherein providing capability information comprises: Provides information indicating that the UE does not support the ability to deactivate SCG, wherein: Receiving the instruction includes receiving an instruction from the UE to release the SCG; and Deactivating or deactivating SCG includes deactivating SCG.

14. The method of claim 11 or 12, wherein providing capability information comprises: Provides information indicating the UE's ability to deactivate the SCG, wherein: Receiving the instruction includes receiving an instruction from the UE to deactivate the SCG; and Deactivating or deactivating SCG includes deactivating SCG.

15. A user equipment (UE) including processing hardware and configured to implement the method according to any one of claims 11-14.

Images