Method and device for managing user equipment connectivity by a master node and a secondary node

Abstract

The network node operates as a master node (MN) for a user equipment (UE), and the user equipment communicates with the MN and a secondary node (SN) via dual connectivity (DC). To manage deactivation of a secondary cell group (SCG), the network node determines (2202) that the SCG has been deactivated, determines (2206) that a radio connection between the MN and the UE should be suspended when the SCG is deactivated, and suspends (2208) the radio connection.

Description

Technical Field

[0001] The present disclosure generally relates to wireless communication, and more specifically, to managing UE connectivity with different nodes such as a master node (MN) and a secondary node (SN) according to UE data activity and inactivity.

Background Art

[0002] This section of the background art description is provided for the purpose of generally presenting the context of the present disclosure. The research of the inventors, as currently named, is not admitted as prior art to the present disclosure, either explicitly or implicitly, to the extent that the research is described in this section of the background art and further to the extent that there is no other form of qualification as prior art at the time of filing.

[0003] User devices (or user equipment, generally denoted by the initials "UE") can, in some cases, simultaneously utilize the resources of multiple network nodes, such as base stations, interconnected by a backhaul. This type of connectivity is referred to as dual connectivity (DC) or multi-radio DC (MR-DC) when these network nodes support the same radio access technology (RAT) or different RATs, respectively. Typically, when a UE operates in DC or MR-DC, one base station operates as a master node (MN) and the other base station operates as a secondary node (SN). The backhaul can support, for example, an X2 or Xn interface.

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

[0005] When operating in DC, there are several types of SRBs available for the UE. SRB1 and SRB2 resources enable the UE and MN to exchange RRC messages related to MN and embed RRC messages related to SN, and can be referred to as MCG SRBs. SRB3 resources enable the UE and SN to exchange RRC messages related to SN, and can be referred to as SCG SRBs. Split SRBs enable the UE to directly exchange RRC messages with MN by using the radio resources of MN, SN, or both MN and SN. Further, the UE and base stations (e.g., MN and SN) use data radio bearers (DRBs) to transport data on the user plane. A DRB terminated at MN and using only the lower layer resources of MN is referred to as an MCG DRB, a DRB terminated at SN and using only the lower layer resources of SN is referred to as an SCG DRB, and a DRB terminated at MCG but using the lower layer resources of both MN and SN can be referred to as a split DRB. A DRB terminated at MN but using only the lower layer resources of SN can be referred to as an MN-terminated SCG DRB. A DRB terminated at SN but using only the lower layer resources of MN can be referred to as an SN-terminated MCG DRB.

[0006] In some scenarios, the UE may transition to the inactive or idle state of the RRC protocol in a suspended configuration. Considering inbound or outbound data traffic, in other scenarios, the UE and / or the SN may determine that the UE does not need an SN connection. It is not clear how the RAN and the UE should manage the MCG and SCG connections in these situations.

Summary of the Invention

Problems to be Solved by the Invention

[0007] A network node and / or the UE implements the techniques of the present disclosure to manage the deactivation and activation of the SCG. When the SCG should be deactivated, one or more of the MN, SN, and UE can determine whether the UE should retain some or all of the SN configuration. Further, the MN can determine whether the radio connection between the UE and the MN on the MCG should be suspended. The MN can notify the UE regarding the deactivation of the SCG and, in some cases, the suspension of the radio connection, whereby the UE can transition to the inactive or idle state in a suspended configuration. After the reactivation of the SCG, the MN can determine whether the radio connection between the MN and the UE should remain suspended.

Means for Solving the Problems

[0008] In various implementations or scenarios, when the SCG is deactivated and the radio connection with the MN is suspended, the UE can release a part of the MN configuration and retain the remaining MN configuration. The UE in these situations can similarly release some or all of the SN configuration and, in some cases, release the lower layer of the SCG connection and maintain the upper layer of the SCG connection by means of a keep-alive function.

[0009] One exemplary embodiment of these techniques is a method in a network node operating as a MN for a UE communicating with a MN and a SN with a DC to manage deactivation of the SCG. This method includes determining by the processing hardware of the network node that the SCG is to be deactivated, notifying by the processing hardware the UE that the SCG is to be deactivated, determining by the processing hardware that the radio connection between the MN and the UE should be suspended when the SCG is deactivated, and suspending by the processing hardware the radio connection.

[0010] Another exemplary embodiment of these techniques is a network node operating in a RAN, the network node comprising processing hardware and configured to implement the above method.

[0011] Another exemplary embodiment of these techniques is a method in a UE communicating with a MN in a MN configuration, a SN in a SN configuration, and a DC to manage deactivation of the SCG. This method includes determining by the processing hardware that the SCG is to be deactivated, determining by the processing hardware that the radio connection between the UE and the MN should be suspended, and suspending or releasing at least a part of the MN configuration in response to determining that the radio connection should be suspended.

[0012] Another exemplary embodiment of these techniques is a UE comprising processing hardware and configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0013]

Figure 1A

Figure 1B

Figure 2

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 3E

Figure 4A

Figure 4B

Figure 4C

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 12C

Figure 13A

Figure 13B

Figure 13C

Figure 14A

Figure 14B

Figure 14C

Figure 15A

Figure 15B

Figure 16A

Figure 16B

Figure 16C

Figure 17A

Figure 17B

Figure 17C

Figure 18A

Figure 18B

Figure 18C

Figure 19

Figure 20

Figure 21A

Figure 21B

Figure 21C

Figure 22

Figure 23

DETAILED DESCRIPTION OF THE INVENTION

[0014] As described in detail below, a network node of a radio access network (RAN) that communicates with a UE operating in DC can implement the techniques disclosed herein to manage the deactivation of multi-radio dual connectivity (MR-DC) along with the suspension of the radio connection between the UE and the MN and, in some cases, the reactivation of the SCG. Before describing these techniques, an exemplary communication system in which these techniques can be implemented is considered with reference to FIGS. 1A and 1B.

[0015] FIG. 1A shows an exemplary wireless communication system 100 that includes a UE 102, a base station (BS) 104A, a base station 106A, and a core network (CN) 110. The base stations 104A and 106A may operate in a RAN 105 connected to the same core network (CN) 110. The CN 110 may be implemented, for example, as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160.

[0016] There are also other components, but in particular, EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 is generally configured to transfer user plane packets related to, for example, voice calls, video calls, Internet traffic, etc. The MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks, such as the Internet network and / or the Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management (AMF) 164, and / or a Session Management Function (SMF) 166. Generally, the UPF 162 is configured to transfer user plane packets related to, for example, voice calls, video calls, Internet traffic, etc. The AMF 164 is configured to manage authentication, registration, paging, and other related functions. The SMF 166 is configured to manage PDU sessions.

[0017] As illustrated in FIG. 1A, 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 such that UE 102 can communicate with base stations 104A and 106A operating as a master node (MN) and a secondary node (SN), respectively, over DC. Cells 125A and 126A may partially overlap such that UE 102 can communicate with base station 106A operating as a master node (MN) and a secondary node (SN), respectively, over CA or DC. To directly exchange messages in the DC scenario and other scenarios described below, base station 104A (also referred to herein as MN104A) and base station 106A (also referred to herein as SN106A) can support an X2 or Xn interface. In general, CN 110 can be connected to any suitable number of base stations that support 5G New Radio (NR) cells and / or EUTRA cells.

[0018] As illustrated in FIG. 1A, base station 104A supports cell 124A and base station 106A supports cell 126A. Cells 124A and 126A may partially overlap such that UE 102 can communicate with base stations 104A and 106A operating as a master node (MN) and a secondary node (SN), respectively, over DC. To directly exchange messages in the DC scenario and other scenarios described below, MN104 and SN106A can support an X2 or Xn interface. In general, CN 110 can be connected to any suitable number of base stations that support NR cells and / or EUTRA cells.

[0019] The base station 104A is equipped with processing hardware 130 that can include one or more general-purpose processors such as a CPU, a non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or a dedicated processing unit (e.g., an application-specific integrated circuit (ASIC) or a digital signal processor (DSP)). The processing hardware 130 in the exemplary implementation of FIG. 1A includes an MN RRC controller 132 configured to manage or control RRC configurations and RRC procedures. For example, the base station RRC controller 132 supports RRC messaging associated with RRC connection establishment procedures, RRC connection resume procedures, RRC connection re-establishment procedures, RRC reconfiguration procedures, MR-DC, CA, or procedures for other suitable functions, and / or can be configured to support operations required when the base station 104A operates as an MN as described below. The processing hardware 130 can include an SCG controller 134 configured to manage or control the deactivation and / or activation of the SCG between the UE 102 and the SN.

[0020] The base station 106A is equipped with processing hardware 140 that can also include one or more general-purpose processors such as a CPU, a non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or a dedicated processing unit (e.g., an ASIC or a DSP). The processing hardware 140 in the exemplary implementation includes an SN RRC controller 142 configured to manage or control RRC configurations and RRC procedures. The processing hardware 140 can include an SCG controller 144 configured to manage, control, or execute the deactivation and / or activation of the SCG between the UE 102 and the SN. Generally, since a base station can operate as an MN or an SN in different scenarios, the RRC controllers 132 and 142 implement a similar set of functions and can each support the operations of both the MN and the SN.

[0021] Referring still to FIG. 1A, the UE 102 may be equipped with processing hardware 150 that includes one or more general-purpose processors such as a CPU and a non-transitory computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or a dedicated processing unit. The processing hardware 150 in the exemplary implementation of FIG. 1A includes a UE RRC controller 152 configured to manage or control RRC configurations and / or RRC procedures. For example, the UE RRC controller 152 may be configured to support RRC messaging associated with RRC connection establishment procedures, RRC connection resume procedures, RRC connection re-establishment procedures, and / or procedures for MR-DC, CA, or other suitable functions, according to any of the implementations described below. The processing hardware 150 may include an SCG controller 154 configured to manage, control, or perform deactivation and / or activation of the SCG between the UE 102 and the SN.

[0022] More specifically, the RRC controllers 132, 142, and 152 may implement at least some of the techniques described below (while referring to various messaging and flow diagrams) to manage RRC configurations. The SCG controllers 134, 144, and 154 may implement at least some of the techniques described below (while referring to various messaging and flow diagrams) to manage SCG deactivation and / or activation.

[0023] During operation, UE102 can use radio bearers (e.g., DRBs or SRBs) that terminate at MN104 or SN106A at different times. UE102 can receive a radio bearer configuration that configures a radio bearer from MN104A or SN106A. UE102 can apply one or more security keys in the uplink (from UE102 to the base station) and / or downlink (from the base station to UE102) direction when communicating over the radio bearer. UE102 can, in some cases, use different RATs to communicate with base stations 104A and 106A. The following examples may refer to specific RAT types, 5G NR or EUTRA, but generally, the techniques of the present disclosure can also be applied to other suitable radio access and / or core network technologies.

[0024] Figure 1B depicts an exemplary, distributed or non - centralized implementation of any one or more of base stations 104, 106A. In this implementation, base station 104A or 106A comprises a central unit (CU) 172 and one or more DUs 174. CU172 includes processing hardware such as one or more general - purpose processors (e.g., CPUs) and computer - readable memory storing machine - readable instructions executable on the general - purpose processors and / or dedicated processing units. For example, CU172 can comprise the processing hardware 130 or 140 of FIG. 1A.

[0025] Each of DU174 can also include processing hardware that includes one or more general-purpose processors (e.g., CPUs) and a 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 can 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 process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0026] In some implementations, CU172 can include a logical node CU-CP172A that hosts the control plane portion of the packet data convergence protocol (PDCP) protocol of CU172. CU172 can also include a logical node CU-UP172B that hosts the user plane portion of the PDCP protocol and / or the service data adaptation protocol (SDAP) protocol of CU172. CU-CP 172A can transmit control information (e.g., RRC messages, F1 application protocol messages), and CU-UP172B can transmit data packets (e.g., SDAP PDUs or Internet protocol packets).

[0027] CU-CP172A can be connected to a plurality of CU-UP172B through the E1 interface. CU-CP172A selects an appropriate CU-UP172B for the requested service for UE102. In some implementations, a single CU-UP172B can be connected to a plurality of CU-CP172A through the E1 interface. CU-CP172A can be connected to one or more DUs174 through the F1-C interface. CU-UP172B can be connected to one or more DUs174 through the F1-U interface under the control of the same CU-CP172A. In some implementations, one DU174 can be connected to a plurality of CU-UP172B under the control of the same CU-CP172A. In such an implementation, the connectivity between CU-UP172B and DU174 is established by CU-CP172A using the bearer context management function.

[0028] Figure 2 illustratively shows in a simplified manner an exemplary protocol stack 200 that UE102 can follow when communicating with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104A, 106A).

[0029] In the exemplary stack 200, the physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides RLC channels to the EUTRA PDCP sublayer 208 and in some cases to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide the data transfer services to the service data adaptation protocol (SDAP) 212 or to a radio resource control (RRC) sublayer (not shown in FIG. 2). The UE 102 supports both the EUTRA and NR stacks as shown in FIG. 2 to support handover between the EUTRA and NR base stations and / or to support DC on the EUTRA and NR interfaces in some implementations. Further, as illustrated in FIG. 2, the UE 102 can support the layering of NR PDCP 210 on EUTRA RLC 206A and the SDAP sublayer 212 on the NR PDCP sublayer 210.

[0030] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which may be referred to as service data units (SDUs) (e.g., from an Internet protocol (IP) layer directly or indirectly layered on top of the PDCP layer 208 or 210), and output packets, which may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except where the difference between the SDU and the PDU is relevant, in the present disclosure, for simplicity, both the SDU and the PDU are referred to as "packets".

[0031] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide, for example, SRBs for exchanging RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0032] In a scenario where the UE 102 operates as a MeNB with the base station 104A and as an SgNB with the base station 106A and operates in EN-DC, the wireless communication system 100 can provide the UE 102 with an MN-terminated bearer using the EUTRA PDCP sublayer 208 or an MN-terminated bearer using the NR PDCP sublayer 210. Also, the wireless communication system 100 in various scenarios can provide the UE 102 with an SN-terminated bearer that uses only the NR PDCP sublayer 210. The MN-terminated bearer may be an MCG bearer or a split bearer. The SN-terminated bearer may be an SCG bearer or a split bearer. The MN-terminated bearer may be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN-terminated bearer can be an SRB (e.g., SRB3) or a DRB.

[0033] Below the PDCP layer, the PHY, MAC, and RLC layers can all be generally referred to as one or more lower layers (e.g., PHY202A / 202B, MAC204A / 204B, and / or RLC206A / 206B). While managing the connectivity between the base stations 104A, 106A and the UE 102, one or more of these lower layers can be suspended, released, resumed, reset, or re-established.

[0034] Next, several exemplary scenarios in which a base station operating within the system of FIG. 1A deactivates an SCG and / or reactivates an SCG that was previously deactivated are described with reference to FIGS. 3A-6B. Generally, events within similar FIGS. 3A-3D and FIGS. 5A and 5B are labeled with similar reference numbers (e.g., event 316A is similar to events 316B-D and 516A and B), and differences are described as appropriate hereinafter. Events within similar FIGS. 4A-4C and FIGS. 6A and 6B are labeled with similar reference numbers (e.g., event 404A is similar to events 404B-C and 604A-B), and differences are described as appropriate hereinafter.

[0035] Referring initially to FIG. 3A, in scenario 300A, base station 104A operates as an MN and base station 106A operates as an SN. Initially, UE 102 communicates with MN 104A and SN 106A in DC to transmit uplink (UL) PDUs and / or downlink (DL) PDUs, respectively, according to a first MN configuration and a first SN configuration at 302A. In some implementations, UE 102 can transmit UL PDUs and / or DL PDUs via radio bearers that can include SRBs and / or DRBs in DC at 302A. MN 104A and / or SN 106A can configure radio bearers to UE 102. UE 102 communicates with MN 104A on MCG and SN 106A on SCG in DC. As part of the first MN configuration, MN 104A configures an MCG that includes at least one serving cell of MN 104A. As part of the first SN configuration, SN 106A configures an SCG that includes at least one serving cell of SN 106A. In some implementations, the first MN configuration includes a plurality of configuration parameters, and UE 102 receives the configuration parameters in one or more RRC messages from MN 104A. In other implementations, the first SN configuration includes a plurality of configuration parameters, and UE 102 receives the configuration parameters in one or more RRC messages from SN 106A, for example, via MN 104A, or on an SRB (e.g., SRB3) configured by MN 104A or SN 106A to exchange RRC messages between UE 102 and SN 106A.

[0036] At a later point in time, MN104A decides 308A to deactivate the SCG for communication with UE102. In some implementations, MN104A detects data inactivity on the SCG and, in response, decides 308A to deactivate the SCG for UE102. In one implementation, MN104A detects data inactivity on the SCG based on a message for UE102 that MN104A receives from SN106A. For example, SN106A may detect data inactivity for UE102 or the amount of data for UE102 is small, and in response, transmits 304A to MN104A an activity notification message having an inactivity indication for UE102. MN104A can then decide 308A to deactivate the SCG for UE102 based on the received activity notification message. In another implementation, MN104A does not receive from CN110 (shown in FIG. 1A) any data packets to be transmitted to UE102 via SN106A for a predetermined time period, and thus detects that there is data inactivity on the SCG.

[0037] In other implementations, MN104A decides to deactivate the SCG for UE102 based on the UE preference that MN104A receives from UE102. For example, UE102 can transmit 306A to MN104A UE assistance information (e.g., UE Assistance Information message), indicating that the UE currently prefers single connectivity for power saving or due to overheating. MN104A decides 308A to deactivate the SCG for UE102 in response to the UE assistance information received in event 306A.

[0038] In response to decision 308A, MN104A transmits, at 310A, a SN modification request message to SN106A to deactivate the SCG for UE102. In some implementations, MN104A includes an indication (e.g., a field or information element (IE)) to deactivate the SCG within the SN modification request message of event 310A to cause SN106A to deactivate the SCG. In response to the SN modification request message, SN106A transmits, at 312A, a SN modification request confirmation response message to MN104A.

[0039] After MN104A transmits the SN modification request message at 308A in response to decision 308A, or after MN104A receives the SN modification request confirmation response message at 312A, MN104A transmits, at 314A, an RRC reconfiguration message that causes UE102 to deactivate the SCG. In response to the RRC reconfiguration message, UE102 deactivates, at 316A, the SCG for communication with SN106A and transmits, at 318A, an RRC reconfiguration complete message to MN104A. After deactivating the SCG, UE102 maintains a radio connection with MN104A. After receiving the RRC reconfiguration complete message, MN104A may transmit, at 320A, a SN message (e.g., a SN reconfiguration complete message) to SN106A indicating that UE102 has deactivated the SCG.

[0040] In some implementations, SN106A includes additional SN configuration within SN modification request confirmation response message 312A, and MN104A includes additional SN configuration within RRC reconfiguration message 314A to deactivate all or part of the SCG configuration in the UE. In some implementations, SN106A generates additional SN configuration as a delta SN configuration that deactivates the SCG in the UE by enhancing only a part of the first SN configuration in the UE. Thus, UE102 enhances or modifies only a part of the first SN configuration with the delta SN configuration and retains the part of the first SN configuration that is not enhanced by the delta SN configuration. In other implementations, SN106A generates additional SN configuration as a complete self - contained configuration (i.e., complete SN configuration). UE102 replaces the first SN configuration with the additional SN configuration. In yet other implementations, SN106A does not include SN configuration within SN modification request confirmation response message 312A, and thus, MN104A does not include SN configuration within RRC reconfiguration message 314A.

[0041] In some implementations, MN104A can also include a second MN configuration within the RRC reconfiguration message that MN104A transmits 314A. In this case, UE102 communicates with MN104A using the second MN configuration after receiving the RRC reconfiguration message 314A. In some implementations, MN104A generates the second MN configuration as a delta MN configuration that enhances only a part of the first MN configuration. Thus, UE102 communicates with MN104A using the delta MN configuration and a part of the first MN configuration that is not enhanced by the delta MN configuration. In other implementations, MN104A does not include MN configuration within the RRC reconfiguration message that MN104A transmits 314A.

[0042] After 312A that transmitted an SN modification request confirmation response message in response to 310A that received an SN modification request message, or after 320A that received an SN message, SN106A can deactivate the SCG for communication with the UE102 at 322A. Events 304A, 306A, 308A, 310A, 312A, 314A, 316A, 318A, 320A, and 322A are collectively referred to as the SCG deactivation procedure 390A in Figure 3A.

[0043] In some implementations, after deactivating the SCG, SN106A suspends one or more lower layers of the radio connection between SN106A and UE102. While the lower layer is suspended, SN106A in one implementation does not transmit downlink transmissions to UE102 using the lower layer. SN106A in another implementation does not receive uplink transmissions from UE102 via the suspended lower layer. In some implementations, SN106A includes a CU (e.g., CU172) and a DU (e.g., DU174). The CU can send a UE context request message (e.g., a UE context modification request message) to the DU that includes an instruction to suspend the lower layer after performing deactivating the SCG 322A, or receiving an SN modification request message 310A, or receiving an SN message 320A, or transmitting an SN modification request confirmation response message 320A, or in response to performing any of these. In response to the UE context request message or the instruction to suspend the lower layer, the DU suspends the lower layer for communication with UE102 and sends a UE context response message (e.g., a UE context modification response message) to the CU. Similarly, in some implementations, UE102 suspends the lower layer for communication with SN106A to deactivate the SCG. While the lower layer is suspended, UE102 in one implementation does not transmit uplink transmissions to SN106A via the lower layer. While the lower layer is suspended, UE102 in another implementation does not receive downlink transmissions from SN106A via the lower layer. For example, the downlink transmission can include a PDU (e.g., a MAC PDU or an RLC PDU), downlink control information (DCI) having a cyclic redundancy check (CRC) scrambled with a cell radio network temporary identifier (C-RNTI), and / or a reference signal (e.g., a channel state information reference signal (CSI-RS)).In another example, the uplink transmission may include a PDU (e.g., a MAC PDU or an RLC PDU), channel state information (CSI), a physical uplink control channel (PUCCH), and / or a sounding reference signal (SRS).

[0044] In other implementations, after deactivating the SCG, SN106A releases one or more lower layers of the radio connection between SN106A and UE102. More specifically, in this case, SN106A releases the lower layer resources for communicating with UE102. These resources may include software, firmware, memory resources, and / or processing capabilities used to implement the functions of the PHY202A / 202B, MAC204A / 204B, and / or RLC206A / 206B layers for SN106A to communicate with the UE. If SN106A includes a CU and a DU, the CU sends a UE context release command message to the DU, which causes the DU to release the lower layers for communicating with UE102. In response to the UE context release command message, the DU releases the lower layer resources for communicating with UE102.

[0045] In some implementations, MN104A can include an indication in the SN modification request message for event 310A that SN106A should deactivate the SCG. In other implementations, MN104A can include an indication in the SN modification request message for event 310A that SN106A should suspend the lower layers. In the latter case, MN104A can include this indication in addition to or instead of the indication that SN106A should deactivate the SCG.

[0046] In some implementations, UE 102 starts a timing advance value or a time alignment timer associated with uplink synchronization before deactivating the SCG. In response to deactivating the SCG, UE 102 maintains the time alignment timer running so as to determine that UE 102 is synchronized with the uplink SN 106A on the SCG. Similarly, the DU of SN 106A or SN (not shown in FIG. 3A) starts a corresponding time alignment timer for UE 102 to determine whether UE 102 is synchronized with SN 106A on the uplink of the SCG before activating the SCG, and maintains the corresponding time alignment timer running in response to deactivating the SCG.

[0047] In some implementations, UE102 starts one or more timers associated with the SCG before deactivating the SCG, and UE102 stops the timers in response to deactivating the SCG. For example, the timers include timers T310, T312, T321, T322, T342, T345, T346a, T346b, T346c, T346d, T346e and / or T346f specified in 3GPP™ specification 38.331 or 36.331 v16.3.0. In response to deactivating the SCG, UE102, in other implementations, maintains some of the timers running and stops a second, non-overlapping subset of the timers. In yet other implementations, UE102 may detect an SCG failure before receiving the RRC reconfiguration message 314A. If UE102 does not notify MN104A of the SCG failure after receiving the RRC reconfiguration message 314A, UE102, in some implementations, stops or refrains from transmitting an SCG failure information message indicating the SCG failure to MN104A. Alternatively, UE102 may still transmit an SCG failure information message indicating the SCG failure to MN104A independent of receiving the RRC message 314A. In some implementations, in response to receiving or after receiving an SCG failure information message, MN104A refrains from transmitting a second RRC reconfiguration message to UE102 to activate the SCG (to recover from the SCG failure) after making a decision to deactivate the SCG 308A. In other implementations, MN104A activates the SCG as described in event 370E or 380E of FIG. 3E to recover from the SCG failure in response to or after receiving the SCG failure information message.

[0048] Continuing to refer to FIG. 3A, after receiving an RRC reconfiguration message from 314A or after deactivating the SCG at 316A, UE 102 may retain the first SN configuration (or retain some components of the first SN configuration). SN 106A may also retain the first SN configuration (or retain some components of the first SN configuration). In some implementations, UE 102 may release the configuration in the first SN configuration after 314A where the RRC reconfiguration message was received, or after 316A where the SCG was deactivated. Correspondingly, SN 106A may also release the configuration in the first SN configuration after 322A where the SCG was deactivated.

[0049] In some implementations, UE 102 may release the first part of the first SN configuration and retain the second part of the first SN configuration after 314A where the RRC reconfiguration message was received or after 316A where the SCG was deactivated, or in response thereto. SN 106A may also release the corresponding part of the first SN configuration and retain the second part of the first SN configuration, for example, after it is determined that the SCG should be deactivated (event 310A or 312A) or after the SCG is deactivated (event 320A or 322A), or in response thereto.

[0050] In other implementation forms, after the UE 102 deactivates the 314A or the SCG that has received the RRC reconfiguration message, or in response to having done so, the UE 102 may hold the first part of the first MN configuration and hold the second part of the first MN configuration. Correspondingly, the MN 104A may also hold the first part of the first MN configuration and the second part of the first MN configuration after the 308A that has determined that the SCG should be deactivated, the 310A that has deactivated the SCG, the 314A that has transmitted the RRC reconfiguration message, or the 318A that has received the RRC reconfiguration complete message, or in response to having done so. After deactivating the SCG, the UE 102 uses the second part of the first MN configuration to communicate with the MN 104A and does not use the first part of the first MN configuration to communicate with the MN 104A.

[0051] Referring back to FIG. 3A, events 324A, 326A, and 330A are collectively referred to as the RRC suspend procedure 394A. At a later point with respect to the SCG deactivation procedure 390A, MN104A can detect further data inactivity for UE102 and, in response, decides to configure UE102 to enter an inactive state (e.g., the RRC_INACTIVE state) 324A. In some implementations, MN104A can start a data inactivity timer to monitor for further data activity after MN104A receives a message at event 304A. When the data inactivity timer expires and MN104A neither transmits data to UE102 nor receives data from UE102 nor receives an activity communication message including an active indication for UE102 from SN106A while the data inactivity timer is running, MN104A detects further data inactivity for UE102. Conversely, when MN104A has data to transmit to UE102, receives data from UE102, or receives an activity notification message including an inactive indication for UE102 while the data inactivity timer is running, MN104A can restart the data inactivity timer. In response to detecting further data inactivity for UE102 (e.g., expiration of the data inactivity timer), MN104A decides to configure UE102 to enter an inactive state.

[0052] In response to decision 324A, in some implementations, MN104A can send a SN request message (e.g., a SN modification request message) including an instruction to release the lower layer for UE102 to SN106A at 326A. In response to receiving the SN request message, or after receiving the SN request message, SN106A can release the lower layer and send a SN request confirmation message (e.g., a SN modification request confirmation response message) to MN104A. In some implementations, SN106A can release the lower layer resources allocated for communicating with UE102 in response to the SN request message or an instruction to release the lower layer. These resources can include, for example, software, firmware, memory resources (e.g., memory hardware or storage areas within memory hardware), and / or processing capabilities used by SN106A to implement the functions of PHY202A / 202B, MAC204A / 204B, and / or RLC206A / 206B layers for communicating with UE102. For example, SN106A can allocate processing capabilities from its ASIC, DSP, and / or CPU for communicating with UE102, and may be configured to release the allocated processing capabilities in response to an instruction to release the lower layer. In other implementations, SN106A can release a first SN configuration or a part of the first SN configuration in response to an instruction to release the lower layer. In some implementations, SN106A can hold at least one interface identifier (ID) of UE102 for exchanging interface messages between MN104A and SN106A in response to an instruction to release the lower layer. For example, if the interface between MN104A and SN106A is an Xn interface (e.g., the Xn interface shown in Figure 1A), the at least one interface ID can include a first UE XnAP ID assigned by SN106A and a second UE XnAP ID assigned by MN104A.In another example, when the interface between MN104A and SN106A is the X2 interface, at least one interface ID can include a first UE X2AP ID assigned by SN106A and a second UE X2AP ID assigned by MN104A.

[0053] In response to decision 324A, in other implementations, MN104A sends a SN request message (e.g., a SN modification request message) including an instruction to suspend the lower layer for communicating with UE102 to SN106A at 326A. In response to receiving or after receiving a SN request message (e.g., a SN modification request confirmation response message), SN106A suspends the lower layer and sends a SN request confirmation response message (e.g., a SN modification request confirmation response message) to MN104A. In some implementations, SN106A releases the resources of the lower layer allocated to communicate with UE102 in response to an instruction to suspend the lower layer. These resources may include software, firmware, memory resources, and / or processing capabilities used to implement the functions of the PHY202A / 202B, MAC204A / 204B, and / or RLC206A / 206B layers for SN106A to communicate with UE102. For example, SN106A can allocate processing capabilities from the ASIC, DSP, and / or CPU of SN106A to communicate with UE102 and can release the allocated processing capabilities in response to an instruction to suspend the lower layer. In other implementations, SN106A holds the resources of the lower layer allocated to communicate with UE102 despite receiving an instruction to suspend the lower layer and despite suspending the operations of the PHY202A / 202B, MAC204A / 204B, and / or RLC206A / 206B layers (i.e., despite suspending communication with UE102).

[0054] In yet other implementations, SN106A may hold or release the first SN configuration or a part of the first SN configuration in response to an instruction 326A to suspend the lower layer. In some implementations, SN106A may hold at least one interface ID of UE102 for exchanging interface messages between MN104A and SN106A in response to an instruction to suspend the lower layer. For example, if the interface between MN104A and SN106A is an Xn interface (such as shown in FIG. 1A), the interface ID may include a first UE XnAP ID assigned by SN106A and a second UE XnAP ID assigned by MN104A. In another example, if the interface between MN104A and SN106A is an X2 interface, the at least one interface ID may include a first UE X2AP ID assigned by SN106A and a second UE X2AP ID assigned by MN104A.

[0055] In some implementations, MN104A does not trigger a decision 324A to send an SN request message to SN106A. That is, MN104A decides to keep the SCG for UE102 deactivated even if MN104A makes the decision 324A. In other implementations, MN104A may send an SN release request message to SN106A in response to the decision, and in response, SN106A may send an SN release request confirmation response message to MN104A (not shown).

[0056] In response to decision 324A, after MN104A optionally transmits SN request message 326A, or after MN104A receives an SN request confirmation response message (not shown), MN104A transmits RRC suspend message 328A that causes UE102 to transition to the inactive state. In response to the RRC suspend message, UE102 transitions to the inactive state 330A. In some implementations, UE102 stops or clears the time alignment timer to disable uplink synchronization in response to the RRC suspend message. Similarly, SN106A stops the corresponding time alignment timer for UE102 and disables uplink synchronization in response to or after receiving SN request message 326A. In other implementations, UE102 determines in response to the RRC suspend message that the time alignment timer is invalid or that it is no longer synchronized with SN106A on the uplink over the SCG. Similarly, SN106A determines in response to or after receiving SN request message 326A that the corresponding time alignment timer is invalid or that UE102 is no longer synchronized with SN106A on the uplink over the SCG.

[0057] In some alternative implementations, MN104A may decide 324A that UE102 should be configured to enter an idle state where the radio connection is suspended rather than an inactive state. In the RRC suspend message, MN104A may instruct 330A UE102 to enter an idle state where the radio connection is suspended. Then, in response to the RRC suspend message, UE102 enters an idle state where the radio connection is suspended instead of entering an inactive state. In other alternative implementations, MN104A may decide 324A that UE102 should be configured to enter an idle state without a suspended radio connection. In this case, instead of sending a RRC suspend message 328A, MN104A may send a RRC release message to UE102 to instruct 330A UE102 to enter an idle state without a suspended radio connection. In response to the RRC release message (not shown), UE102 enters an idle state without a suspended radio connection and releases the first MN configuration and the first SN configuration. In response to deciding to configure UE102 to enter an idle state without a suspended radio connection, MN104A may send a SN release request message and / or a context release message to SN106A.

[0058] In the idle state when in the non-active state or the RRC connection is suspended, UE102 suspends the radio connection with MN104A but retains the first MN configuration (or at least some components of the first MN configuration). In some implementations, MN104A stores a UE context (e.g., a UE access stratum (AS) context or a UE non-active AS context as defined by 3GPP specifications, a part of the UE AS context, or a part of the UE non-active AS context) for UE102 in the idle state of the non-active state or the state where the radio connection is suspended. MN104A communicates with UE102 according to the UE context while UE102 is in the connected state. The UE context can include, for example, a security key, a configuration for MCG (e.g., including one or more cells of MN104A, the first MN configuration or a part of the first MN configuration), and a radio bearer configuration constituting one or more MN-terminated bearers and / or one or more SN-terminated bearers. One or more MN-terminated bearers and / or one or more SN-terminated bearers can include SRB and / or DRB. Correspondingly, UE102 in the idle state of the non-active state or the state where the radio connection is suspended stores a UE context similar to the UE context stored by MN104A.

[0059] Continuing to refer to Figure 3A, upon receiving the RRC suspend message at 328A, UE102 may retain the (enhanced) first SN configuration (or retain some components of the (enhanced) first SN configuration) and / or retain the SCG deactivation configuration. However, as described below, in some implementations, UE102 does not retain the first SN configuration for a sufficiently long time for SCG to be reactivated at SN106A as illustrated in Figures 4A - 4C. In other implementations, after 328A where the radio connection is suspended, UE102 does not retain the first SN configuration at all and releases the deactivated SCG.

[0060] In some implementations, the RRC suspend message is an RRCConnectionRelease or RRCRelease message for configuring the UE 102 to enter an idle state where the UE 102 is in an inactive state or a state where the radio connection is suspended. The RRC suspend message can include a SuspendConfig IE, an RRC-InactiveConfig-r15 IE, a ResumeIdentity-r13 IE, a fullI-RNTI-r16 field, or a shortI-RNTI-r16 field. In other implementations, the RRC release message is an RRCConnectionRelease or RRCRelease message.

[0061] The MN configuration (e.g., the first MN configuration and / or the second MN configuration) can include a plurality of configuration parameters for configuring radio resources such that the UE 102 communicates with the MN 104A via the PCell (e.g., cell 124A or a cell other than cell 124A) and zero, one, or more secondary cells (SCs) of the MN 104A. For example, the first MN configuration can include a PHY configuration, a MAC configuration, and / or an RLC configuration. In another example, the MN configuration can include one or more measurement configurations. The MN configuration can include one or more radio bearer configurations for configuring one or more radio bearers. The UE 102 can receive the plurality of configuration parameters from the MN 104A in one or more RRC messages.

[0062] In some implementations, the MN configuration includes configuration parameters within the RRCReconfiguration message, RRCReconfiguration-IEs, or the CellGroupConfig information element (IE) compliant with 3GPP TS 38.331. In one implementation, the MN configuration can be the RRCReconfiguration message, RRCReconfiguration-IEs, or the CellGroupConfig IE compliant with 3GPP TS 38.331. In other implementations, the MN configuration can include configuration parameters within the RadioResourceConfigDedicated IE, RRCConnectionReconfiguration message, or RRCConnectionReconfiguration-IEs. In one implementation, the MN configuration can be the RadioResourceConfigDedicated IE, RRCConnectionReconfiguration message, or RRCConnectionReconfiguration-IEs compliant with 3GPP TS 36.331.

[0063] The SN configuration (i.e., the first SN configuration or the additional SN configuration) can include a plurality of configuration parameters for configuring radio resources such that the UE 102 communicates with the SN 106A via the PSCell (e.g., cell 125A) and zero, one, or more SCell of the SN 106A. For example, the SN configuration can include a PHY configuration, a MAC configuration, and / or an RLC configuration. The SN configuration may or may not include a measurement configuration. In some implementations, the SN configuration may or may not include one or more radio bearer configurations (e.g., RadioBearerConfig, SRB-toAddMod, or DRB-toAddMod) that configure one or more radio bearers.

[0064] In some implementation forms, the SN configuration includes configuration parameters in the RRCReconfiguration message, RRCReconfiguration-IEs, or the CellGroupConfig IE compliant with 3GPP TS 38.331. In one implementation form, the SN configuration can be the RRCReconfiguration message, RRCReconfiguration-IEs, or the CellGroupConfig IE compliant with 3GPP TS 38.331. In other implementation forms, the SN configuration can include configuration parameters in the SCG-ConfigPartSCG-r12 IE. In some implementation forms, the SN configuration can be the RRCConnectionReconfiguration message, RRCConnectionReconfiguration-IEs, or the ConfigPartSCG-r12 IE compliant with 3GPP TS 36.331.

[0065] When MN104A is a gNB, the RRC reconfiguration message and the RRC reconfiguration complete message are the RRCReconfiguration message and the RRCReconfigurationComplete message, respectively. When MN104A is an eNB or an ng-eNB, the RRC reconfiguration message and the RRC reconfiguration complete message are the RRCConnectionReconfiguration message and the RRCConnectionReconfigurationComplete message, respectively.

[0066] Next, referring to FIG. 3B, scenario 300B is generally similar to scenario 300A, but rather than MN104A, SN106A determines to deactivate the SCG and (in some cases) then reactivate the SCG. As described above, events in scenario 300B that are similar to those described above for scenario 300A are labeled with similar reference numbers (e.g., event 302A in FIG. 3A corresponds to event 302B in FIG. 3B). Except for the differences shown in FIG. 3B and the differences described below, any of the alternative implementations described above for scenario 300A can be applied to scenario 300B (e.g., with respect to messaging and processing).

[0067] After event 302B, SN106A determines 307B that the SCG should be deactivated for communication with UE102. In some implementations, SN106A can determine 307B that data inactivity exists on the SCG for UE102 and, in response, determine that the SCG for UE102 should be deactivated. In one implementation, SN106A can detect that data inactivity exists for UE102 because SN106A has not received data packets to be sent from CN110 to UE102 and has not received data packets from UE102 over a predetermined time period.

[0068] In other implementation forms, SN106A should determine 307B that the SCG for UE102 should be deactivated based on the UE preference received by SN106A from UE102 via, for example, MN104A, or based on an SRB (for example, SRB3) configured by MN104A or SN106A to exchange RRC messages between UE102 and SN106A. For example, UE102 transmits 305B UE assistance information (for example, UE Assistance Information message) to SN106A, indicating that the UE currently prefers single connectivity for power saving or due to overheating. SN106A determines 307B that the SCG for UE102 should be deactivated by SN106A in response to the UE assistance information received in event 305B. In some implementation forms, SN106A receives 305B UE assistance information from UE102 via MN104A.

[0069] In response to determination 307B, SN106A transmits 309B a SN modification required message to SN106A requesting deactivation of the SCG for UE102. In response to the request to deactivate the SCG, MN104A transmits 314B an RRC reconfiguration message to UE102, similar to event 314A. UE102 deactivates 316B the SCG and transmits 318B an RRC reconfiguration complete message to MN104A in response to the RRC reconfiguration message received 314B by UE102, similar to events 316A and 318A respectively. After receiving 318B the RRC reconfiguration complete message, MN104A transmits 311B a SN modification confirmation message to SN106A indicating that UE102 has deactivated the SCG in response to the SN modification required message.

[0070] In some implementations, SN106A causes MN104A to transmit an RRC reconfiguration message to UE102 at 314B by including an indication (e.g., a field or information element (IE)) in the SN modification required message at 309B to deactivate the SCG. After determining at 307B that the SCG should be deactivated, SN106A deactivates the SCG at 322B. In some implementations, SN106A deactivates the SCG at 322B after receiving an SN modification confirmation message at 311B to reduce the chance of reactivation when UE102 detects an SCG failure while or prior to the SCG being deactivated. Events 305B, 307B, 309B, 311B, 314B, 316B, 318B, and 322B are collectively referred to as the SCG deactivation procedure 391B in FIG. 3B.

[0071] After the SCG deactivation procedure 391B, either receive an RRC reconfiguration complete message at 318B or send an SN modification confirmation message at 311B, and MN104A can perform an RRC suspend procedure 394B with UE102, similar to the RRC suspend procedure 394A.

[0072] Referring now to FIG. 3C, scenario 300C is generally similar to scenarios 300A and 300B, except here UE102 communicates directly with SN106A regarding the deactivation of the SCG. Except for the differences shown in FIG. 3C and described below, any of the alternative implementations described above for scenarios 300A and 300B can apply to scenario 300C (e.g., regarding messaging and processing).

[0073] In response to 307C determining that the SCG should be deactivated, SN106A generates an RRC message to deactivate the SCG and transmits an RRC reconfiguration message to UE102 on an SRB (e.g., SRB3) configured by MN104A or SN106A to exchange RRC messages between UE102 and SN106A 315C. In response thereto, UE102 deactivates the SCG 316C. Optionally, UE102 can transmit an RRC reconfiguration complete message to SN106A on the SRB 319C in response to the RRC reconfiguration message. Alternatively, SN106A transmits the RRC reconfiguration message to UE102 via MN104A 315C. UE102 can transmit an RRC reconfiguration complete message to SN106A via MN104A 319C.

[0074] In some implementations, if UE102 needs to transmit an RRC reconfiguration complete message, UE102 can transmit the RRC reconfiguration complete message 319C before or after deactivating the SCG 316C. In other implementations, SN106A deactivates the SCG 322C after determining to deactivate the SCG 307C or after transmitting the RRC reconfiguration message 315C. In yet other implementations, if UE102 transmits the RRC reconfiguration complete message 319C, SN106A deactivates the SCG 322C after receiving the RRC reconfiguration complete message 319C. In yet other implementations, SN106A deactivates the SCG 322C after receiving an acknowledgement message from UE102 acknowledging receipt of a PDU containing the RRC reconfiguration message. For example, the acknowledgement message can be an RLC acknowledgement PDU or a hybrid automatic repeat request (HARQ) acknowledgement.

[0075] In some implementations, after 307C which determines that SN106A should deactivate SCG, SN106A can send an SN modification required message to MN104A to obtain permission from MN104A to deactivate SCG. MN104A can send an SN modification confirmation message to SN106A indicating that MN104A permits SN106A to deactivate SCG at 311C. After obtaining the permission, SN106A transmits an RRC reconfiguration message to UE102 at 315C.

[0076] In other implementations, SN106A does not need permission from MN104A to deactivate SCG. After 307C which determines that SCG should be deactivated, SN106A can send an SN message (e.g., an SN modification required message, an SN deactivation notification message, or an X2 or Xn interface message) to MN104A indicating that SCG is deactivated. In one implementation, SN106A can send the SN message before or after transmitting the RRC reconfiguration message at 315C. In another implementation, SN106A can send the SN message before or after receiving the RRC reconfiguration complete message at 319C at 309C.

[0077] In some implementations, instead of an RRC reconfiguration message, SN106A can send a MAC control element (CE) to UE102 at 315C instructing UE102 to deactivate SCG. In such an implementation, in one implementation, UE102 may not need to transmit a MAC CE to SN106A in response to the MAC CE received by UE102 in event 315C. In another implementation, UE102 transmits another MAC CE to SN106A at 319C in response to the MAC CE received by UE102 in event 315C. Since there are fewer protocol layers involved, it is often faster to deactivate SCG using a MAC CE rather than an RRC reconfiguration message.

[0078] Events 305C, 307C, 309C, 311C, 315C, 316C, 319C, and 322C are collectively referred to as the SCG deactivation procedure 392C in FIG. 3C.

[0079] After the SCG deactivation procedure 392C, or after 309C that has received an SN message, or after 311C that has sent an SN correction confirmation message, MN104A can execute an RRC suspension procedure 394C with UE102, similar to the RRC suspension procedure 394A.

[0080] Referring next to FIG. 3D, scenario 300D is generally similar to scenarios 300A - C, but UE102 determines that it should deactivate the SCG. Except for the differences shown in FIG. 3D and the differences described below, any of the alternative implementations described above for scenarios 300A - C can be applied to scenario 300D (e.g., with respect to messaging and processing).

[0081] In DC, UE102 determines at 382D that UE102 should deactivate the SCG. For example, UE102 can determine at 382D that UE102 should deactivate the SCG based on the power level or thermal level in the UE, or based on whether UE102 has data to transmit via the SCG or expects to receive data via the SCG. In response to this determination, UE102 transmits a SCG deactivation command to SN106A on a SRB (e.g., SRB3) configured by MN104A or SN106A to exchange RRC messages between UE102 and SN106A at 384D. Alternatively, UE102 transmits a SCG deactivation command to SN106A via MN104A. SN106A deactivates the SCG in response to the SCG deactivation command at 322D. SN106A may transmit a SN message (e.g., SN modification required message, SN deactivation notification message, or X2 or Xn interface message) indicating that the SCG has been deactivated to MN104A at 375D. Events 382D, 384D, 316D, 322D, and 375D are collectively referred to as the SCG deactivation procedure 393D in FIG. 3D.

[0082] In some implementations, UE102 can transmit a MAC CE for deactivating the SCG to SN106A instead of a SCG deactivation command message at 384D. In such an implementation, in one implementation, SN106A may not need to transmit a MAC CE to UE102 in response to the MAC CE received by SN106A at event 384D. In another implementation, SN106A transmits another MAC CE to UE102 in response to the MAC CE received by SN106A at event 384D. Since there are fewer protocol layers involved, it is often faster to deactivate the SCG using a MAC CE rather than an RRC reconfiguration message.

[0083] After the SCG deactivation procedure 393D, or after 375D of receiving the SN deactivation notification message, MN104A can execute an RRC suspension procedure with UE102, similar to the RRC suspension procedure 394A.

[0084] Next, referring to FIG. 3E, scenario 300E is generally similar to scenarios 300A - D, but rather than configuring UE102 to enter the inactive state for each of the RRC suspension procedures 394A - D, MN104A determines that the SCG should be reactivated. Except for the differences shown in FIG. 3E and the differences described below, any of the alternative implementations described above for scenarios 300A - D can be applied to scenario 300E (e.g., with respect to messaging and processing).

[0085] While the UE 102 is in the DC with the MNs 104A and 106A during the event 302E, the UE 102 can execute a SCG deactivation procedure 390E, similar to the SCG deactivation procedures 390A, 391B, 392C, or 393D. After deactivating the SCG in the SCG deactivation procedure 390E, the MN 104A can decide 336E to reactivate the SCG for communication with the UE 102. In some implementations, the MN 104A can detect data activity on the SCG for the UE 102 and, in response, decide 336E to activate the SCG for the UE 102. For example, the MN 104A can decide that there is data activity for the UE 102 based on messages for the UE 102 received by the MN 104A from the SN 106A. As a more specific example, the SN 106A can detect data activity for the UE 102 and, in response, can send 332E an activity notification message with an active indication for the UE 102 to the MN 104A. The MN 104A can then detect data activity for the UE 102 based on the received activity notification message. In some implementations, the SN 106A can detect data activity for the UE 102 after receiving a data packet addressed to the UE 102 from the CN 110. In still other implementations, the MN 104A makes a decision 336E in response to receiving a sufficiently large amount of data for the UE 102 from the CN 110 or the SN 106A. For example, if the amount of data received by the MN 104A from the CN 110 or the SN 106A exceeds a specific pre-configured, predetermined, dynamic, or static threshold, the MN 104A decides that the amount of data is sufficiently large. In still other implementations, the MN 104A makes a decision 336E in response to receiving data associated with a specific QoS (flow) or a specific PDU session for the UE 102 from the CN 110 or the SN 106A.

[0086] In other implementation forms, MN104A may receive data packets that MN104A transmits to UE102 via SN106A, whereby MN104A may determine to activate the SCG in response to receiving the data packets. MN104A can transmit data packets to UE102 via MCG. In still other implementation forms, MN104A receives data packets for UE102 from SN106A, which causes MN104A to determine to activate the SCG. MN104A can transmit data packets to UE102 via MCG.

[0087] In yet other implementation forms, MN104A determines to activate the SCG for UE102 based on the UE preferences received by MN104A from UE102. For example, UE102 may send UE assistance information (e.g., UE Assistance Information message) indicating that UE102 (temporarily) prefers dual connectivity or has data to be transmitted on the SCG. MN104A determines to activate the SCG for UE102 in response to the UE assistance information received in event 334E.

[0088] In yet other implementation forms, MN104A determines to activate the SCG for UE102 based on one or more measurement results received from the UE. If the measurement result for cell 126A exceeds a first threshold and / or the measurement result for cell 125A is below a second threshold, MN104A may determine to activate the SCG for UE102. Alternatively, MN104A may refrain from activating the SCG even if the measurement result for cell 126A exceeds the first threshold and / or the measurement result for cell 125A (i.e., the current PSCell) is below the second threshold.

[0089] In response to decision 336E, MN104A sends a SN modification request message to SN106A to activate the SCG for UE102 at 338E. In response to the SN modification request message at 338E, SN106A sends a SN modification request confirmation response message to MN104A at 340E to activate the SCG at 342E. In some implementations, SN106A can include a second SN configuration in the SN modification request confirmation response message at 340E. In one implementation, SN106A includes in the second SN configuration a random access configuration for UE102 to perform a random access procedure by SN106A. In another implementation, using the second SN configuration, SN106A instructs UE102 not to perform a random access procedure if the corresponding time alignment timer is still running (i.e., the corresponding time alignment timer has not expired yet). In other implementations, SN106A does not include the SN configuration in the SN modification request confirmation response message that the SN transmits at 340E.

[0090] In some implementations, SN106A includes a CU (e.g., CU172) and a DU (e.g., DU174). As described with respect to FIG. 3A, when the DU suspends the lower layer for UE102, the CU can send a UE context request message (e.g., a UE context modification request message) including an instruction to resume the lower layer for UE102 after or in response to activating SCG 342E, receiving an SN modification request message to activate SCG 338E, or transmitting an SN modification request confirmation response message 340E. In response to the UE context request message, the DU resumes the lower layer for communication with UE102 and sends a UE context response message (e.g., a UE context modification response message) to the CU. In some implementations, the UE context request message to resume the lower layer and the UE context request message to suspend the lower layer include the same interface ID (e.g., F1AP ID) assigned by the CU and / or the DU. For example, the interface ID includes a CU F1AP ID assigned by the CU and / or a DU F1AP ID assigned by the DU.

[0091] As described with respect to FIG. 3A, when DU releases the lower layer for UE102, CU can send a UE context request message (e.g., UE context setup request message) to DU to (re)establish the lower layer for UE102 after or in response to having transmitted 340E or having received 338E with an SN modification request message for activating SCG or 342E with SCG activated. In response to the UE context request message, DU can (re)establish the lower layer for communicating with UE102 and send a UE context response message (e.g., UE context setup response message) to CU. The UE context request message for (re)establishing the lower layer and the UE context request message for suspending the lower layer can include the same or different interface IDs (e.g., F1AP ID) assigned by CU and / or DU. For example, the interface ID can include the CU F1AP ID assigned by CU and / or the DU F1AP ID assigned by DU.

[0092] In some implementations, MN104A does not include an instruction to activate SCG in the SN modification request message for event 338E. In other implementations, MN104A generates an instruction to activate SCG and includes the instruction in the SN modification request message for event 338E. In yet other implementations, MN104A generates an instruction to resume the lower layer and includes the instruction in the SN modification request message for event 338E. MN104A may include or omit an instruction to activate SCG in the SN modification request message for event 338E.

[0093] In response to decision 336E, and after 338E when MN104A transmits a SN modification request message, or after 340E when MN104A receives a SN modification request confirmation response message, MN104A transmits a RRC reconfiguration message at 344E that causes UE102 to activate the SCG. In response to the RRC reconfiguration message, UE102 activates the SCG for communication with SN106A at 346E and transmits a RRC reconfiguration complete message to MN104A at 348E. After receiving the RRC reconfiguration complete message at 348E, MN104A can send a SN message (e.g., a SN reconfiguration complete message or a SN modification confirmation message) indicating that UE102 has activated the SCG to SN106A at 350E.

[0094] In some implementations, MN104A can include an instruction to activate the SCG in the RRC reconfiguration message transmitted by MN104A. In other implementations, MN104A does not include an instruction to activate the SCG in the RRC reconfiguration message transmitted at 344E by MN104A because that instruction is inherent in the message.

[0095] In some implementations, UE102 includes a second RRC reconfiguration complete message in the RRC reconfiguration complete message transmitted at 348E by UE102 in response to receiving a second SN configuration. MN104A can include the second RRC reconfiguration complete message in the SN reconfiguration complete message so that SN106A can receive the second RRC reconfiguration complete message. When SN106A is a gNB, the second RRC reconfiguration complete message is a RRCReconfigurationComplete message. When SN106A is an ng-eNB, the second RRC reconfiguration complete message is a RRCConnectionReconfigurationComplete message.

[0096] After receiving the RRC reconfiguration message at 344E, or in response to the RRC reconfiguration message of 344E, UE102 can perform the random access procedure on SN106A and cell 126A at 352E to activate the SCG by SN106A. In some implementations, UE102 performs the random access procedure using one or more random access configurations in the second SN configuration in which the UE receives 344E. In other implementations, UE102 performs the random access procedure using one or more random access configurations received by UE102 from SN106A before activating or deactivating the SCG at 352E.

[0097] After UE102 successfully completes the random access procedure on SN106A and cell 126A at 352E, UE102 can transmit data (user plane data and / or control plane data) in DC with both MN104A and SN106A through cell 124A and cell 126A respectively at 354E. After identifying UE102 in the random access procedure, SN106A can transmit data (user plane data or control plane data) with UE102 according to the configuration parameters in the first SN configuration, additional SN configurations, and / or the second SN configuration at 354E. If the RRC reconfiguration message indicates that UE102 should not perform the random access procedure, UE102 skips the event at 352E and transmits data (user plane data and / or control plane data) in DC with both MN104A and SN106A through cell 124A and cell 126A respectively at 354E. In some implementations, SN106A can include an uplink configuration within the second SN configuration, and UE102 can transmit a transmission to SN106A via cell 126A according to the uplink configuration. For example, SN106A can configure an uplink grant in the uplink configuration, and UE102 can transmit a PUSCH transmission to SN106A via cell 126A according to the uplink grant.

[0098] In some implementations, UE102 communicates with MN104A and SN106A over DC and transmits scheduling requests (SRs), sounding reference signals (SRSs), and / or channel state information (CSI) on cell 126A to SN106A. In other implementations, SN106A can communicate with MN104A and SN106A over DC and transmit downlink assignments and / or uplink grants on the physical downlink control channel (PDCCH) to UE102. UE102 receives physical downlink shared channel (PDSCH) transmissions from SN106A via cell 126A according to the downlink assignment and / or uplink grant, and / or transmits physical uplink control channel (PUCCH) transmissions to SN106A.

[0099] In some implementations, SN106A can include new configuration parameters for the secondary cell group (SCG) in the second SN configuration. After activating the SCG, UE102 uses the new configuration parameters to communicate data (user plane data and / or control plane data) with SN106A. For example, the new configuration parameters can change the primary serving cell (PSCell), modify the current PSCell or secondary cell (SCell), release an SCell, or add a new SCell. In another example, the new configuration parameters can include configuration parameters for the operation of physical layer (PHY) 202A / 202B, medium access control (MAC) 204A / 204B, or radio link control (RLC) 206A / 206B. In other implementations, SN106A can indicate to release the configuration parameters included in the first SN configuration or an additional SN configuration in the second SN configuration. Thus, even if UE102 receives a release of the configuration parameters, UE102 does not use the released configuration parameters to communicate user plane data and / or control plane data with SN106A after activating the SCG. If the radio resource control (RRC) reconfiguration message received by UE102 does not include the SN configuration, UE102 uses the configuration parameters of the first SN configuration or the second SN configuration to communicate data with SN106A.

[0100] Events 332E, 334E, 336E, 338E, 340E, 342E, 344E, 346E, 348E, 350E, 352E, and 354E are collectively referred to as the SCG activation procedure 380E in FIG. 3E. Events 344E, 346E, 348E, 350E, 352E, and 354E are collectively referred to as the SCG activation procedure 370E in FIG. 3E.

[0101] The random access procedure can be, for example, a 4-step random access procedure or a 2-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 includes a UE identifier known to SN 106A within "Message 3" of the 4-step random access procedure or Message A of the 2-step random access procedure, whereby SN 106A can 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 a first SN configuration, an additional SN configuration, or a second 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 can assign a dedicated random access preamble in the second SN configuration.

[0102] In some implementations, SN106A activates the SCG 342E after or during the random access procedure with UE102. For example, SN106A can activate the SCG 342E in response to connecting to UE102 during the random access procedure. SN106A can determine that UE102 connects to SN106A in response to identifying UE102 during the random access procedure (e.g., based on the UE identifier or dedicated random access preamble received by SN106A from UE102 during the random access procedure). If the random access procedure is skipped, SN106A in other implementations can determine that UE102 connects to SN106A when SN106A receives PUSCH transmission, SR, SRS, or CSI from UE102.

[0103] In some implementations, after activating the SCG, SN106A resumes the lower layer to communicate with UE102. After resuming the lower layer, in one implementation, SN106A uses the lower layer to transmit downlink transmissions to UE102. After resuming the lower layer, in another implementation, SN106A uses the lower layer to receive uplink transmissions from UE102. Similarly, in some implementations, after activating the SCG, UE102 resumes the lower layer for communication with SN106A. After resuming the lower layer, in one implementation, UE102 transmits uplink transmissions to SN106A through the lower layer. After resuming the lower layer, in another implementation, UE102 uses the lower layer to receive downlink transmissions from SN106A, which can be similar to those described above.

[0104] In some implementations, SN106A deactivates the SCG in the SCG deactivation procedure 390E, or after activating the SCG in 342E, resets (or re-establishes) at least one lower layer. After resetting PHY202A / 202B or MAC204A / 204B, SN106A can set the NDI value associated with the HARQ process in PHY202A / 202B or MAC204A / 204B used by SN106A to communicate with UE102 to its initial value. For example, if SN106A uses the HARQ process to receive transmissions from UE102, SN106A sets the NDI value to its initial value after resetting PHY202A / 202B or MAC204A / 204B. In another example, if SN106A uses the HARQ process to transmit transmissions to UE102, SN106A sets the NDI value to an initial value of 0 or 1 after resetting PHY202A / 202B or MAC204A / 204B. After resetting PHY202A / 202B or MAC204A / 204B, SN106A can reset the beam failure instance indication counter (e.g., set the counter to an initial value such as 0 or a static value), and / or reset the listen-before-talk (LBT) counter (e.g., set the counter to an initial value such as 0 or a static value). After re-establishing RLC206A / 206B, SN106A sets the RLC variables in RLC206A / 206B to their initial values (e.g., 0 or a static value).

[0105] Similarly, UE102 can deactivate the SCG during the SCG deactivation procedure 390E, or reset (or re-establish) at least one lower layer after activating the SCG in 342E. After resetting PHY202A / 202B or MAC204A / 204B, UE102 sets the NDI value associated with the HARQ process in PHY202A / 202B or MAC204A / 204B used by UE102 to communicate with SN106A to its initial value. For example, if UE102 uses a HARQ process to transmit a transmission to SN106A, UE102 sets the NDI value to the initial value of 0 after resetting PHY202A / 202B or MAC204A / 204B. In another example, if UE102 uses a HARQ process to receive a transmission from SN106A, UE102 flushes the soft buffer for the HARQ process and / or considers the next received transmission for the transport block as the first transmission after activating the SCG after resetting PHY202A / 202B or MAC204A / 204B. After resetting PHY202A / 202B or MAC204A / 204B, UE102 can reset the beam failure instance indication counter (e.g., set the counter to an initial value such as 0 or a static value) and / or reset the listen-before-talk (LBT) counter (e.g., set the counter to an initial value such as 0 or a static value). After resetting MAC204A / 204B, UE102 can initialize the appropriate variables for the logical channels to zero for logical channel prioritization. After re-establishing RLC206A / 206B, UE102 sets the RLC variables in RLC206A / 206B to their initial values (e.g., 0 or a static value) as specified in 3GPP TS 36.322 or 3GPP TS 38.322.

[0106] In another implementation, after deactivating the SCG in the SCG deactivation procedure 390E, SN106A retains operation information in at least one lower layer for communication with UE102. After activating the SCG in 342E, SN106A can continue to use the operation information in at least one lower layer for communicating with UE102. For example, the operation information includes the NDI value associated with the HARQ process of PHY202A / 202B or MAC204A / 204B used by SN106A to communicate with UE102 and / or the RLC variables (i.e., the values of the variables) in RLC206A / 206B. After deactivating the SCG in the SCG deactivation procedure 390E, SN106A can retain the NDI value and / or RLC variables within RLC206A / 206B. The RLC variables can conform to 3GPP TS 36.322 or 3GPP TS 38.322.

[0107] Similarly, UE102 retains operation information in at least one lower layer for communication with SN106A after deactivating the SCG in the SCG deactivation procedure 390E or suspending the lower layer. After activating the SCG in 346E, UE102 can continue to use the operation information in at least one lower layer for communicating with SN106A. For example, the operation information includes the NDI value associated with the HARQ process of PHY202A / 202B or MAC204A / 204B used by UE102 to communicate with SN106A and / or the RLC variables (i.e., the values of the variables) in RLC206A / 206B. After deactivating the SCG in the SCG deactivation procedure 390E, UE102 can retain the NDI value and / or RLC variables within RLC206A / 206B.

[0108] In some implementations, after deactivating the SCG in the SCG deactivation procedure 390E, SN106A suspends PDCP208 / 210 and / or SDAP212 for communication with UE102. Similarly, after deactivating the SCG in the SCG deactivation procedure 390E, UE102 suspends PDCP208 / 210 and / or SDAP212 for communication with SN106A. In other implementations, after deactivating the SCG in the SCG deactivation procedure 390E, SN106A does not suspend PDCP208 / 212 and / or SDAP210. Similarly, after deactivating the SCG in the SCG deactivation procedure 390E, UE102 does not suspend PDCP208 / 210 and / or SDAP212 for communication with SN106A.

[0109] In some implementations, SN106A deactivates the SCG in the SCG deactivation procedure 390E, or re - establishes (or resets) PDCP208 / 210 and / or SDAP212 after activating the SCG in 342E. In other implementations, SN106A refrains from re - establishing (or resetting) PDCP208 / 210 and / or SDAP212 after deactivating the SCG in the SCG deactivation procedure 390E, or after activating the SCG in 342E. In some implementations, SN106A deactivates the SCG in the SCG deactivation procedure 390E, or sets the RDCP variables TX_NEXT, RX_NEXT, and / or RX_DELIV to their initial values (e.g., 0 or default or static values) after activating the SCG in 342E. Similarly, UE102 sets the PDCP variables TX_NEXT, RX_NEXT, and / or RX_DELIV to their initial values (e.g., 0 or default or static values) after deactivating the SCG in the SCG deactivation procedure 390E, or after activating the SCG in 346E. In some implementations, SN106A deactivates the SCG in the SCG deactivation procedure 390E, or resets the header compression protocol / context or data compression protocol / context after activating the SCG in 342E. Similarly, UE102 resets the header compression protocol / context or data compression protocol / context after deactivating the SCG in the SCG deactivation procedure 390E, or after activating the SCG in 346E.

[0110] In other implementations, after deactivating SCG in 322A, SN106A retains operation information in PDCP208 / 210 or SDAP212 for communication with UE102. After activating SCG in 342E, SN106A can continue to use the operation information to communicate with UE102. Similarly, after deactivating SCG in 316A, UE102 retains operation information in PDCP208 / 210 or SDAP212 for communication with SN106A. After activating SCG in 346E, UE102 can continue to use the operation information to communicate with SN106A. In some implementations, the operation information may include PDCP variable (values) and / or Quality of Service (QoS) flow information. For example, PDCP variables may include TX_NEXT, RX_NEXT, and / or RX_DELIV as specified in 3GPP specification 38.323. In another example, QoS flow information includes the identity / identifier of the QoS flow, the mapping rule from the QoS flow to the DRB, and / or the mapping rule from the Service Data Flow (SDF) to the QoS flow. In other implementations, the operation information may include a header compression protocol / context or a data compression protocol / context.

[0111] In some implementations, after deactivating SCG in the SCG deactivation procedure 390E, SN106A stops and / or resets the reordering timer (e.g., t-Reordering). After performing header decompression, SN106A can deliver all PDCP SDUs stored in ascending order of the associated COUNT value to the upper layer (e.g., SDAP) or CN110. Similarly, after deactivating SCG in the SCG deactivation procedure 390E, UE102 stops and / or resets the reordering timer (e.g., t-Reordering). After performing header decompression, SN106A can deliver all PDCP SDUs stored in ascending order of the associated COUNT value to the upper layer (e.g., SDAP) or CN110.

[0112] The operation information in the protocol layer (e.g., PHY202A / 202B, MAC204A / 204B, RLC206A / 206B, PDCP208 / 210, or SDAP212) may or may not include configuration parameters for operating the protocol layer in the first SN configuration or the additional SN configuration.

[0113] In some implementations, SN106A releases one or more configuration parameters in the first SN configuration after or in response to an event in the SCG deactivation procedure 390E (e.g., event 310A, 320A of receiving an SN modification request message or an SN message as described in FIG. 3A, event 312A of transmitting an SN modification request confirmation response message, or event 322A of deactivating the SCG). Therefore, after releasing the configuration parameters, SN106A can allocate wireless resources configured with the configuration parameters to other UEs. Similarly, UE102 releases configuration parameters after or in response to an event in the SCG deactivation procedure 390E (e.g., event 314A of receiving an RRC reconfiguration message, event 316A of deactivating the SCG, or event 318A of transmitting an RRC reconfiguration complete message). In one implementation, the configuration parameters can include a field or IE indicating the maximum uplink power that UE102 can use for transmission to SN106A. UE102 limits the uplink transmission towards SN106A so as not to exceed the maximum uplink power indicated by the field or IE. For example, the field can include p-NR-FR1 that constitutes the maximum total transmission power that UE102 can use in frequency range 1 (FR1) across all serving cells of SN106A (i.e., PSCell and SCell). In another example, the field can include p-NR-FR2 that constitutes the maximum total transmission power that UE102 can use in frequency range 2 (FR2) across all serving cells of SN106A (i.e., PSCell and SCell).In yet another example, a field or IE can include a PUCCH or channel state information (CSI) resource configuration (e.g., pucch-CSI-ResourceList or PUCCH-CSI-Resource), a scheduling request resource configuration (e.g., SchedulingRequestResourceConfig), and / or a sounding reference signal (SRS) resource (e.g., SRS-Resources). In yet another example, a field or IE includes parameters within a ReconfigurationWithSync IE, excluding the spCellConfigCommon field within the ReconfigurationWithSync IE. In yet another example, the configuration parameter can be a parameter indicating a time division multiplexing pattern, such as a tdm-PatternConfig-r15 field or a tdm-PatternConfig-r16 field in a scenario with NE-DC or NR-DC.

[0114] In another implementation form, SN106A retains one or more configuration parameters in the first SN configuration after or in response to an event in the SCG deactivation procedure 390E (for example, event 310A, 320A of receiving an SN correction request message or an SN message as described in FIG. 3A, event 312A of transmitting an SN correction request confirmation response message, or event 322A of deactivating the SCG). Similarly, UE102 retains configuration parameters after or in response to an event in the SCG deactivation procedure 390E (for example, after or in response to event 314A of receiving an RRC reconfiguration message, event 316A of deactivating the SCG, or event 318A of transmitting an RRC reconfiguration complete message). At a later point in time, SN106A and UE102 can communicate with each other using the retained configuration parameters after activating the SCG, as described with respect to FIGS. 3E to 4C. The configuration parameters include a plurality of configuration parameters, PHY configuration, MAC configuration, RLC configuration, measurement configuration, and / or radio bearer configuration, as described below. For example, the configuration parameters can include at least one radio network temporary identifier (RNTI). The at least one RNTI includes a C-RNTI, a configured scheduling RNTI (CS-RNTI), and / or a modulation and coding scheme (MCS) RNTI, SRS, PUCCH, and / or transmission power control (TPC) RNTI for PUSCH, a semi-persistent CSI RNTI, and / or a power saving RNTI. In another example, the configuration parameters include a field or IE indicating the maximum uplink power that UE102 can use to transmit to SN106A as described above. In yet another example, the configuration parameters exclude a field or IE indicating the maximum uplink power that UE102 can use to transmit to the SN as described above.

[0115] In some implementations, MN104A releases one or more configuration parameters in a first MN configuration after or in response to an event in the SCG deactivation procedure 390E (e.g., event 308A that determines that the SCG should be deactivated, as described in FIG. 3A, event 310A, 314A, 320A that transmits an SN correction request message, an RRC reconfiguration message, or an SN message, or event 312A, 318A that receives an SN correction request confirmation response message, an RRC reconfiguration message). Similarly, UE102 releases configuration parameters in the first MN configuration after or in response to an event in the SCG deactivation procedure 390E (e.g., event 314A that receives an RRC reconfiguration complete message, event 316A that deactivates the SCG, or event 318A that transmits an RRC reconfiguration complete message, as described in FIG. 3A). For example, the configuration parameter may indicate the maximum uplink power that UE102 can use to transmit to MN104A and / or SN106A. UE102 limits the uplink transmission to MN104A or SN106A so as not to exceed the maximum uplink power indicated by the configuration parameter. In a scenario involving EUTRA / NR DC (EN-DC) or NG-RAN EUTRA / NR DC (NGEN-DC), the configuration parameter may be a p-MaxEUTRA field having a P-Max value. As another example, one of the configuration parameters may indicate the maximum uplink power that UE102 can use to transmit to MN104A and SN106A across serving cells (e.g., across both the master cell group and the secondary cell group) across all cell groups for a particular frequency range. UE102 limits the uplink transmission to MN104A and SN106A across serving cells and across all cell groups for a particular frequency range so as not to exceed the maximum uplink power indicated by the configuration parameter.In a scenario with EN-DC or NGEN-DC, the configuration parameter may be a p-MaxUE-FR1 field having a P-Max value. As a further example, one of the configuration parameters may indicate a time instance at which a UE in MR-DC is allowed to transmit to MN104A or SN106A. UE102 restricts uplink transmission towards MN104A or SN106A according to the indicated time instance. For example, the configuration parameter may be a parameter indicating a time division multiplexing (TDM) pattern, such as the tdm-PatternConfig-r15 field or the tdm-PatternConfig-r16 field in a scenario with EN-DC or NGEN-DC. Before releasing the parameter indicating the TDM pattern, MN104A communicates with UE102 according to the TDM pattern. After releasing the configuration parameter, MN104A communicates with UE102 without using the configuration parameter. Similarly, UE102 communicates with MN104A according to the configuration parameter before releasing the configuration parameter. After releasing the configuration parameter, UE102 communicates with MN104N without using the configuration parameter.

[0116] In some implementations, MN104A releases one or more configuration parameters in the first MN configuration and suspends using the retained configuration parameters after or in response to an event in the SCG deactivation procedure 390E (e.g., event 308A that determines that the SCG should be deactivated, as described in FIG. 3A, event 310A, 314A, 320A that transmits an SN modification request message, an RRC reconfiguration message or an SN message, or event 312A, 318A that receives an SN modification request confirmation response message, an RRC reconfiguration message). Similarly, UE102 retains the configuration parameters in the first MN configuration after or in response to an event in the SCG deactivation procedure 390E (e.g., event 314A that receives an RRC reconfiguration complete message, event 316A that deactivates the SCG, or event 318A that transmits an RRC reconfiguration complete message, as described in FIG. 3A). At a later time, MN104A and UE102 can communicate with each other using the retained configuration parameters after activating the SCG or entering the connected state, as described with respect to FIGS. 3E-4C. The configuration parameters include a plurality of configuration parameters, PHY configuration, MAC configuration, RLC configuration, measurement configuration, and / or radio bearer configuration, as described below. For example, the configuration parameters can include at least one radio network temporary identifier (RNTI). The at least one RNTI includes a cell RNTI (C-RNTI), a configured scheduling RNTI (CS-RNTI), and / or a modulation and coding scheme (MCS) RNTI, SRS, PUCCH and / or PUSCH transmission power control (TPC) RNTI, semi-persistent CSI RNTI, and / or a power saving RNTI. In another example, the configuration parameters include a parameter indicating the maximum uplink power that UE102 can use to transmit to MN104A and / or SN106A, as described above, and / or a parameter indicating a time division multiplexing pattern.In another example, the configuration parameter excludes a parameter indicating the maximum uplink power that can be used by the UE 102 to transmit to the MN 104A and / or the SN 106A as described above, and / or a parameter indicating a time-division multiplexing pattern.

[0117] The MN 104A and the SN 106A can include at least one interface ID of the UE 102 in a message transmitted between the MN 104A and the SN 106A, as described above. For example, the MN 104A can include the interface ID in an SN modification request message transmitted by the MN 104A in events 310A and 338E, in an SN message transmitted by the MN 104A in event 326A, in an SN modification required message transmitted by the SN 106A in events 309B and 309C, in an SN modification confirmation message transmitted by the MN 104A in events 311B and 311C, in an SN deactivation notification message transmitted by the SN 106A in event 375D, and / or in an SN message transmitted by the MN 104A in event 350E. The SN 106A can include the interface ID in an SN modification request confirmation response message transmitted by the SN 106A in events 312A and 340E.

[0118] In some implementations, MN104A includes a third MN configuration in the RRC reconfiguration message that MN104A transmits 344E. In this case, UE102 communicates with MN104A using the third MN configuration. In some implementations, MN104A generates the third MN configuration as a delta MN configuration that enhances only a portion of the first MN configuration and / or the second MN configuration (when transmitted to UE102). Thus, UE102 communicates with MN104A using the delta MN configuration and a portion of the first MN configuration and / or the second MN configuration that is not enhanced by the delta MN configuration 354E. In other implementations, MN104A does not include the third MN configuration in the RRC reconfiguration message that MN104A transmits 344E. Exemplary implementations of the third MN configuration are similar to the first and second MN configurations described in FIG. 3A.

[0119] Exemplary implementations of the second SN configuration are similar to the first SN configuration and / or an additional MN configuration. In some implementations, SN106A can configure the same or different serving cells (i.e., PSCell and / or 0, 1, or a plurality of SCell) in the second SN configuration as the first SN configuration or an additional SN configuration. In some implementations, the second SN configuration can be a complete self - contained configuration (i.e., a complete SN configuration). UE102 can use the complete SN configuration to communicate with SN106A without depending on the first SN configuration and / or an additional SN configuration. In other implementations, SN106A generates the second SN configuration as a delta SN configuration that enhances only a portion of the first SN configuration and / or an additional SN configuration. Thus, UE102 communicates with SN106A using the delta SN configuration and a portion of the first SN configuration and / or an additional SN configuration that is not enhanced by the delta SN configuration 354E. In yet other implementations, SN106A includes only a random access configuration in the second SN configuration such that UE102 communicates with SN106A 354E using the first SN configuration and / or an additional SN configuration.

[0120] When MN104A is a gNB, the RRC reconfiguration message and the RRC reconfiguration complete message are the RRCReconfiguration message and the RRCReconfigurationComplete message, respectively. When MN104A is an eNB or an ng-eNB, the RRC reconfiguration message and the RRC reconfiguration complete message are the RRCConnectionReconfiguration message and the RRCConnectionReconfigurationComplete message, respectively.

[0121] Figures 4A to 4C are exemplary message sequences similar to Figures 3A to 3E, but UE102 performs the RRC resume procedure with MN104A and the SCG activation procedure with SN106A during or after the execution of the RRC resume procedure. Therefore, the events in the scenarios shown in Figures 4A to 4C and the similar scenarios described with respect to Figures 3A to 3E are labeled with similar reference numbers (for example, event 402A is similar to event 302A or 302B, etc.). Except for the differences shown in the figures and described below, any of the alternative implementations described above with respect to scenarios 300A to E can be applied to scenarios 400A to C (for example, with respect to messaging and processing).

[0122] Referring first to Figure 4A, scenario 400A is generally similar to scenario 300A. Therefore, at the start of scenario 400A, UE102 communicates with MN104A according to the first MN configuration and with SN106A according to the first SN configuration, like events 302A to E, at 402A. While UE102 in DC is communicating with MN104A and SN106A at event 402A, UE102, MN104A, and / or SN106A perform an SCG deactivation procedure 490A, similar to the SCG deactivation procedures 390A, 391B, 392C, 393D, or 390E.

[0123] After event 490A, MN104A executes RRC suspend procedure 494A with UE102 (accompanied by SN106A in some cases), which is similar to RRC suspend procedures 394A - D. UE102 suspends the radio connection with MN104A as a result of the RRC suspend procedure. After suspending the radio connection, UE102 can execute an RRC resume procedure to transition from an inactive or idle state to a connected state, for example, in response to a decision to start data transmission with base station 104A or in response to a paging message received from base station 104A. Since UE102 can send an RRC resume request message to base station 104A via cell 124A at 404A, base station 104A can configure UE102 to operate in the connected state again and can operate as an MN with respect to UE102. After or in response to the RRC resume request message, MN104A can decide at 406A to keep SCG deactivated for UE102 and can transmit an RRC resume message to UE102 at 408A. In response to decision 406A, MN104A does not attempt to obtain the SN configuration from SN106A. Thus, the RRC resume message does not include the SN configuration. In response to the RRC resume message, UE102 enters the connected state at 410A and transmits an RRC resume completion message to MN104A at 412A. After or during transmitting the RRC resume completion message, UE102 communicates with MN104A at 414A. In some implementations, MN104A can include in the RRC resume message an instruction to UE102 to continue keeping SCG deactivated. Thus, UE102 holds the (enhanced) first SN configuration (or holds some components in the (enhanced) first SN configuration) and / or holds SCG deactivated in response to the instruction, similar to the description for FIG. 3A.

[0124] In some implementations, MN104A makes determination 406A according to the first resume cause within the RRC resume request 404C. For example, the first resume cause can be emergency, highPriorityAccess, mo-Signalling, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update, mps-PriorityAccess or mcs-PriorityAccess. In other implementations, MN104A makes determination 406A when the paging message is for a (IMS) mobile that terminates a voice call or a video call. In still other implementations, MN104A receives from SN106A an SN message indicating data activity for UE102. For example, the SN message can be an activity notification message. MN104A makes determination 406A in response to the indication of data activity for UE102. In yet other implementations, MN104A makes determination 406A in response to receiving a relatively small amount of data for UE102 from CN110 or SN106A. For example, if the amount of data that MN104A receives from CN110 or SN106A is below a specific pre-configured, predetermined, or static threshold, MN104A determines that the amount of data is small and determines that it is insufficient to reactivate the SCG as such.

[0125] If the first resume cause is rna-Update, in some implementations, MN104A can transmit a RRC suspend message (similar to the RRC suspend message in RRC suspend procedure 494A) to UE102 in response to a RRC resume request instead of a RRC resume message. In response to the RRC suspend message, UE102 remains in the idle state with the non-active state or the radio connection suspended, and does not transmit a RRC response message. In some implementations, UE102 keeps the SCG as non-activated in response to the RRC suspend message. In other implementations, MN104A can indicate to UE102 to release the SCG in the RRC suspend message, and UE102 releases the SCG in response thereto.

[0126] In some implementations, MN104A can also include an MN configuration (i.e., the third MN configuration) in the RRC resume message transmitted by MN104A in event 408A, in which case UE102 communicates with MN104A using the MN configuration 414A. In one implementation, MN104A can generate the third MN configuration as a complete MN configuration that completely replaces the first MN configuration and / or the second MN configuration that UE102 can receive in event 490A. Thus, UE102 can communicate with MN104A using the complete MN configuration 414A. In another implementation, MN104A generates the third MN configuration as a delta MN configuration that enhances only a part of the first MN configuration and / or the second MN configuration. Thus, UE102 communicates with MN104A using the delta MN configuration and a part of the first MN configuration and / or the second MN configuration that is not enhanced by the delta MN configuration 414A. Exemplary implementations of the third MN configuration are similar to the first or second MN configuration.

[0127] In other implementations, MN104A may not include the MN configuration in the RRC resume message. In this case, UE102 communicates with the MN using the first MN configuration and / or the second MN configuration 414A.

[0128] After event 414A, UE 102, MN 104A, and SN 106A may execute SCG activation procedure 480A to activate the SCG, similar to SCG activation procedure 380E. After UE 102 and RAN 105 activate the SCG, they can communicate data on the SCG. Activating the SCG is faster compared to the case where MN 104A initially configures base station 106A as the SN. In this way, the waiting time for setting up the SCG is reduced.

[0129] In some implementations where MN 104A is a gNB, the RRC resume request message, RRC resume message, and RRC resume complete message can be the RRCResumeRequest message, RRCResume message, and RRCResumeComplete message. In other implementations where MN 104A is an eNB or ng-eNB, the RRC resume request message, RRC resume message, and RRC resume complete message can be the RRCConnectionResumeRequest message, RRCConnectionResume message, or RRCConnectionResumeComplete message.

[0130] Referring next to Figure 4B, scenario 400B involves an SCG activation procedure after the RRC resume procedure. Events in scenario 400B that are similar to those described above for scenario 400A are labeled with similar reference numbers (e.g., event 402A in Figure 4A corresponds to event 402B in Figure 4B). Except for the differences shown in Figure 4B and described below, any of the alternative implementations described above for scenario 400A can be applied to scenario 400B (e.g., with respect to messaging and processing).

[0131] After event 414B, SN106A can determine 437B that it should activate the SCG for communication with UE102. In some implementations, SN106A can determine that there is data activity on the SCG for UE102 and, in response, determine 437B that it should activate the SCG for UE102. In one implementation, when SN106A receives a data packet to be sent from CN110 to UE102, SN106A can detect that there is data activity for UE102.

[0132] In other implementations, SN106A can determine 437B that it should activate the SCG for UE102 based on UE preferences received by SN106A from UE102 via MN104A. For example, UE102 can send 433B UE assistance information (e.g., UE Assistance Information message) indicating that UE102 (temporarily) prefers dual connectivity or has data to be transmitted on the SCG to MN104A. In response, MN104A can send 435B the UE assistance information to SN106A. SN106A can determine 437B that it should activate the SCG for UE102 in response to the UE assistance information received in event 435B.

[0133] In yet another implementation, SN106A has a 437B that determines that SN106A should activate the SCG for UE102 based on one or more measurement results received from the UE via MN104A. If the measurement result for cell 126A exceeds a first threshold and / or the measurement result for cell 125A (i.e., the current PSCell) is below a second threshold, SN106A can determine that it should activate the SCG for UE102. Thus, SN106A can change the PSCell from cell 125A to cell 126A by activating the SCG 442B. Alternatively, SN106A can refrain from activating the SCG even if the measurement result for cell 126A exceeds the first threshold and / or the measurement result for cell 125A (i.e., the current PSCell) is below the second threshold.

[0134] In response to the determination 437B, SN106A sends a SN modification required message to MN104A that requests MN104A to activate the SCG for UE102 439B. In response to the request to activate the SCG, MN104A performs an RRC SCG activation procedure with UE102 and SN106A, similar to the RRC SCG activation procedures 370E or 380E 480B. UE102 activates the SCG as a result of the RRC SCG activation procedure 480B.

[0135] In some implementations, SN106A causes MN104A to transmit an RRC reconfiguration message that activates an SCG similar to event 344E by including an indication (e.g., a field or information element (IE)) to activate the SCG in the SN modification required message of 439B. After 437B determines to activate the SCG, SN106A activates the SCG at 442B. In some implementations, after MN104A receives an RRC reconfiguration complete message similar to event 348E from UE102, MN104A sends an SN modification confirmation message similar to event 350E to SN106A. SN106A activates the SCG at 442B before or after receiving the SN modification confirmation message.

[0136] Referring now to FIG. 4C, scenario 400C involves an SCG activation procedure during the execution of an RRC resume procedure. Events in scenario 400C that are similar to those described above for scenarios 400A - B are labeled with similar reference numbers (e.g., event 402A in FIG. 4A and event 402B in FIG. 4B correspond to event 402C in FIG. 4C). Except for the differences shown in FIG. 4C and described below, any of the alternative implementations described above for scenarios 400A - B may apply to scenario 400C (e.g., with respect to messaging and processing).

[0137] After event 490C, MN104A executes RRC suspension procedure 494C with UE102, with or without SN106A, which is similar to RRC suspension procedures 394A - D. In response to receiving RRC resume request message 404C, MN104A decides 405C to activate SCG for UE102 rather than maintaining it as deactivated as shown in FIGS. 4A and 4B. In some implementations, MN104A makes decision 405C according to the second resume reason in RRC resume request 404C. For example, the second reason can be mo - Data. In other implementations, MN104A makes decision 405C when the paging message is not for a mobile that ends a voice call or a video call (IMS). In yet other implementations, MN104A receives from SN106A an SN message indicating data activity for UE102 or activating SCG. For example, the SN message can be an activity notification message or an SN modification required message. MN104A makes decision 405C in response to an indication indicating data activity for UE102 or an indication indicating activation of SCG. In still other implementations, MN104A makes decision 406A in response to receiving (a large amount of) data for UE102 from CN110. For example, if the amount of data that MN104A receives from SN106A exceeds a pre - configured, predetermined, or static threshold, MN104A decides that the amount of data is large.

[0138] In response to the decision 405C, MN104A can send a SN modification request message to activate the SCG to SN106A at 430C. In response to receiving the SN modification request message, SN106A sends a SN modification request confirmation response message including a second SN configuration to MN104A at 432C. In some implementations, SN106A generates the second SN configuration as a complete self - contained configuration (i.e., a complete SN configuration). In other implementations, SN106A generates the second configuration as a delta SN configuration. The delta SN configuration includes only a subset of the configuration parameters, i.e., only the configuration parameters that SN106A has changed with respect to the first SN configuration and / or additional SN configurations.

[0139] After receiving the SN modification request confirmation response message at 432C and in response to the RRC resume request message, MN104A sends an RRC resume message including the second SN configuration to UE102 at 409C. If the second SN configuration is a complete SN configuration, MN104A includes a release and add indication (e.g., mrdc - ReleaseAndAdd or endc - ReleaseAndAdd) in the RRC resume message. If the second SN configuration is a delta SN configuration, MN104A does not include a release and add indication in the RRC resume message. If MN104A includes a complete MN configuration in the RRC resume message, MN104A can include a complete configuration indicator in the RRC resume message. In this case, MN104A may not need to include a release and add indication in the RRC resume message when the second SN configuration is a complete SN configuration.

[0140] In response to the RRC resume message, UE 102 resumes the suspended radio connection with MN 104A, transitions to the connected state 410C, and activates the SCG 446C. After resuming the suspended radio connection, UE 102 can transmit, in response to the RRC resume message, an RRC resume completion message that may include an RRC reconfiguration completion message to MN 104A 413C. After receiving the RRC resume completion message 413C, MN 104A can send a SN reconfiguration completion message indicating to SN 106A that UE 102 has successfully received or applied the second SN configuration to SN 106A 450C. In one implementation, MN 104A can include the RRC reconfiguration completion message from the RRC resume completion message in the SN reconfiguration completion message. In some implementations, SN 106A activates the SCG for UE 102 442C after receiving a SN modification request message 430C, transmitting a SN modification request confirmation response message 430C, or receiving a SN reconfiguration completion message 450C.

[0141] Following reception of the second SN configuration by 409C or activation of SCG by 446C, UE 102 can perform a random access procedure with SN 106A on cell 126A, e.g., using one or more random access configurations in the second SN configuration at 452C, to connect to SN 106A. After UE 102 successfully completes the random access procedure on cell 126A, UE 102 can transmit data (user plane data and / or control plane data) in DC communication with both MN 104A and SN 106A through cell 126A, e.g., by using the first, additional, or second SN configuration at 454C. After identifying UE 102 during the execution of the random access procedure, SN 106A can transmit data (user plane data or control plane data) in communication with UE 102 according to the first SN configuration or the second SN configuration received by UE 102 in event 409C at 454C. If the RRC resume message includes a release and addition indication, UE 102 communicates with SN 106A at 454C by using the second SN configuration without the first SN configuration. If the RRC resume message does not include a release and addition indication, UE 102 transmits data in communication using the configuration parameters in the second SN configuration and the first SN configuration not enhanced by the second SN configuration at 454C. In some implementations, SN 106A can activate SCG for UE 102 at 442C after identifying UE 102 during the execution of a random access procedure, which may be a two-step or four-step procedure and contention-based or contention-free procedure as described above. SN 106A can allocate a dedicated random access preamble in the second SN configuration in some cases.

[0142] MN104A and SN106A can include at least one interface ID of UE102 in a message transmitted between MN104A and SN106A, as described above. For example, MN104A can include the interface ID in the SN modification request message transmitted by MN104A in events 490C and 430C, and in the SN reconfiguration completion message transmitted by MN104A in event 450C. SN106A can include the interface ID in the SN modification request confirmation response message transmitted by SN106A in events 490C and 432C. In another example, SN106A can include the interface ID in the SN modification required message or the SN deactivation notification message at event 490C. MN104A can include the interface ID in the SN modification request message transmitted by MN104A in event 430C and in the SN reconfiguration completion message transmitted by MN104A at transmission 450C. SN106A can include the interface ID in the SN modification request confirmation response message transmitted by SN106A in event 432C.

[0143] In some implementations, MN104A can include an instruction to re-establish the lower layer in the SN correction request message 430C, and SN106A can allocate lower layer resources to communicate with UE102 in response to the instruction to re-establish the lower layer. The resources can include, for example, software, firmware, memory resources, and / or processing capabilities used to implement the functions of the PHY202A / 202B, MAC204A / 204B, and / or RLC206A / 206B layers for SN106A to communicate with UE102. SN106A can allocate processing capabilities from the ASIC, DSP, and / or CPU of SN106A to communicate with UE102. In some implementations, MN104A determines to include an instruction to re-establish the lower layer for UE102 in the SN correction request message 430C based on, for example, MN104A indicating to SN106A that MN104A released the lower layer in the SN request message in the RRC suspend procedure 494C, similar to event 326A. In other implementations, MN104A determines to include an instruction to re-establish the lower layer for UE102 in the SN correction request message 430C based on MN104A determining to release a first SN configuration before, during, or in response to UE102 transitioning to the connected state (e.g., before starting the RRC resume procedure, during the execution of the RRC resume procedure, or in response thereto). In some of these latter implementations, MN104A determines that UE102 releases the first SN configuration based on the first UE capability of UE102. The first UE capability can indicate that UE102 cannot (e.g., does not immediately delete) hold an SN configuration (in this case, an SCG configuration) after starting the RRC resume procedure. MN104A can receive the first UE capability from the core network 110 (e.g., AMF164 or MME114) or another base station, or can receive the UE capability in a UECapabilityInformation message from UE102 in event 402C.In yet another implementation, SN106A may not be able to maintain the first SN configuration while the UE102 deactivates the SCG, or may not be able to reuse some of the configurations of the first SN configuration after the UE102 activates the SCG. For example, SN106A may be able to release the first SN configuration in response to an SN request message in the RRC suspend procedure 494C. In such an implementation, regardless of whether MN104A can maintain the first SN configuration before the UE102 transitions to the connected state, MN104A includes an instruction in the SN modification request message 430C to re-establish the lower layer for the UE102 based on the determination that SN106A releases the first SN configuration or does not reuse a part of the first SN configuration.

[0144] In some implementations, after receiving the RRC resume message at 409C (e.g., in response thereto), UE 102 releases the first SN configuration. However, in other implementations, UE 102 may release the first SN configuration at another time (e.g., in response to the RRC suspend message in the RRC suspend procedure instead of retaining the first SN configuration) or after transmitting the RRC resume request message at 404C. In some implementations, after receiving the RRC suspend message in the RRC suspend procedure 494C, UE 102 retains the radio bearers configured by MN 104A and / or SN 106A, and MN 104A and / or SN 106A can release or modify one or more of the radio bearers in the RRC resume message transmitted at event 409C, thereby causing UE 102 to appropriately release or modify the radio bearers. For example, MN 104A can include one or more radio bearer configurations (e.g., RadioBearerConfig information elements) in the RRC resume message to release, add, or modify one or more radio bearers, thereby causing UE 102 to appropriately release, add, or modify the radio bearers. MN 104A can receive one or more radio bearer configurations from SN 106A and include the one or more radio bearer configurations in the RRC resume message.

[0145] In other implementations, MN104A can include, in the SN modification request message 430C, an indication that, similar to event 338E, together with UE102, the lower layer should resume, instead of a command for SN106A to re-establish the lower layer. In some implementations, MN104A includes, in the SN modification request message 430C, a command to resume the lower layer of UE102 based on the fact that MN104A has indicated to SN106A that MN104A deactivates the SCG in the SCG deactivation procedure 490C (similar to event 310A) or suspends the lower layer in the SN request message in the RRC suspend procedure 494 (similar to event 326A). In other implementations, MN104A determines to include, in the SN modification request message 430C, a command to re-establish the lower layer for UE102 based on the fact that MN104A has determined that UE102 should maintain the first SN configuration before, during, or in response to (e.g., before starting the RRC resume procedure, during the execution of the RRC resume procedure, or in response to it) the transition of UE102 to the connected state. In some of these latter implementations, MN104A determines that UE102 should maintain the first SN configuration based on the second UE capability of UE102 or based on the fact that MN104A does not receive the first UE capability for UE102. The second UE capability may indicate that UE102 can maintain (e.g., not immediately delete) the SN configuration (i.e., the SCG configuration) after starting the RRC resume procedure. MN104A may receive the second UE capability from the core network 110 (e.g., AMF164 or MME114) or another base station, or may receive the second UE capability from UE102 in the UECapabilityInformation message in event 402C. In still other implementations, SN106A can maintain the first SN configuration while UE102 deactivates the SCG, or some configurations of the first SN configuration cannot be reused after UE102 activates the SCG. For example, SN106A can maintain the first SN configuration in response to the SN request message in the RRC suspend procedure 494C.In such an implementation form, regardless of whether MN104A can maintain the first SN configuration before UE102 transitions to the connected state, based on the determination by MN104A that SN106A does not maintain the first SN configuration or does not reuse a part of the first SN configuration, an instruction to resume the lower layer is included in the SN modification request message 430C for UE102.

[0146] In some implementation forms, SN106A can generate the second SN configuration as a complete SN configuration in response to an instruction to re - establish the lower layer. In still other implementation forms, MN104A includes a complete configuration request (for example, a complete configuration IE) in the SN modification request message, and SN106A generates the second SN configuration as a complete SN configuration according to the complete configuration request, regardless of an instruction to re - establish the lower layer or an instruction to suspend the lower layer.

[0147] In some implementation forms, SN106A can generate the second SN configuration as a delta SN configuration in response to an instruction to resume the lower layer. In still other implementation forms, MN104A includes a delta configuration request (for example, a delta configuration IE) in the SN modification request message or excludes the complete configuration request, and SN106A generates the second SN configuration as a delta SN configuration according to the delta configuration instruction or the SN modification request message excluding the delta configuration instruction.

[0148] In some implementation forms, when SN106A generates the second SN configuration as a complete SN configuration, SN106A may or may not include an indication in the SN modification request confirmation response message indicating that the second SN configuration is a complete SN configuration. If the SN modification request confirmation response message does not include the indication, MN104A can determine that the second SN configuration is a complete SN configuration according to the UE capabilities or the determination that SN106A cannot maintain the first SN configuration.

[0149] Figures 5A - 5B are exemplary message sequences similar to Figures 3A - 3D, except that a portion of a single base station acts as both the MN and the SN. Thus, events in the scenarios shown in Figures 5A - 5B, which are similar to those described with respect to Figures 3A - 3D, are labeled with similar reference numbers. Except for the differences shown in the figures and described below, any of the alternative implementations described above with respect to Scenarios 300A - 300C and 300D can apply (e.g., with respect to messaging and processing) to Scenarios 500A and 500B, respectively. As one exemplary difference, the MN and SN of Figures 5A - 5B do not need to exchange SN modification requests and SN modification request confirmation responses, as in Figures 3A - 3D.

[0150] Referring to FIG. 5A, in scenario 500A, base station 106A operates as both an MN and an SN. The MN includes a CU (e.g., CU 172) and a first DU of base station 106A (e.g., DU 174A of one or more DUs 174, referred to herein as M-DU 174A), and the SN includes the same CU and a second, different DU of base station 106A (e.g., DU 174B of one or more DUs 174, referred to herein as S-DU 174B). Scenario 500A is generally similar to scenarios 300A - 300C, except that here a single base station 106A includes both an MN and an SN. RRC messages (e.g., as described below) transmitted by the CU to a DU (i.e., the first DU or the second DU) may be included in F1AP messages (e.g., DL RRC message transfer messages or UE context request messages) transmitted by the CU to the DU. The first DU or the second DU can transmit to the CU an F1AP message (e.g., an initial UL RRC message transfer message, a UL RRC message transfer message, or a UE context request confirmation response message) including the RRC message. Thus, at the start of scenario 500A, UE 102 communicates with CU 172 over DC with M-DU 174A according to a first M-DU configuration, with S-DU 174B according to a first S-DU configuration, and with M-DU 174A and S-DU 174B having a first CU configuration at 502A. Then, MN 104A determines to deactivate the SCG for communication with UE 102, similar to event 308A, 307B, or 307C at 508A.

[0151] In response to decision 508A, CU 172 transmits to M-DU 174A an RRC reconfiguration message to deactivate the SCG for UE 102 at 514A-1. M-DU 174A then transmits the RRC reconfiguration message to UE 102 at 514A-2, similar to event 314A. In response to the RRC reconfiguration message at 514A-2, UE 102 deactivates the SCG at 516A and transmits an RRC reconfiguration complete message to M-DU 174A at 518A-1, similar to events 316A and 318A respectively. M-DU 174A then transmits the RRC reconfiguration complete message to CU 172 at 518A-2, similar to event 318A.

[0152] In some implementations, CU 172 may obtain additional S-DU configurations from S-DU 174B by performing a UE context modification procedure with S-DU 174B. The additional S-DU configurations are similar to the additional SN configurations described with respect to FIG. 3A. CU 172 includes the additional S-DU configurations in the RRC reconfiguration message 514A-1. In some implementations, S-DU 174B generates the additional S-DU configurations as delta DU configurations that enhance only a portion of the first S-DU configuration. Thus, UE 102 enhances only a portion of the first S-DU configuration with the delta DU configuration and retains a portion of the first S-DU configuration that is not enhanced by the delta DU configuration. In other implementations, S-DU 174B generates the additional S-DU configurations as a complete self-contained configuration (i.e., a complete DU configuration). UE 102 replaces the first S-DU configuration with the additional S-DU configuration. In yet other implementations, CU 172 does not include a DU configuration in the RRC reconfiguration message 514A-1.

[0153] Alternatively, in response to decision 508A, CU 172 transmits an RRC reconfiguration message to S-DU 174B at 514A-1, and S-DU 174B then transmits the RRC reconfiguration message to UE 102 at 514A-2. In response to the RRC reconfiguration message at 514A-2, UE 102 deactivates the SCG at 516A and transmits an RRC reconfiguration complete message to S-DU 174B at 518A-1, similar to events 315C and 319C respectively. Then, S-DU 174A transmits the RRC reconfiguration complete message to CU 172 at 518A-2, similar to event 319C.

[0154] After or in response to making decision 508A, transmitting the RRC reconfiguration at 514A-1, or receiving the RRC reconfiguration complete message at 518A-2, CU 172 transmits a UE context request message to M-DU 174A to deactivate the SCG at 572A. In response to the UE context request message, M-DU 174A deactivates the SCG at 522A and transmits a UE context response message to CU 172 at 574A. DU 174 may transmit the UE context response message at 574A before or after deactivating the SCG.

[0155] In some implementations, CU172 may also include a second MN configuration in the RRC reconfiguration message that CU172 transmits 514A-1. In this case, after receiving the RRC reconfiguration message 514A-2, UE102 communicates with CU172 and / or M-DU174A using the second MN configuration. The second MN configuration may include a second CU configuration and / or a second M-DU configuration. In some implementations, CU172 may obtain the second M-DU configuration from M-DU174A before generating the second MN configuration. In some implementations, CU172 generates the second MN configuration as a delta MN configuration that enhances only a portion of the first CU configuration and / or the first M-DU configuration. Thus, UE102 communicates with CU172 and / or M-DU174A using the delta MN configuration and the portion of the first CU configuration and / or the first M-DU configuration that is not enhanced by the delta MN configuration. In other implementations, CU172 and / or M-DU174A do not include the second MN configuration in the RRC reconfiguration message that CU172 and / or M-DU174A transmit 514A-1, 514A-2.

[0156] After deactivating the SCG, CU172 determines 524A to configure UE102 to enter the inactive state or the idle state with the radio connection suspended. In response to the determination 524A, CU172 transmits 526A a UE context request message to S-DU174B, which causes S-DU174B to release or suspend the lower layers for communicating with UE102.

[0157] In response to decision 524A, CU172 sends an RRC suspend message to M-DU174A, similar to event 328A, at 528A-1, and M-DU174A then sends the RRC suspend message to UE102 at 528A-2. UE102 enters the inactive state in response to the RRC suspend message, similar to event 330A, at 530A. In response to the RRC suspend message, UE102 suspends the radio connection with CN172 and / or M-DU174A, retains the first M-DU configuration or a part of the M-DU configuration, and retains the first CU configuration. Events 502A, 506A, 508A, 514A-1, 516A, 518A-1, 518A-2, 572A, 522A, 574A are collectively referred to as the SCG deactivation suspend procedure 590A in FIG. 5A.

[0158] In some implementations, the UE context request message can be a UE context release command message. CU172 sends a UE context release command message to S-DU174B at 526A, which causes S-DU174B to release the lower layers for communicating with UE102. In response to the UE context release command message, S-DU174B releases the lower layer resources for communicating with UE102. These resources can include software, firmware, memory resources, and / or processing capabilities used to implement the functions of the PHY202A / 202B, MAC204A / 204B, and / or RLC206A / 206B layers for S-DU174B to communicate with the UE. For example, S-DU174B can release the processing capabilities from the ASIC, DSP, and / or CPU of S-DU174B allocated for communicating with UE102. In scenario 500A, S-DU174B also releases or alternatively releases the first S-DU configuration in response to the UE context release command message. S-DU174B sends a UE context release complete message to CU172 in response to the UE context release command message 526A.

[0159] In other implementation forms, the UE context request message may be a UE context modification request message. The CU 172 can send 526A a UE context modification request message including an instruction to suspend the lower layer for communicating with the UE 102 to the S-DU 174B. As a response, the S-DU 174B suspends the lower layer, similar to Event 326A. After suspending the lower layer, the S-DU 174B transmits a UE context modification response message to the CU 172 in response to the UE context modification request message 526A.

[0160] An exemplary implementation form of the second MN configuration is as described with respect to FIG. 3A. In some implementation forms, the CU configuration (i.e., the first CU configuration and / or the second CU configuration) can include at least one radio bearer configuration (e.g., RadioBearerConfig, SRB-toAddMod, or DRB-toAddMod), at least one measurement configuration (e.g., MeasConfig or CSI-MeasConfig), and / or other configurations (e.g., OtherConfig). In some implementation forms, the DU configuration (i.e., the first M-DU configuration, the first S-DU configuration, and / or the second M-DU configuration) can include a cell group configuration (e.g., CellGroupConfig).

[0161] Next, referring to FIG. 5B, in scenario 500B, base station 106A operates as both an MN and an SN. The MN includes a CU (e.g., CU172) and a first DU of base station 106A (e.g., DU174A of one or more DUs 174, referred to herein as M-DU174A), and the SN includes the same CU and a second, different DU of base station 106A (e.g., DU174B of one or more DUs 174, referred to herein as S-DU174B). Scenario 500B is generally similar to scenario 500A, but CU172 determines that UE 102 decides to release the first S-DU configuration. Scenario 500B is also generally similar to scenario 300D, but differs in that base station 106A includes both an MN and an SN.

[0162] Accordingly, after 582B when UE 102 decides to deactivate the SCG, UE 102 transmits an SCG deactivation command to S-DU174B 584B-1 and forwards this SCG deactivation command to CU172 584B-2. In response to or after receiving the SCG deactivation command, CU172 can send a UE context request message to S-DU174B that causes S-DU174B to deactivate the SCG 522B 572B. S-DU174B can send a UE context response message to CU172 in response to the UE context request 574B. Events 582B, 584B-1, 584B-2, 572B, 516B, 522B, and 574B are collectively referred to as the SCG deactivation procedure 593B in FIG. 5B. After deactivating the SCG 522B, CU172 can execute an RRC suspension procedure with UE 102 that is similar to the RRC suspension procedure 594A 594B.

[0163] Figures 6A - 6B are exemplary message sequences similar to Figures 4A - 4C, except that the components of a single base station act as the MN and SN. Thus, events in the scenarios shown in Figures 6A - 6B, which are similar to those described with respect to Figures 4A - 4C, are labeled with similar reference numbers (e.g., events 602A, 602B correspond to events 402A - 402C). Except for the differences shown in the figures and described below, any of the alternative implementations described above with respect to scenarios 400A - 400B and 400C can apply (e.g., with respect to messaging and processing) to scenarios 600A and 600B respectively. As one exemplary difference, the MN and SN of Figures 6A - 6B do not need to exchange SN modification requests and SN modification request confirmation responses, SN modification needed, and SN reconfiguration complete messages as in Figures 4A - 4C.

[0164] Referring initially to FIG. 6A, in scenario 600A, base station 106A operates as both an MN and an SN. The MN includes a CU (e.g., CU172) and a first DU of base station 106A (e.g., DU174A of one or more DUs 174, referred to herein as M-DU174A), and the SN includes the same CU and a second, different DU of base station 106A (e.g., DU174B of one or more DUs 174, referred to herein as S-DU174B). Scenario 600A is generally similar to scenarios 400A - 400B, except that a single base station 106A includes both an MN and an SN. Thus, at the start of scenario 600A, UE 102 communicates with CU 172 via M-DU174A according to a first M-DU configuration, S-DU174B according to a first S-DU configuration, and M-DU174A and S-DU174B having a first CU configuration, in the same way as events 402A - 402B and 502A, 602A for DC communication. While UE 102 in DC communicates with M-DU174A and S-DU174B and communicates with CU 172 in event 602A, UE 102, CU 172, M-DU174A, and / or S-DU174B execute an SCG deactivation procedure 690A, similar to SCG deactivation procedures 590A or 593B.

[0165] After event 690A, CU172 can execute an RRC resume procedure with UE102 via M-DU174A, with or without S-DU174B, similar to the RRC suspend procedure 594A. In response to the RRC suspend procedure, UE102 enters an inactive state or an idle state in which the radio connection is suspended. At a later time, UE102, which is in an inactive state or an idle state in which the radio connection is suspended, can execute an RRC resume procedure with CU172 via M-DU174A. During the execution of the RRC resume procedure 686A, UE102 transmits an RRC resume request message to M-DU174A 604A-1, and M-DU174A then transmits the RRC resume request message to CU172 604A-2. After receiving the RRC resume request message 604A-2 or in response thereto, CU172 decides to continue deactivating the SCG 606A and transmits an RRC resume message to M-DU174A 608A-1. Then, M-DU174A transmits the RRC resume message to UE102 608A-2. In response to the decision 606A, CU172 does not include the SN configuration in the RRC resume message. In response to the RRC resume message, UE102 enters the connected state 610A and transmits an RRC resume completion message to M-DU174A 612A-1. Then, M-DU174A transmits the RRC resume completion message to CU172 612A-2.

[0166] In some implementations, in response to receiving the RRC resume request message or after receiving it, CU172 transmits a UE context request message (e.g., a UE context setup request message) to M-DU174A, and M-DU174A transmits a UE context response message (e.g., a UE context setup response message) including a third M-DU configuration to CU172 in response to the UE context request message. Similar to the third MN configuration, CU172 can include the third M-DU configuration in the RRC resume message. After receiving the third M-DU configuration, UE102 communicates with M-DU174A using the third M-DU configuration.

[0167] After the RRC resume procedure, CU 172, 104A can determine 636A to activate the SCG for communication with UE 102, similar to event 336E. In some implementations, CU 172 can determine 636A to activate the SCG for UE 102 in response to determining that there is data activity on the SCG for UE 102. For example, CU 172 can detect that there is data activity for UE 102 based on a message for UE 102 received by CU 172 from M-DU 174A. In other implementations, CU 172 makes a determination 636A in response to receiving (a large amount of) data for UE 102 from CN 110. For example, if the amount of data received by CU 172 from SN 106A exceeds a preconfigured, predetermined, or static threshold, MN 104A determines that the amount of data is large. In yet other implementations, CU 172 makes a determination 636A in response to receiving data associated with a specific QoS (flow) or a specific PDU session (e.g., the first QoS (flow) or the first PDU session) for UE 102 from CN 110. In such implementations, CU 172 does not make a determination 636A in response to receiving data associated with a second QoS (flow) or a second PDU session for UE 102 from CN 110.

[0168] In response to the decision 636A, the CU 172 sends a UE context request message (e.g., a UE context setup request message or a UE context modification request message) to the S-DU 174B 676A to activate the SCG for the UE 102. The CU 172 may or may not include an indication to activate the SCG in the UE context request message. In response to the UE context request message, the S-DU 174B can send a UE context response message including a second S-DU configuration to the CU 172. Next, the CU 172 sends an RRC reconfiguration message including the second S-DU configuration to the M-DU 174A 644A-1 to activate the SCG. Then, the M-DU 174A transmits the RRC reconfiguration message to the UE 102 644A-2. Events 644A-1 and 644A-2 are similar to event 344E. In response to the RRC reconfiguration message received by the UE 644A-2, the UE activates the SCG 646A and transmits an RRC reconfiguration complete message 648A-1 to the M-DU 174A, similar to events 346E and 348E respectively. Then, the M-DU 174A transmits the RRC reconfiguration complete message to the CU 172 648A-2, similar to event 348E.

[0169] Subsequent to receiving the RRC reconfiguration message at 644A, or in response to the RRC reconfiguration message at 644A, the UE 102 can perform a random access procedure on cell 126A together with S-DU 174B to activate the SCG in accordance with, for example, the random access configuration in the second S-DU configuration, similar to event 352E at 652A. After the UE 102 has successfully completed the random access procedure with S-DU 174B on cell 126A at 652A, the UE 102 can transmit data (user plane data and / or control plane data) in DC through communication with both M-DU 174A and S-DU 174B respectively through cells 125A and 126A at 654A. After identifying the UE 102 in the random access procedure, S-DU 174B can transmit data (user plane data or control plane data) through communication with the UE 102 in accordance with the configuration parameters in the first S-DU configuration, additional S-DU configuration, and / or second S-DU configuration, similar to event 354E at 654A.

[0170] Referring next to FIG. 6B, the base station 106A in scenario 600B includes a CU 172, an M-DU 174A, and an S-DU 174B. Different from the scenario in FIG. 6A, this scenario includes the CU 172 making a decision to activate the SCG before the UE 102 enters the connected state. In this regard, scenario 600B is generally similar to scenario 400C, except that here, the MN and SN are components of the same base station.

[0171] After CU172 makes the decision 605B to activate the SCG (for reasons similar to those described with reference to event 405C above), CU172 can, in some cases, retrieve (set up) the UE context from S-DU174B (events 676B and 678B) (or together with it), and in some cases, from M-DU174A (events 662B and 664B) (or together with it). S-DU174B can provide the second S-DU configuration to CU172 678B, and CU172 can then send a RRC resume message containing the second S-DU configuration to M-DU174A to activate the SCG 609B-1. Then, M-DU174A transmits the RRC resume message containing the second S-DU configuration to UE102 609B-2. Events 609B-1 and 609B-2 are generally similar to event 409C in Figure 4C. In some implementations, M-DU174A can provide a third M-DU configuration to CU172 664B, and CU172 can include the third M-DU configuration in the RRC resume message as described for Figure 6A.

[0172] In response to receiving the RRC resume message 609B-2, UE102 enters the connected state 610B and transmits an RRC resume complete message to M-DU174A 611B-1. Then, M-DU174A transmits the RRC resume complete message to CU172 611B-2. After entering the connected state 610B, UE102 can perform random access procedures with S-DU174B similar to the random access procedure 652A. UE102 can then communicate with M-DU174A and S-DU174B over DC 654B.

[0173] Next, some exemplary methods for managing the SCG and MN connections in one or more RAN nodes or UEs will be described with reference to FIGS. 7A-23. Each of these methods can be implemented using processing hardware such as one or more processors configured to execute instructions stored on a non-transitory computer-readable medium. For clarity, the methods that can be implemented at the MN are described below with reference to MN104A, the methods that can be implemented at the UE are described below with reference to UE102, and the methods that can be implemented at the RAN (e.g., one or more network nodes such as MN104A or SN106A) are described below with reference to RAN105.

[0174] Referring first to FIGS. 7A and 7B, an exemplary method of notifying the UE of the deactivation of the SCG can be implemented at a network node, such as a base station or DU, operating as an MN for a UE communicating in dual connectivity.

[0175] Methods 700A and 702B each begin at block 702A or 702B, where the MN communicates with the UE to support the DC function with the MN and the SN (e.g., events 302A-302E, 402A-402E, 502A-502B, 602A-602B). At block 704A, the MN determines that the SCG of the SN should be deactivated for the UE while the UE and the MN are communicating (e.g., event 308A). The MN can make this determination based on, for example, whether data packets are arriving from the CN, whether data packets are arriving for a particular QoS or PDU session, the amount of data addressed to the UE, etc. On the other hand, at block 704B (see FIG. 7B), MN104A receives a notification of the deactivation of the SCG from SN106A (e.g., event 309B).

[0176] Next, in block 706A or 706B, the MN determines whether there is data activity on the MCG of the MN. When the MN determines that the UE has data activity on the MCG, the MN transmits, in block 708A or 708B, an SCG deactivation command to deactivate the SCG to the UE (e.g., event 314A, 314B, 514A). Otherwise, when the MN determines that the UE does not have data activity on the MCG, the flow proceeds to block 710A or 710B, where the MN transmits an RRC suspend message to the UE to suspend the radio connection with the MN (e.g., event 328A, 528A).

[0177] Next, FIG. 8 is a flowchart of an exemplary method 800 for deactivating the SCG, in accordance with which the MN determines whether to transmit a message to the SN to suspend or release the lower layer for communication with the UE based on whether the SCG is currently active. In block 802, the MN communicates with the UE to support DC operation (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). Next, in block 804, the MN determines that the radio connection with the UE 102 should be suspended (e.g., event 324A, 524A). The MN determines, in block 806, whether the UE and / or the RAN has already deactivated the SCG. If the SCG is active, the MN transmits, in block 810, an SN modification request message to the SN to suspend or release the lower layer for communication with the UE. If the SCG has been deactivated, the MN refrains from transmitting an SN modification request message to the SN106A in block 808. In block 812, the MN transmits an RRC suspend message to the UE.

[0178] Figure 9 illustrates another exemplary method 900 for deactivating or activating the SCG. According to method 900, the MN selects a message to be sent to the UE considering whether the UE is active on the SCG and further on the MCG. Method 900 starts from block 902, where the MN communicates with the UE to support DC operation (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). At block 904, while communicating with the UE, the MN sends an SCG deactivation command to the UE to deactivate the SCG of the SN (e.g., events 314A, 314B, 514A). Then, at block 906, the MN determines whether the UE has data activity on the SCG (based on messages from the SN, messages from the UE, data packets from the CN, etc.).

[0179] If the MN determines that there is data activity on the SCG, the flow proceeds to block 908, where the MN sends an SCG activation command to the UE to activate the SCG (e.g., events 344E, 409C, 644A, 609B). However, if the MN determines that there is no data activity on the SCG, the flow proceeds to block 910, where the MN determines whether the UE has data activity on the MCG (e.g., based on incoming data packets from the CN to the UE, QoS of the data packets, amount of data).

[0180] When the MN detects data activity on the MCG, the MN maintains the radio connection with the UE102 at block 912. Otherwise, when the MN determines that there is no data activity on the MCG, the MN sends an RRC suspend message to the UE to suspend the radio connection between the MN and the UE at block 914 (e.g., events 328A, 528A).

[0181] Referring now to FIG. 10, an exemplary method 1000 for deactivating or activating the SCG can be implemented at the UE. Method 1000 begins at block 1002, where the UE communicates with the MN and the SN using a first configuration (the "first MN configuration") and a second configuration (the "first SN configuration"), respectively (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B).

[0182] In some implementations, the first MN configuration can relate to the MCG and include one or more parameters for at least one serving cell of the MN, and the first SN configuration can include one or more parameters for at least one serving cell of the SN. At block 1004, the UE deactivates the SCG 1004 while continuing to communicate with the MN (e.g., events 316A, 316B, 516A). At block 1006, the UE releases the first configuration 1006 and retains the second configuration.

[0183] Next, FIG. 11 shows a flow diagram of an exemplary method 1100 that is similar to method 1000 of FIG. 10, where the UE first communicates with the MN using the first and second configurations (or the first and second parts of the MN configuration) and with the SN using a third configuration (or the SN configuration), and then activates (or re - activates) the deactivated SCG before applying the first configuration to the MN.

[0184] More specifically, in block 1102, the UE communicates with the MN using the first and second parts of the MN configuration and with the SN using the SN configuration. In block 1104, the UE deactivates the SCG while continuing to communicate with the MN. However, the UE retains at least a portion of the SN configuration in block 1106. In block 1108, the UE stops using the first part of the MN configuration. In some implementations, the UE only suspends the use of the first part of the MN configuration in block 1106 and does not discard the first part. In other implementations, the UE releases (or discards) the first part in block 1106.

[0185] In some implementations, after deactivating the SCG in block 1104, the UE continues to communicate with the MN using the second part of the MN configuration in block 1110. The UE 102 can then activate (or reactivate) the previously deactivated SCG while continuing to communicate with the MN (e.g., event 346E, 646A) in block 1112. In block 1114, the UE can continue to communicate with the MN using the first part of the MN configuration. Alternatively, after (re)activating the deactivated SCG, the UE does not use the first part of the MN configuration to communicate with the MN. In block 1116, the UE continues to communicate with the MN using the second part of the MN configuration. In some implementations, after activating the deactivated SCG, the UE can use at least a portion of the SN configuration to communicate with the SN. In some implementations, after activating the deactivated SCG, the UE can use the SN configuration to communicate with the SN.

[0186] Figure 12A is a flowchart of an exemplary method 1200, according to which a UE receives an RRC message indicating SCG deactivation and determines whether to retain some or all of the MN configuration depending on whether the message indicates RRC suspend or RRC reconfiguration. In particular, at block 1202A, the UE communicates with the MN using a first portion of the MN configuration and a second portion of the MN configuration, and communicates with the SN using the SN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B).

[0187] At block 1204A, the UE receives an RRC message from the MN to deactivate the SCG and, in response, deactivates the SCG (e.g., events 314A, 316A, 314B, 316B, 514A, 516A, 328A, 528A). The UE determines at block 1206A whether the received RRC message is related to RRC suspend or reconfiguration. In response to determining that the RRC message is an RRC suspend message, the UE releases a first portion of the MN configuration and retains a second portion of the MN configuration at block 1208A. Otherwise, if the UE determines that the RRC message is an RRC reconfiguration message, the UE retains both portions of the MN configuration at block 1210A.

[0188] Figure 12B is a flowchart of an exemplary method 1200B, according to which a UE receives an RRC message indicating SCG reactivation and determines whether to retain some or all of the MN configuration depending on whether the message is related to resuming an RRC connection or resuming RRC reconfiguration.

[0189] In block 1202B, the UE communicates with the MN using a first part of the MN configuration and a second part of the MN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). In block 1204B, the UE receives an RRC message from the MN to activate the SCG and, in response, (re)activates the SCG (e.g., events 344E, 346E, 409C, 446C, 644A, 646A, 609B). In block 1206B, the UE determines whether the received RRC message is related to resuming an RRC connection or an RRC re - configuration. In response to determining that the RRC message is an RRC resume message, the UE, in block 1208B, releases a first part of the MN configuration and retains a second part of the MN configuration. Otherwise, if the UE determines that the RRC message is an RRC re - configuration message, the UE, in block 1210B, retains both parts of the MN configuration.

[0190] FIG. 12C illustrates a flowchart of another exemplary method 1200C, in accordance with which the UE receives an RRC message indicating SCG de - activation. According to method 1200C, the UE determines whether to retain some or all of the MN configuration depending on whether the message indicates that the UE should suspend the MN connection.

[0191] At block 1202C, the UE communicates with the MN using the first part of the MN configuration and the second part of the MN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). At block 1204C, the UE receives an RRC message from the MN to deactivate the SCG and, in response, deactivates the SCG (e.g., events 314A, 316A, 314B, 316B, 514A, 516A, 328A, 528A). At block 1206C, the UE determines whether the received RRC message requires the UE to suspend the MN connection. If so, the flow proceeds to block 1208C, or determines whether the received RRC message does not require the UE to suspend the MN connection. If so, the flow proceeds to block 1210C. The UE releases the first part of the MN configuration and retains the second part of the MN configuration at block 1208C. On the other hand, at block 1210C, the UE retains both parts of the MN configuration.

[0192] Referring now to FIG. 13A, the UE receives an RRC message indicating SCG deactivation by an exemplary method 1300A and determines whether to retain some or all of the SN configuration depending on whether the message is related to RRC suspend or RRC reconfiguration. More specifically, at block 1302A, the UE communicates with the MN using the MN configuration and communicates with the SN using the first part of the SN configuration and the second part of the SN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B).

[0193] In block 1304A, the UE receives an RRC message from the MN to deactivate the SCG, and in response, deactivates the SCG (e.g., event 314A, 316A, 314B, 316B, 514A, 516A, 328A, 528A). In block 1306A, the UE determines whether the received RRC message is related to RRC suspend or reconfiguration. In response to determining that the RRC message is an RRC suspend message, the UE releases the first part of the SN configuration and retains the second part of the SN configuration in block 1308A. Otherwise, if the UE determines that the RRC message is an RRC reconfiguration message, the UE retains both parts of the SN configuration in block 1310A.

[0194] Figure 13B is a flowchart of an exemplary method 1300B, according to which the UE receives an RRC message indicating SCG reactivation and determines whether to retain some or all of the SN configuration depending on whether the message is related to resuming RRC connection or RRC reconfiguration. In block 1302B, the UE communicates with the MN using the MN configuration and communicates with the SN using the first part of the SN configuration and the second part of the SN configuration (e.g., event 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B).

[0195] In block 1304B, the UE receives an RRC message from the MN to activate the SCG, and in response, (re)activates the SCG (e.g., event 344E, 346E, 409C, 446C, 644A, 646A, 609B). In block 1306B, the UE determines whether the received RRC message is related to resuming RRC connection or RRC reconfiguration. In response to determining that the RRC message is an RRC resume message, the UE releases the first part of the SN configuration and retains the second part of the SN configuration in block 1308B. Otherwise, if the UE determines that the RRC message is an RRC reconfiguration message, the UE retains both parts of the MN configuration in block 1310B.

[0196] Figure 13C illustrates a flowchart of another exemplary method 1300C, according to which the UE receives an RRC message indicating SCG deactivation. According to method 1300C, the UE determines whether to retain some or all of the SN configuration depending on whether the message indicates that the UE should suspend the MN connection.

[0197] In block 1302C, the UE communicates with the MN using the MN configuration and communicates with the SN using the first part of the SN configuration and the second part of the SN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). In block 1304C, the UE receives an RRC message from the MN to deactivate the SCG and, in response, deactivates the SCG (e.g., events 314A, 316A, 314B, 316B, 514A, 516A, 328A, 528A). In block 1306C, the UE determines whether the received RRC message requires the UE to suspend the MN connection, in which case the flow proceeds to block 1308C, or determines whether the received RRC message does not require the UE to suspend the MN connection, in which case the flow proceeds to block 1310C. In block 1308C, the UE releases the first part of the SN configuration and retains the second part of the SN configuration. On the other hand, in block 1310C, the UE retains both parts of the SN configuration.

[0198] Next, FIG. 14A is a flowchart of an exemplary method 1400A according to which a UE receives an RRC message indicating SCG deactivation and determines whether to reset or retain operation information used in at least one lower layer of the radio connection with the SN depending on whether the message is related to RRC suspend or RRC reconfiguration. At block 1402A, the UE communicates with the MN and the SN (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). Next, at block 1404A, the UE receives an RRC message from the MN to deactivate the SCG and deactivates the SCG in response (e.g., events 314A, 316A, 314B, 316B, 514A, 516A, 328A, 528A).

[0199] At block 1406A, the UE determines whether the RRC message is related to RRC suspend or RRC reconfiguration. When the UE determines that the RRC message is an RRC suspend message, the flow proceeds to block 1408A and the UE resets at least one lower layer for communication with the SN. Otherwise, when the UE determines that the RRC message is an RRC reconfiguration message, the flow proceeds to block 1410A and the UE retains operation information used in at least one lower layer for communication with the SN.

[0200] Figure 14B illustrates a flowchart of another exemplary method 1400B, according to which the UE receives an RRC message indicating SCG reactivation and determines whether to reset or retain the operation information used in at least one lower layer of the radio connection with the SN depending on whether the message indicates RRC resume or RRC reconfiguration. In particular, at block 1402B, the UE communicates with the MN and the SN (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B), and at block 1404B, the UE receives from the MN an RRC message for activating the SCG indicating that the UE should (re)activate the SCG and, in response, activates the SCG (e.g., events 344E, 346E, 409C, 446C, 644A, 646A, 609B).

[0201] At block 1406B, the UE determines whether the received RRC message is related to resuming the RRC connection or RRC reconfiguration. In response to determining that the RRC message is an RRC resume message, the UE resets at least one lower layer for communication with the SN at block 1408B. Otherwise, if the UE determines that the RRC message is an RRC reconfiguration message, at block 1410B, the UE retains the operation information used in at least one lower layer for communication with the SN.

[0202] Figure 14C is a flowchart of an exemplary method 1400C, according to which the UE receives an RRC message indicating SCG deactivation and determines whether to reset or retain the operation information used in at least one lower layer of the radio connection with the SN depending on whether the received RRC message indicates that the UE should suspend the MN connection.

[0203] In block 1402C, the UE communicates with the MN and the SN (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). In block 1404C, the UE receives from the MN an RRC message to deactivate the SCG and deactivates the SCG in response (e.g., events 314A, 316A, 314B, 316B, 514A, 516A, 328A, 528A). In block 1406C, the UE determines whether the received RRC message requires the UE to suspend the MN connection. If so, the flow proceeds to block 1408C, or determines whether the received RRC message does not require the UE to suspend the MN connection. If so, the flow proceeds to block 1410C. In block 1408C, the UE resets at least one lower layer for communication with the SN. In block 1410C, the UE retains the operation information used in at least one lower layer for communication with the SN.

[0204] Referring now to FIG. 15A, there is shown a flowchart of an exemplary method 1500A for managing the MN configuration when the SCG for the UE is deactivated, which may be implemented at the MN. In block 1502A, the MN communicates with the UE to support DC operation using a first part of the MN configuration and a second part of the MN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). In block 1504A, the MN deactivates the SCG while continuing to communicate with the UE (e.g., events 310A, 322A - 322D, 522A, 572A). Then, in block 1506A, the MN releases the first part of the MN configuration and retains the second part of the MN configuration.

[0205] Figure 15B is a flowchart of method 1500B at an MN that manages the MN configuration when the SCG for a UE is deactivated and then (re)activated. Method 1500B starts at block 1502B, where the MN communicates with the UE to support DC operation using a first part of the MN configuration and a second part of the MN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). At block 1504B, the MN deactivates the SCG while continuing to communicate with the UE (e.g., events 310A, 322A - 322D, 522A, 572A).

[0206] Next, at block 1506B, the MN stops using the first part of the MN configuration. In some implementations, rather than completely discarding the first part, the MN suspends the first part of the MN configuration. In other implementations, the MN releases (or discards) the first part at block 1506. In some implementations, the flow proceeds to block 1508B, where the MN continues to use the second part of the MN configuration. Next, at block 1510B, the MN can (re)activate the deactivated SCG while continuing to communicate with the UE (e.g., events 336E, 338E, 636A, 676A). At block 1512B, the MN can use the first part of the MN configuration after (re)activating the deactivated SCG, and at block 1514B, the MN communicates with the UE while continuing to use the second part of the MN configuration after (re)activating the deactivated SCG. Alternatively, the MN does not use the first part of the MN configuration to communicate with the UE after (re)activating the deactivated SCG.

[0207] Figure 16A is a flowchart of an exemplary method 1600A, according to which the MN transmits an RRC message indicating SCG deactivation to the UE and determines whether to retain some or all of the MN configuration depending on whether the message indicates an RRC suspend or an RRC reconfiguration. At block 1602A, the MN communicates with the UE using a first portion of the MN configuration and a second portion of the MN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). Next, at block 1604A, the MN transmits an RRC message indicating SCG deactivation to the UE (e.g., events 314A, 314B, 514A, 328A, 528A). At block 1606A, the MN determines whether the transmitted RRC message is related to an RRC suspend or reconfiguration. In response to determining that the RRC message is an RRC suspend message, at block 1608A, the MN releases the first portion of the MN configuration and retains the second portion of the MN configuration. Otherwise, if the MN determines that the RRC message is an RRC reconfiguration message, the MN retains both portions of the MN configuration at block 1610A.

[0208] FIG. 16B is a flowchart of an exemplary method 1600B, in accordance with which the MN transmits an RRC message indicating SCG (re)activation and determines whether to retain some or all of the MN configuration depending on whether the message is related to resuming an RRC connection or RRC reconfiguration. At block 1602B, the MN communicates with the UE using a first portion of the MN configuration and a second portion of the MN configuration (e.g., events 302A-302E, 402A-402E, 502A-502B, 602A-602B). At block 1604B, the MN transmits an RRC message to the UE to (re)activate the deactivated SCG (e.g., events 344E, 409C, 644A, 609B). At block 1606B, the MN determines whether the received RRC message is related to resuming an RRC connection or RRC reconfiguration. In response to determining that the RRC message is an RRC resume message, the MN releases the first portion of the MN configuration and retains the second portion of the MN configuration at block 1608B. Otherwise, if the MN determines that the RRC message is an RRC reconfiguration message, the MN retains both portions of the MN configuration at block 1610B.

[0209] Figure 16C illustrates a flowchart of another exemplary method 1600C, in accordance with which the MN transmits an RRC message indicating SCG deactivation and determines whether to retain some or all of the MN configuration depending on whether the message indicates that the UE 102 should suspend the MN connection. Method 1600C begins at block 1602C, where the MN communicates with the MN using a first portion of the MN configuration and a second portion of the MN configuration (e.g., events 302A-302E, 402A-402E, 502A-502B, 602A-602B). At block 1604C, the MN determines to deactivate the SCG for the UE 102 (e.g., events 308A, 508A). At block 1606C, the MN determines whether to suspend the MN connection with the UE, in which case the flow proceeds to block 1608C, or determines to not suspend the MN connection, in which case the flow proceeds to block 1610C. At block 1608C, the MN releases the first portion of the MN configuration and retains the second portion of the MN configuration. On the other hand, at block 1610C, the MN retains both portions of the MN configuration.

[0210] Next, FIGS. 17A-17C illustrate exemplary methods 1700A-C for releasing and / or retaining a portion of the SN configuration, which may be implemented, for example, in the RAN 105.

[0211] Method 1700A starts from block 1702A, where the RAN communicates with the UE using the MN configuration, the first part of the SN configuration, and the second part of the SN configuration (e.g., events 302A - 302E, 402A - 402C, 502A - 502B, 602A - 602B). At block 1704A, the RAN transmits an RRC message to the UE to deactivate the SCG (e.g., events 314A, 314B, 315C, 514A, 328A, 528A). Next, at block 1706A, the RAN determines whether the RRC message indicates an RRC suspend, in which case the flow proceeds to block 1708A, or determines an RRC reconfiguration, in which case the flow proceeds to block 1710A. At block 1708A, the RAN releases the first part of the SN configuration and retains the second part of the SN configuration. At block 1710A, the RAN retains both parts of the SN configuration.

[0212] Method 1700B starts from block 1702B, where the RAN communicates with the UE using the MN configuration, the first part of the SN configuration, and the second part of the SN configuration (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). At block 1704B, the RAN transmits an RRC message to the UE to (re)activate the deactivated SCG (e.g., events 344E, 409C, 644A, 609B). Next, at block 1706B, the RAN determines whether the RRC message is related to resuming the RRC connection, in which case the flow proceeds to block 1708B, or determines an RRC reconfiguration, in which case the flow proceeds to block 1710B. At block 1708B, the RAN releases the first part of the SN configuration and retains the second part of the SN configuration. At block 1710B, the RAN retains both parts of the SN configuration.

[0213] Method 1700C starts from block 1702C, where the RAN communicates with the UE using the MN configuration, the first part of the SN configuration, and the second part of the SN configuration. At block 1704C, the RAN determines that the MN and / or SN should deactivate the SCG for the UE. Next, at block 1706C, the RAN determines whether the RAN should suspend the MN connection with the UE, in which case the flow proceeds to block 1708C, or determines not to suspend the MN connection, in which case the flow proceeds to block 1710C. At block 1708C, the RAN releases the first part of the SN configuration and retains the second part of the SN configuration. At block 1710C, the RAN retains both parts of the SN configuration.

[0214] Next, FIGS. 18A-18C illustrate exemplary methods 1700A-C for resetting and / or retaining operation information used in at least one lower layer of the radio connection between the UE and the SN.

[0215] Method 1800A starts from block 1802A, where the RAN communicates with the UE (e.g., events 302A-302E, 402A-402E, 502A-502B, 602A-602B). At block 1804A, the RAN transmits an RRC message to the UE to deactivate the SCG (e.g., events 314A, 314B, 315C, 514A, 328A, 528A). Next, at block 1806A, the RAN determines whether the RRC message indicates an RRC suspend, in which case the flow proceeds to block 1808A, or determines an RRC reconfiguration, in which case the flow proceeds to block 1810A. At block 1808A, the RAN resets at least one lower layer of the radio connection between the SN and the UE. At block 1810A, the RAN retains the operation information of the lower layer of the radio connection between the UE and the SN.

[0216] Method 1800B starts from block 1800B, where the RAN communicates with the UE over DC. At block 1804B, the RAN transmits an RRC message to the UE (e.g., event 344E, 409C, 644A, 609B) to (re)activate the deactivated SCG. Next, at block 1806B, the RAN determines whether the RRC message is related to resuming the RRC connection. In this case, the flow proceeds to block 1808B, or determines an RRC reconfiguration. In this case, the flow proceeds to block 1810B. At block 1808B, the RAN resets at least one lower layer of the radio connection between the SN and the UE. At block 1810B, the RAN retains the operation information of the lower layer of the radio connection between the UE and the SN.

[0217] Method 1800C starts from block 1800C, where the RAN communicates with the UE over DC. At block 1804C, the RAN determines that the MN and / or SN should deactivate the SCG for the UE. Next, at block 1806C, the RAN determines whether it should suspend the MN connection with the UE. In this case, the flow proceeds to block 1808C, or determines not to suspend the MN connection. In this case, the flow proceeds to block 1810C. At block 1808C, the RAN resets at least one lower layer of the radio connection between the SN and the UE. At block 1810C, the RAN retains the operation information of the lower layer of the radio connection between the UE and the SN.

[0218] Next, FIG. 19 illustrates a flow diagram of an exemplary method 1900 for deactivating or activating an SCG that can be implemented in the RAN. Method 1900 begins at block 1902, where the RAN communicates with the UE to support DC operation (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). At block 1904, the RAN deactivates the SCG for the UE (e.g., events 322A - 322D, 522A - 522B). At block 1906, the RAN determines that the radio connection between the MN and the UE should be suspended (e.g., events 324A, 524A). At block 1908, the RAN releases the deactivated SCG and transmits an RRC suspend message to the UE.

[0219] FIG. 20 shows a flow diagram of another exemplary method 2000, according to which the RAN resumes the suspended radio connection with the UE before releasing the deactivated SCG. Method 2000 begins at block 2002, where the RAN communicates with the UE to support DC (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). At block 2004, the RAN deactivates the SCG for the UE (e.g., events 322A - 322D, 522A - 522B). Next, at block 2006, the RAN suspends the radio connection between the MN and the UE (e.g., events 326A, 328A, 526A, 528A). The RAN then executes an RRC resume procedure to resume the suspended radio connection between the MN and the UE at block 2008 (events 404, 408, 412). At block 2010, the RAN releases the deactivated SCG.

[0220] Next, FIG. 21A illustrates a flowchart of an exemplary method 2100A, in accordance with which the RAN determines whether a deactivated SCG should be reactivated for the UE according to the amount of received data. At block 2102A, the RAN communicates with the UE to support DC operation (e.g., events 302A-302E, 402A-402E, 502A-502B, 602A-602B). At block 2104A, while communicating with the UE, the RAN deactivates the SCG (e.g., events 322A-322D, 522A-522B). At block 2106A, the RAN receives data for the UE from, for example, the CN. At block 2108A, the RAN determines whether the amount of received data exceeds a specific threshold. The flow proceeds to block 2110A when the amount exceeds the threshold and to block 2112A when the amount does not exceed the threshold. At block 2110A, the RAN starts the (re)activation of the deactivated SCG (e.g., events 380E, 437B, 439B, 442B, 480B, 405C, 430C, 432C, 442C, 409C, 636A, 676A, 678A, 644A, 642A, 605B, 676B, 678B, 609B). On the other hand, at block 2112A, the RAN refrains from activating the deactivated SCG. Thus, according to method 2100A, the RAN determines whether the MN and / or SN should (re)activate a deactivated SCG based on whether there is sufficient data activity on the SCG.

[0221] Figure 21B illustrates a flowchart of an exemplary method 2100B, in accordance with which the RAN determines whether a suspended SCG for a UE should be reactivated according to the QoS or PDU session to which data for the UE is associated. At block 2102B, the RAN communicates with the UE to support dual connectivity operation (e.g., events 302A - 302E, 402A - 402E, 502A - 502B, 602A - 602B). At block 2104B, while communicating with the UE, the RAN105 suspends the SCG (e.g., events 322A - 322D, 522A - 522B). At block 2106B, the RAN receives data for the UE from, for example, the CN. At block 2108B, the RAN determines whether the received data is associated with a particular QoS flow or PDU session. If the flow is associated with a QoS flow or PDU session, the process proceeds to block 2110B; otherwise, it proceeds to block 2112B. At block 2110B, the RAN initiates the (re)activation of the suspended SCG (e.g., events 380E, 437B, 439B, 442B, 480B, 405C, 430C, 432C, 442C, 409C, 636A, 676A, 678A, 644A, 642A, 605B, 676B, 678B, 609B). On the other hand, at block 2112B, the RAN refrains from activating the SCG. Thus, according to method 2100B, the RAN determines whether the MN and / or SN should (re)activate a suspended SCG based on the type of data addressed to the UE.

[0222] FIG. 21C shows a flowchart of an exemplary method 2100C that is generally similar to method 2100B, in accordance with which the RAN also determines whether the MN and / or SN should (re)activate an SCG deactivated based on the type of addressed data to the UE. Except for block 2108C, the blocks in FIG. 21C are similar to the blocks in FIG. 21B. At block 2108C, the RAN determines that the flow should proceed to block 2110C when the received data is associated with a particular QoS flow or PDU session, and determines that the flow should proceed to block 2112C when the received data is associated with another QoS flow or PDU session.

[0223] To make it more explicit, FIG. 22 illustrates a flowchart of an exemplary method 2200 for managing SCG deactivation and activation, which may be implemented at the MN or RAN, including the MN and SN. At block 2202, the MN or RAN determines that the RAN and / or UE should deactivate the SCG (e.g., event 308A in FIG. 3A, event 309B in FIG. 3B, event 309C in FIG. 3C, procedure 490A in FIG. 4A, procedure 490B in FIG. 4B, procedure 490C in FIG. 4C, event 508A in FIG. 5A, events 584B-1 and 584B-2 in FIG. 5B, procedure 690A in FIG. 6A, procedure 690B in FIG. 6B).

[0224] Optionally, at block 2204, the MN or RAN notifies the UE 102 that the SCG has been deactivated (e.g., event 314A in FIG. 3A, event 314B in FIG. 3B, event 315C in FIG. 3C, event 514A-2 in FIG. 5A).

[0225] Next, at block 2206, the MN or the RAN determines that the radio connection between the MN and the UE should be suspended (e.g., event 324A in FIG. 3A, procedure 394B in FIG. 3B, procedure 394C in FIG. 3C, procedure 494A in FIG. 4A, procedure 494B in FIG. 4B, procedure 494C in FIG. 4C, event 524A in FIG. 5A, procedure 594B in FIG. 5B, procedure 694A in FIG. 6A, procedure 694B in FIG. 6B).

[0226] In response to the determination at block 2206, the MN or the RAN suspends the radio connection between the MN and the UE at block 2208 (e.g., event 328A in FIG. 3A, procedure 394B in FIG. 3B, procedure 394C in FIG. 3C, procedure 494A in FIG. 4A, procedure 494C in FIG. 4C, events 528A-1 and 528A-2 in FIG. 5A, procedure 594B in FIG. 5B, procedure 694A in FIG. 6A, and procedure 694B in FIG. 6B).

[0227] Finally, FIG. 23 illustrates a flowchart of an exemplary method 2300 for managing deactivation and activation of an SCG that may be implemented at a UE. At block 2302, the UE determines that the RAN and / or the UE should deactivate the SCG (e.g., events 314A and 316A in FIG. 3A, events 314B and 316B in FIG. 3B, events 315C and 316C in FIG. 3C, procedure 490A in FIG. 4A, procedure 490B in FIG. 4B, procedure 490C in FIG. 4C, events 514A-2 and 516A in FIG. 5A, event 582B in FIG. 5B, procedure 690A in FIG. 6A, procedure 690B in FIG. 6B).

[0228] At block 2304, the UE determines that the RAN and / or the UE should suspend the radio connection between the UE and the MN (e.g., event 328A in FIG. 3A, procedure 394B in FIG. 3B, procedure 394C in FIG. 3C, procedure 494A in FIG. 4A, procedure 494B in FIG. 4B, procedure 494C in FIG. 4C, event 528A-2 in FIG. 5A, procedure 594B in FIG. 5B, procedure 694A in FIG. 6A, procedure 694B in FIG. 6B).

[0229] In block 2306, the UE suspends at least a portion of the MN configuration and / or releases at least a portion of the MN configuration (e.g., event 330A in FIG. 3A, procedure 394B in FIG. 3B, procedure 394C in FIG. 3C, procedure 494A in FIG. 4A, procedure 494B in FIG. 4B, procedure 494C in FIG. 4C, procedure 594B in FIG. 5B, event 530A in FIG. 5A, procedure 594B in FIG. 5B, procedure 694A in FIG. 6A, procedure 694B in FIG. 6B).

[0230] The following list of examples reflects various embodiments explicitly contemplated by the present disclosure

Example

[0231] A method for managing deactivation of a secondary cell group (SCG) in a network node operating as a master node (MN) for a user equipment (UE) communicating with a master node (MN) and a secondary node (SN) in dual connectivity (DC), the method comprising: determining by processing hardware of the network node that the SCG is to be deactivated for the UE; determining by the processing hardware that a radio connection between the MN and the UE should be suspended when the SCG is deactivated; and suspending, by the processing hardware, the radio connection between the UE and the MN.

Example

[0232] The method according to Example 1, wherein determining that the radio connection should be suspended includes detecting data inactivity on the radio connection.

Example

[0233] The method according to Example 2, wherein detecting data inactivity includes starting an inactivity timer for the radio connection by the processing hardware in response to receiving a notification of inactivity.

Example

[0234] Determining that the SCG is deactivated includes receiving, from the UE, an indication that the UE currently prefers single connectivity, according to any one of embodiments 1 to 3.

Embodiment

[0235] Determining that the SCG is deactivated includes receiving, from the SN, an indication of data inactivity on the SCG, according to any one of embodiments 1 to 4.

Embodiment

[0236] Determining that the SCG is deactivated includes receiving, from the SN, a request to deactivate the SCG, according to any one of embodiments 1 to 3.

Embodiment

[0237] Determining that the SCG is deactivated includes receiving, from the SN, a notification that the SN has deactivated the SCG, according to any one of embodiments 1 to 3.

Embodiment

[0238] In response to determining that the SCG is deactivated, further includes releasing a first part of the MN configuration for the UE and maintaining a second part of the MN configuration for the UE in the MN, according to any one of embodiments 1 to 7.

Embodiment

[0239] Suspending the radio connection includes transmitting, by the processing hardware, a suspend command associated with a protocol for controlling radio resources to the UE, the suspend command including an indication that the SCG is deactivated, according to any one of embodiments 1 to 8.

Embodiment

[0240] In response to determining that the SCG has been deactivated, the method according to any one of Embodiments 1 to 7, further including, at the MN, maintaining the MN configuration for the UE.

Example

[0241] Transmitting, by processing hardware, to the UE a reconfiguration command associated with a protocol for controlling radio resources, the reconfiguration command including an indication that the SCG is deactivated, the method according to Embodiment 10.

Example

[0242] Suspending the radio connection includes transmitting, by processing hardware, to the UE a message indicating that the UE should transition to an inactive state of a protocol for controlling radio resources, the method according to any one of Embodiments 1 to 11.

Example

[0243] Suspending the radio connection includes transmitting, by processing hardware, to the UE a message indicating that the UE should transition to an idle state of a protocol for controlling radio resources and maintaining at least a part of the MN configuration associated with the protocol, the method according to any one of Embodiments 1 to 11.

Example

[0244] In response to determining that the radio connection between the MN and the UE should be suspended, further including transmitting, by processing hardware, to the SN an instruction that the SN releases one or more lower layers of the radio connection between the SN and the UE and maintains one or more upper layers of the radio connection between the SN and the UE, the method according to any one of Embodiments 1 to 13.

Example

[0245] In response to determining that the radio connection between the MN and the UE should be suspended, the processing hardware further includes transmitting, to the SN, an instruction for the SN to suspend one or more lower layers of the radio connection between the UE and the SN and maintain one or more upper layers of the radio connection, according to any one of Examples 1 to 13.

Example

[0246] In response to determining that the UE should transition to an inactive state, the processing hardware further includes transmitting, to the SN, an instruction for the SN to release all layers of the radio connection between the UE and the SN, according to any one of Examples 1 to 13.

Example

[0247] (i) Determining that the SCG is to be deactivated for the UE and (ii) determining that the radio connection between the MN and the UE should be suspended are performed in a first instance, and in a second instance, the method further includes determining, by the processing hardware, that the radio connection between the MN and the UE should be suspended when the SCG is active, and refraining from transmitting, by the processing hardware, a request to release or suspend one or more layers of the radio connection between the UE and the SN to the SN, according to any one of Examples 14 to 16.

Example

[0248] After suspending the radio connection between the UE and the MN, further including determining to resume the radio connection when the SCG is deactivated and when the radio connection between the MN and the UE is suspended, and determining whether the SCG should be reactivated in view of determining to resume the radio connection, according to any one of Examples 1 to 17.

Example

[0249] Determining whether the SCG should be reactivated includes receiving an indication of pending data activity on the SCG from the SN, as described in Example 18.

Example

[0250] Determining whether the SCG should be reactivated includes receiving a request from the UE to resume a radio connection, as described in Example 18.

Example

[0251] The request indicates a cause for resuming the radio connection between the UE and the MN, and the method further includes determining that the SCG should be reactivated when the cause indicates a phone call, as described in Example 20.

Example

[0252] Determining whether the SCG should be reactivated includes receiving addressed data for the UE from the core network and determining whether the SCG should be reactivated based on at least one of (i) the amount of data, (ii) the quality of service (QoS) of the data, or (iii) the protocol data unit (PDU) session to which the data is associated, as described in Example 18.

Example

[0253] In response to determining that the SCG should not be reactivated, the processing hardware transmits a command to the UE to resume the radio connection between the MN and the UE, further including omitting the SN configuration from the command, as described in Example 18.

Example

[0254] In response to determining that the SCG should be reactivated, the processing hardware transmits, to the UE, a command to resume the radio connection between the MN and the UE, further including transmitting the SN configuration, and further including transmitting, as described in Example 18.

Example

[0255] Determining that the radio connection should be suspended and suspending the radio connection are performed in a first instance, and the method further includes, in a second instance, transmitting, to the UE, an SCG deactivation command in response to detecting data activity on the radio connection, as described in any one of Examples 1 to 24.

Example

[0256] The MN is implemented in a first distributed unit (DU) of a distributed base station, and the SN is implemented in a second DU of the distributed base station, as described in any one of Examples 1 to 25.

Example

[0257] The method further includes, by the processing hardware, notifying the UE that the SCG has been deactivated, as described in any one of Examples 1 to 26.

Example

[0258] A network node operating in a radio access network (RAN), including processing hardware, configured to implement the method as described in any one of Examples 1 to 27.

Example

[0259] A method for managing deactivation of a secondary cell group (SCG) in a user equipment (UE) that communicates with a master node (MN) having an MN configuration and a secondary node (SN) having an SN configuration in dual connectivity (DC), the method comprising: deactivating the SCG by processing hardware; determining by the processing hardware that a radio connection between the UE and the MN should be suspended when the SCG is deactivated; and suspending or releasing at least a portion of the MN configuration in response to determining that the radio connection should be suspended.

Example

[0260] Deactivating the SCG includes receiving, from the MN, a message associated with a protocol for controlling radio resources, the message including an indication that the SCG should be deactivated, as described in Example 29.

Example

[0261] After deactivating the SCG, further comprising receiving, from the MN, a second message associated with a protocol for controlling radio resources, the second message including an indication that the SCG should be reactivated, as described in Example 29.

Example

[0262] Further comprising releasing a first portion of the MN configuration and retaining a second portion of the MN configuration in response to determining that the message is a suspend command or a resume command, as described in Example 30 or 31.

Example

[0263] Further comprising retaining the entire MN configuration in response to determining that the message is a reconfiguration command, as described in Example 30 or 31.

Example

[0264] The method according to embodiment 30 or 31, further comprising releasing a first part of the SN configuration and holding a second part of the SN configuration in response to determining that the message is a suspend command or a resume command.

Example

[0265] The method according to embodiment 30, further comprising holding the entire SN configuration in response to determining that the message is a reconfiguration command.

Example

[0266] The method according to embodiment 30 or 31, further comprising resetting one or more lower layers of the radio connection between the UE and the SN in response to determining that the message is a suspend or resume command.

Example

[0267] The method according to embodiment 30 or 31, further comprising holding information associated with one or more lower layers of the radio connection between the UE and the SN in response to determining that the message is a reconfiguration command.

Example

[0268] The method according to embodiment 30, further comprising resetting one or more lower layers of the radio connection between the UE and the SN in response to determining that the message causes the UE to suspend the radio connection between the UE and the MN.

Example

[0269] The method according to embodiment 30, further comprising holding information associated with one or more lower layers of the radio connection between the UE and the SN in response to determining that the message does not cause the suspension of the radio connection between the UE and the MN.

Example

[0270] The method according to any one of Embodiments 29 to 39, further comprising: determining by processing hardware that the UE currently prefers single connectivity; and transmitting an indication to the MN that the UE prefers single connectivity.

Example

[0271] The method according to any one of Embodiments 29 to 39, further comprising: determining by processing hardware that the UE currently prefers single connectivity; and transmitting an indication to the SN that the UE prefers single connectivity.

Example

[0272] The method according to any one of Embodiments 40 or 41, further comprising receiving, from the MN or the SN, a command to deactivate the SCG in response to an indication that the UE prefers single connectivity.

Example

[0273] A user equipment (UE) comprising processing hardware and configured to implement the method according to any one of Embodiments 29 to 42.

[0274] The following additional considerations apply to the foregoing description.

[0275] In some implementations, "message" is used, which can be replaced by "information element (IE)". In some implementations, "IE" is used, which can be replaced by "field". In some implementations, "configuration" can be replaced by "a plurality of configurations" or the configuration parameters included in the above-mentioned MN or SN configuration. For example, "SN configuration" can be replaced by "a plurality of SN configurations". The SN configuration can be replaced by a cell group configuration and / or a radio bearer configuration. In some implementations, "deactivate SCG" can be replaced by "suspend SCG", and "activate SCG" can be replaced by "resume SCG". In some implementations, "lower layer" is used, which can be replaced by "protocol layer".

[0276] The user device (e.g., UE102) in which the techniques of the present disclosure can be implemented can be any suitable device capable of wireless communication such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hot spot, a femtocell, or a broadband router. Further, the user device can be incorporated into an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS) in some cases. Still further, the user device can operate as an Internet of Things (IoT) device or a mobile / internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0277] In some embodiments, in the present disclosure, are described as including logic or a number of components or modules. A module may 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 some operations and can be configured or arranged in a particular way. A hardware module can include dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform some operations. A hardware module can also include programmable logic or circuitry that is temporarily configured by software (e.g., such as being included within a general-purpose processor or other programmable processor) to perform some operations. The decision of whether to implement a hardware module with dedicated permanently configured circuitry or with temporarily configured circuitry (e.g., configured by software) can be made by considering cost and time.

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

[0279] After reading this disclosure, those skilled in the art will understand additional alternative structures and functional designs for resuming MR-DC between a UE and a RAN through the principles disclosed herein. Thus, while specific embodiments and applications are illustrated and described, it should be understood that the disclosed embodiments are not limited to the exact structures and components disclosed herein. Various other modifications, changes, and variations will be apparent to those skilled in the art and may be made in the arrangement, operation, and details of the methods and apparatuses disclosed herein without departing from the spirit and scope defined by the appended claims.

Description of Reference Numerals

[0280] Timers T310, T312, T321, T322, T342, T345, T346a, T346b, T346c, T346d, T346e, T346f 100 Wireless communication system 102 UE 104A Base station (BS) 105 RAN 106A Base station 110 Core network (CN) 111 Evolved Packet Core (EPC) 112 Serving Gateway (SGW) 114 Mobility Management Entity (MME) 116 Packet Data Network Gateway (PGW) 124A Cell 125A Cell 126A Cell 130 Processing hardware 132 MN RRC Controller 134 SCG Controller 140 Processing hardware 142 SN RRC Controller 144 SCG Controller 150 Processing hardware 152 UE RRC Controller 154 SCG Controller 160 5th Generation (5G) Core (5GC) 162 User Plane Function (UPF) 164 Access and Mobility Management (AMF) 166 Session Management Function (SMF) 172 Central Unit (CU) 172A Logical Node CU-CP 172B Logical Node CU-UP 174 DU 174A M-DU 174B S-DU 200 Protocol Stack 202A Physical Layer (PHY) 202B NR PHY 204A EUTRA MAC Sub-layer 204B NR MAC Sub-layer 206A EUTRA RLC Sub-layer 206B NR RLC Sub-layer 208 EUTRA PDCP Sub-layer 210 NR PDCP Sub-layer 212 Service Data Adaptation Protocol (SDAP) 300A Scenario 302A~302E, 402A~402E, 502A~502B, 602A~602B Events 304A, 306A, 308A, 310A, 312A, 314A, 316A, 318A, 320A, 322A Events 305B, 307B, 309B, 311B, 314B, 316B, 318B, 322B Events 305C, 307C, 309C, 311C, 315C, 316C, 319C, 322C Events 308A, 508A Events 310A, 322A~322D, 522A, 572A Events 314A, 316A, 314B, 316B, 514A, 516A, 328A, 528A Events 315C Event 322A - 322D, 522A - 522B Events 324A, 326A, 330A Events 324A, 524A Events 326A, 328A, 526A, 528A Events 328A, 528A Events 332E, 334E, 336E, 338E, 340E, 342E, 344E, 346E, 348E, 350E, 352E, 354E Events 336E, 338E, 636A, 676A Events 344E, 346E, 348E, 350E, 352E, 354E Events 346E, 646A Event 370E, 380E Events 370E SCG Activation Procedure 380E SCG Activation Procedure 380E, 437B, 439B, 442B, 480B, 405C, 430C, 432C, 442C, 409C, 636A, 676A, 678A, 644A, 642A, 605B, 676B, 678B, 609B Events 382D, 384D, 316D, 322D, 375D Events 390A SCG De - activation Procedure 390E SCG De - activation Procedure 391B SCG De - activation Procedure 392C SCG De - activation Procedure 393D SCG De - activation Procedure 394A RRC Suspend Procedure 394B RRC Suspend Procedure 394C RRC Suspend Procedure 394D RRC Suspend Procedure 400A Scenario 400B Scenario 402A Event 402B Event 404, 408, 412 Events 414B Event 490A SCG Deactivation Procedure 490B SCG Deactivation Procedure 490C SCG Deactivation Procedure 494 RRC Suspend Procedure 494A RRC Suspend Procedure 494B RRC Suspend Procedure 494C RRC Suspend Procedure 500A Scenario 500B Scenario 502A, 506A, 508A, 514A-1, 516A, 518A-1, 518A-2, 572A, 522A, 574A Events 514A-1 RRC Reconfiguration Message 530A Event 582B, 584B-1, 584B-2, 572B, 516B, 522B, 574B Events 590A SCG Deactivation Suspend Procedure 593B SCG Deactivation Procedure 594A RRC Suspend Procedure 594B RRC Suspend Procedure 602A, 602B Events 644A-1, 644A-2 Events 690A SCG Deactivation Procedure 694A RRC Suspend Procedure 694B RRC Suspend Procedure 700A, 702B Methods 900 Method 1000 Method 1100 Method 1200 Method 1200B Method 1200C Method 1300A Method 1300B Method 1300C Method 1400A Method 1400B Method 1400C Method 1500A Method 1500B Method 1600A method 1600B method 1600C method 1700A method 1700B method 1700C method 1800A method 1800B method 1800C method 1900 method 2000 method 2100A method 2100B method 2100C method 2200 method 2300 method

Claims

1. In a network node operating as the master node (MN) for a user equipment (UE) communicating with a master node (MN) and a secondary node (SN) in dual connectivity (DC), a method for managing deactivation of a secondary cell group (SCG), the method being executed by a computer, transmitting, from the MN, a first request to deactivate the SCG to the SN; receiving, at the MN, a first message from the SN in response to the step of transmitting the first request to the SN; transmitting, from the MN, a second message to deactivate the SCG to the UE; transmitting, from the MN, a second request to activate the SCG to the SN; receiving, at the MN, a third message from the SN in response to the step of transmitting the second request to the SN, the third message comprising a random access configuration for the UE to perform a random access procedure, indicating refraining from performing the random access procedure if a corresponding time alignment timer is running; and transmitting, from the MN, a fourth message comprising the random access configuration to the UE.

2. The step of transmitting the second message comprises transmitting, from the MN, a reconfiguration message to the UE to deactivate the SCG; and receiving, at the MN, an indication from the UE indicating that the SCG has been deactivated in response to the step of transmitting the reconfiguration message to the UE. The method according to claim 1.

3. The step of transmitting the second request to activate the SCG to the SN is performed in response to receiving an indication of pending data activity on the SCG from the SN. The method according to claim 1.

4. The step of transmitting the second request to activate the SCG to the SN is performed in response to receiving a request from the UE to resume a radio connection. The method according to claim 1.

5. The step of transmitting the second request to activate the SCG to the SN is receiving, from a core network, data addressed to the UE; determining whether the SCG should be activated based on at least one of: (i) the amount of the data, (ii) the quality of service (QoS) of the data, or (iii) the protocol data unit (PDU) to which the data is associated; The method according to claim 1, wherein the method is performed in response to the determining step. **Claim 6** The step of transmitting the first request to deactivate the SCG to the SN is performed in response to receiving, from the UE, an indication that the UE currently prefers single connectivity, according to any one of claims 1 to 5. **Claim 7** The step of transmitting the first request to deactivate the SCG to the SN is performed in response to receiving, from the SN, an indication of data inactivity on the SCG, according to any one of claims 1 to 5. **Claim 8** The step of transmitting the first request to deactivate the SCG to the SN is performed in response to receiving, from the SN, a notification indicating that SN correction is required, according to any one of claims 1 to 5. **Claim 9** The first message from the SN includes an indication that the SCG is to be deactivated, according to any one of claims 1 to 8. **Claim 10** A method for managing deactivation of a secondary cell group (SCG) in a network node operating as the SN for a user equipment (UE) communicating in dual connectivity (DC) with a secondary node (SN) and a master node (MN), the method comprising: receiving, at the SN, a first request from the MN to deactivate the SCG; transmitting, from the SN, a first message to the MN in response to receiving the first request from the MN; deactivating the SCG by the SN; receiving, at the SN, a second request from the MN to activate the SCG; and transmitting, from the SN, a second message to the MN in response to receiving the second request, the second message comprising: Including a random access configuration for the UE to execute a random access procedure, When a corresponding time alignment timer is running, a step indicating refraining from executing the random access procedure, A method including the step of activating the SCG by the SN.

11. The method according to claim 10, wherein the first message includes an SN configuration for the UE.

12. The step of deactivating the SCG, The method according to claim 11, including the step of deactivating the SCG by the SN according to the SN configuration.

13. A network node operating in a radio access network (RAN), including processing hardware and configured to implement the method according to any one of claims 1 to 9.

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

Images