Restoring multi-radio dual connectivity

Abstract

A node of a radio access network (RAN) can implement a method for facilitating recovery of dual connectivity for a user equipment (UE). The method includes receiving, from the UE, a request to recover radio connectivity with the UE, and determining whether to recover dual connectivity with the UE. The method also includes generating a message instructing the UE to recover radio connectivity with the node, where the generating includes including or excluding, in the message based on the determining, an indication of a maximum power limit for UE uplink transmissions. The method further includes transmitting the message to the UE.

Description

Technical Field

[0001] This disclosure generally relates to wireless communications, and more particularly to the restoration of multiple radio dual connectivity (MR-DC) during an RRC restoration process in which a user equipment (UE) restores suspended radio connections with a primary node (MN) and a secondary node (SN), respectively. Background Technology

[0002] This background description is provided for the purpose of generally presenting the context of this disclosure. The work of the currently attributed inventors, to the extent described in this background section, and aspects of the description that may not be worthy of being considered prior art at the time of filing, are neither expressly nor implicitly acknowledged as prior art relative to this disclosure.

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

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

[0005] When operating in a DC, several types of SRBs exist that the UE can use. SRB1 and SRB2 resources allow the UE and MN to exchange MN-related RRC messages and embed SN-related RRC messages, and can be referred to as MCG SRBs. SRB3 resources allow the UE and SN to exchange SN-related RRC messages, and can be referred to as SCG SRBs. Split SRBs allow the UE to exchange RRC messages directly with the MN using radio resources of the MN, SN, or both. Furthermore, the UE and base stations (e.g., MN and SN) use data radio bearers (DRBs) to transmit data on the user plane. A DRB terminating at the MN and using only lower-layer resources of the MN can be referred to as an MCG DRB; a DRB terminating at the SN and using only lower-layer resources of the SN can be referred to as an SCG DRB; and a DRB terminating at the MCG but using lower-layer resources of both the MN and SN can be referred to as a split DRB.

[0006] In certain circumstances, the base station (e.g., MN, SN) and / or CN causes the UE to transition from one operating state of the Radio Resource Control (RRC) protocol to another state specified in 3GPP technical specifications 36.331v16.0.0 and 38.331v16.0.0. More specifically, the UE can operate in an idle state (e.g., EUTRA-RRC_IDLE or NR-RRC IDLE), in which the UE does not have a radio connection with the base station; in a connected state (e.g., EUTRA-RRC_CONNECTED or NR-RRCCONNECTED), in which the UE has a radio connection with the base station; or in an inactive state (e.g., EUTRA-RRC_IDLE, NR-RRC IDLE, EUTRA-RRC INACTIVE, or NR-RRC INACTIVE), in which the UE has a suspended radio connection with the base station.

[0007] In certain circumstances, a UE in an MR-DC with both the MN and SN can operate in a connected state and subsequently transition to an inactive state. In the inactive state, the radio connection between the UE and the MN and SN is suspended; that is, the MR-DC between the UE and the MN and SN is suspended. When the radio connection between the UE and the MN is suspended, the UE and MN retain the configuration they used to communicate with each other prior to the transition. Similarly, when the radio connection between the UE and the SN is suspended, the UE and SN retain the configuration they used to communicate with each other prior to the transition. In response to a network-triggered event (e.g., RAN paging), such as when the MN pages the UE (e.g., for an incoming call), or when the UE is otherwise triggered to transmit data (e.g., for an outgoing call, browser launch, non-access stratum message, or location service), the UE can subsequently transition back to the connected state. To perform the transition, the UE can request the MN to restore the suspended radio connection(s)(e.g., by sending an RRC restoration request message), allowing the MN to configure the UE to operate in the connected state again.

[0008] More specifically, the MN can restore MR-DC by separately restoring the suspended connections between the UE and the MN and between the UE and the SN (e.g., by sending an RRC restore message to the UE). In some scenarios, the UE can reuse the retained configuration to communicate with the MN and SN after restoring the suspended connections. By restoring MR-DC when transitioning from an inactive state to a connected state, the UE can immediately take advantage of the high data rates and low latency available during MR-DC.

[0009] However, a UE may encounter various issues when attempting to resume MR-DC after transitioning from an inactive state. As a first example, some UEs may not be able to apply retained configurations to communicate with the SN upon transitioning to a connected state. More specifically, a UE may not retain the SN configuration long enough to use it to resume MR-DC. As a result, when a UE transitions from an inactive state to a connected state, the MN may only configure the UE to resume single connectivity. The MN could configure the UE to operate in MR-DC later, but this delays MR-DC operation and therefore the availability of the higher data rates offered by MR-DC.

[0010] As another example, the UE may be unaware of the power and timing limitations on uplink transmissions to the RAN after MR-DC recovery. The MN can configure the UE to recover the MR-DC using the RRC connection recovery procedure, causing the UE to transition from an inactive state to a connected state. At a later time, according to current standards (e.g., 3GPP TS 36.331v16.0.0), the MN can inform the UE operating in the MR-DC of the maximum power limits for uplink transmissions to the MN or SN, or the timing instances where the UE is permitted to transmit to the MN or SN (e.g., by transmitting an RRCConnectionReconfiguration message to the UE, including parameters such as p-MaxEUTRA, p-MaxUE-FR1, tdm-PatternConfig-r15, and / or tdm-PatternConfig-r16). However, during the period between the UE transitioning to the connected state and the UE receiving these parameters, the UE may be unaware of these power and timing limitations, which could require the UE to refrain from signaling or lead to other network inefficiencies (e.g., excessive use of uplink resources by the UE).

[0011] As another example, if the MN includes the SN configuration in the RRC recovery message sent to the UE, some UEs may fail to comply with at least a portion of the SN configuration. In such a scenario, the UE may not know how to communicate with the RAN and may attempt to communicate with the RAN in a manner different from the SN configuration. Correspondingly, the RAN may not be aware of the UE's state and may fail to properly process and / or respond to unexpected transmissions from the UE. Summary of the Invention

[0012] This disclosure discloses various types of RAN node implementations for configuring a UE to resume MR-DC after transitioning from an inactive state to a connected RRC state, offering less latency and / or other advantages over existing technologies (e.g., avoiding unknown UE states). Generally, in some implementations, in response to determining that a UE should be configured to enter an inactive state, the MN can cause the SN to release or suspend lower layers (e.g., PHY, MAC, and / or RLC layers) used for communication with the UE. After receiving a request to restore radio connectivity from the UE, the MN can send an indication to the SN to rebuild or restore the lower layers used for communication with the UE. In response, the SN provides a new configuration that the UE can use to communicate with the SN. If the RAN (MN or SN) determines that the UE releases the old SN configuration before restoring radio connectivity, the SN can provide a full configuration; or if the RAN determines that the UE can retain and apply the old SN configuration upon restoration of radio connectivity, the SN can provide an incremental configuration. If the SN includes a central unit (CU) and a distributed unit (DU) of a base station, the CU can communicate with the DU to receive a full or incremental configuration for the DU and can provide that DU configuration to the MN.

[0013] In some implementations, a single base station acts as both the MN and the SN, where the MN comprises the base station's CU and a first DU, and the SN comprises the base station's CU and a second DU. Similar to the techniques described above, the CU can provide a new configuration for the second DU, which the UE can use to communicate with the second DU (and thus with the SN) upon restoration of MR-DC.

[0014] The MN can include a new full or incremental configuration in the RRC recovery message sent by the MN to the UE, so that the UE can immediately utilize the configuration to communicate in MR-DC with the MN and SN.

[0015] The UE disclosed herein can also implement techniques for resuming MR-DC after transitioning from an inactive state to a connected RRC state. For example, if the UE communicates in MR-DC before transitioning to an inactive state, the UE can retain parameters specifying the power and / or timing requirements for communication in MR-DC. After transitioning back to the connected state, the UE can reuse these parameters to communicate in MR-DC. Therefore, the UE can avoid overusing network resources (e.g., causing excessive interference to other UEs by transmitting uplink signals at high power).

[0016] As another example, if the UE receives an RRC recovery message that includes SN and MN configurations that the UE cannot fully comply with, the UE can transition to an idle state without a suspended radio connection. Conversely, if the UE can fully comply with the MN configuration but not the SN configuration, the UE can transmit an SCG failure information message to the MN. In this way, the UE can react to its failure to comply with the MN and / or SN configurations in a manner that the RAN understands and expects.

[0017] An example embodiment of the technology disclosed herein is a method for facilitating the restoration of dual connectivity for a UE in a first node of a RAN. The method includes transmitting a first message to a second node of the RAN communicating with the UE according to a first configuration, the first message causing the second node to release or suspend lower layers used for communicating with the UE. The method also includes transmitting a second message to the second node after transmitting the first message, the second message causing the second node to rebuild or resume lower layers used for communicating with the UE. The method further includes receiving a second configuration from the second node in response to the second message for the UE to use for communicating with the second node.

[0018] Another example embodiment of these technologies is a method for facilitating the restoration of dual connectivity for a UE in a first node of the RAN, wherein the first node previously communicated with the UE according to a first configuration. The method includes receiving a first message from a second node of the RAN and, in response to the first message, releasing or suspending the lower layer used for communication with the UE via the processing hardware of the first node. The method also includes receiving a second message from the second node and, in response to the second message, reconstructing or restoring the lower layer used for communication with the UE via processing hardware, and transmitting a second configuration for the UE to use for communication with the first node to the second node.

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

[0020] Another example embodiment of these technologies is a method for restoring dual connectivity in a UE within a RAN. The method includes operating in dual connectivity with a primary node via a first radio connection and with a secondary node via a second radio connection, and receiving from the primary node one or more configuration parameters for the UE to communicate with one or both of the primary and secondary nodes. The method also includes transitioning the UE's operational state, associated with a protocol for controlling radio resources, from a connected state to an inactive state by at least partially suspending the first and second radio connections via the UE's processing hardware. The method further includes, while in the inactive state, retaining one or more configuration parameters and receiving a command to restore radio connectivity with the RAN. Furthermore, the method includes communicating with the primary or secondary node using the retained one or more configuration parameters after restoring radio connectivity with the RAN.

[0021] Another example embodiment of these technologies is a method for restoring dual connectivity in a UE within a RAN. The method includes receiving a command from the RAN to restore suspended dual connectivity with the RAN, the command including at least one configuration that the UE intends to use to communicate with a primary or secondary node. The method also includes determining, through processing hardware, that the UE cannot comply with at least a portion of the at least one configuration, and in response to the determination, transitioning to an idle state or transmitting a failure message to the primary node.

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

[0023] Figure 1A This is a block diagram of an example system in which one or more base stations and / or user equipment (UE) can implement the techniques of this disclosure to restore a suspended multi-RAT dual connectivity (MR-DC) between the UE and the radio access network (RAN);

[0024] Figure 1B It includes being able to Figure 1A A block diagram of an example base station operating in the system, consisting of a central unit (CU) and a distributed unit (DU);

[0025] Figure 2 yes Figure 1A The UE can be based on the block diagram of the example protocol stack for its communication with the base station;

[0026] Figures 3A-3E This is a sample message sequence in which the primary node (MN) enables the secondary node (SN) to provide SN configuration for the UE to use when restoring MR-DC;

[0027] Figures 4A-4E It is similar to Figures 3A-3E The example message sequence, but in which SN includes both the Central Unit (CU) and the Distributed Unit (DU);

[0028] Figures 5A-5E It is similar to Figures 3A-3E Example message sequences, but in which the portion from a single base station acts as MN and SN;

[0029] Figure 6 This is a flowchart of an example method for recovering MR-DC with the UE, which can be implemented by MN;

[0030] Figure 7 This is a flowchart of an example method that can be implemented by the SN to respond to an SN modification request message received from the MN;

[0031] Figure 8This is a flowchart of an example method that can be implemented by MN to facilitate the recovery of MR-DC using full or incremental SN configuration;

[0032] Figure 9 This is a flowchart of an example method that can be implemented by an SN to facilitate the recovery of MR-DC using full or incremental SN configuration;

[0033] Figure 10 This is a flowchart of an example method for receiving an SN modification request message from the MN and including an indication for the UE to release a lower layer, which can be implemented by the CU of the SN;

[0034] Figure 11 This is a flowchart of an example method for receiving an SN modification request message from the MN and including an indication for the UE to suspend the lower layer, which can be implemented by the CU of the SN;

[0035] Figure 12 This is a flowchart of an example method for receiving an SN modification request message from the MN and including an indication for the UE to rebuild a lower layer, which can be implemented by the CU of the SN;

[0036] Figure 13 This is a flowchart of an example method for receiving an SN modification request message from the MN and including an indication for the UE to recover a lower layer, which can be implemented by the CU of the SN;

[0037] Figure 14 This is a flowchart of an example method for providing the CU with a DU configuration that the UE can use to restore MR-DC, which can be implemented by the SN's DU;

[0038] Figure 15 This is a flowchart of an example method that can be implemented by an MN to provide power and / or timing parameters to be used by the UE after MR-DC recovery;

[0039] Figure 16 This is a flowchart of an example method that can be implemented by the UE to retain power and / or timing parameters that the UE can use after MR-DC recovery;

[0040] Figure 17 This is a flowchart of an example method that the UE can execute in response to determining that the UE cannot apply the SN configuration in the RRC recovery message;

[0041] Figure 18 This is a flowchart of an example method that the UE can execute in response to determining that the UE cannot apply the MN or SN configuration in the RRC recovery message;

[0042] Figure 19This is a flowchart of an example method for recovering MR-DC that can be implemented by network nodes of this disclosure;

[0043] Figure 20 This is a flowchart of another example method for recovering MR-DC that can be implemented by network nodes of this disclosure;

[0044] Figure 21 This is a flowchart of an example method for recovering MR-DC that can be implemented by the UE of this disclosure; and

[0045] Figure 22 This is a flowchart of another example method for recovering MR-DC that can be implemented by the UE of this disclosure. Detailed Implementation

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

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

[0048] Among other components, EPC 111 may include a Serving Gateway (S-GW) 112 and a Mobility Management Entity (MME) 114. The S-GW 112 is typically configured to transmit user plane packets related to audio calls, video calls, internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. 5GC 160 includes a User Plane Function (UPF) 162 and Access and Mobility Management (AMF) 164 and / or Session Management Function (SMF) 166. Generally, the UPF 162 is configured to transmit user plane packets related to audio calls, video calls, internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

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

[0050] Base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (such as CPUs) and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units (e.g., application-specific integrated circuits (ASICs) or digital signal processors (DSPs)). In an example embodiment, processing hardware 130 includes an RRC recovery controller 132 configured to restore the radio connection between UE 102 and RAN 105 and / or release the previous DC configuration using a new DC configuration.

[0051] SN 106 is equipped with processing hardware 140, which may also include one or more general-purpose processors (such as a CPU) and non-transitory computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors, and / or dedicated processing units (e.g., ASICs or DSPs). In the example implementation, processing hardware 140 includes an RRC recovery controller 142 configured to process an SN modification process in response to an RRC recovery request from UE 102. Typically, since the base station can operate as an MN or SN in different scenarios, RRC recovery controllers 132 and 142 can implement similar sets of functions, and each supports both MN and SN operation.

[0052] Still referencing Figure 1A UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors (such as a CPU) and non-transitory computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors, and / or dedicated processing units. In an example implementation, processing hardware 150 includes an RRC recovery controller 152 configured to restore radio connectivity with RAN 105 (e.g., MN 104 and / or SN 106) (one or more).

[0053] More specifically, RRC recovery controllers 132, 142, and 152 can implement at least some of the techniques discussed below (refer to various messaging and flowcharts) for managing RRC configurations.

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

[0055] Figure 1B An example distributed implementation of a base station, such as base station 104 or 106, is depicted. The base station in this implementation may include a centralized unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 is equipped with processing hardware, which may include one or more general-purpose processors (such as CPUs) and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. In one example, CU 172 is equipped with processing hardware 130. In another example, CU 172 is equipped with processing hardware 140. The processing hardware 140 in the example implementation includes an RRC recovery controller 142 configured to manage or control one or more RRC configurations and / or RRC processes when base station 106 operates as an SN. DU 174 is also equipped with processing hardware, which may include one or more general-purpose processors (such as CPUs) and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. In some implementations and / or scenarios, processing hardware 130 and / or 140 may be distributed between CU 172 and DU 174 (or one or more DU 174). In some examples, the processing hardware in the example implementation includes a MAC controller configured to manage or control one or more Media Access Control (MAC) operations or procedures (e.g., random access procedures) when base station 106 operates as MN or SN, and an RLC controller configured to manage or control one or more Radio Link Control (RLC) operations or procedures. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer (PHY) operations or procedures.

[0056] Figure 2 An example radio protocol stack 200 is illustrated in a simplified manner, which UE 102 can use to communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104 or 106). In the example stack 200, the EUTRA PHY 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A provides an RLC channel to the EUTRA Packet Data Convergence Protocol (PDCP) sublayer 208, and in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B, in turn, provides an RLC channel to the NR PDCP sublayer 210. In some implementations, UE 102 supports EUTRA and NR stacks, such as Figure 2 As shown, this is to support handover between EUTRA and NR base stations and / or support DC on the EUTRA and NR interfaces. Additionally, as... Figure 2 As shown, UE 102 can support the layering of NR PDCP sublayer 210 on EUTRA RLC sublayer 206A.

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

[0058] For example, on the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide SRBs to exchange RRC messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide DRBs to support data exchange.

[0059] In scenarios where UE 102 operates in EUTRA / NR DC (EN-DC) or NG-RAN EN-DC (NGEN-DC), with base station 104 operating as a MeNB or Mng-eNB and base station 106 operating as an SgNB, the wireless communication system 100 can provide UE 102 with an MN-terminated bearer using EUTRA PDCP sublayer 208, or an MN-terminated bearer using NR PDCP sublayer 210. In various scenarios, the wireless communication system 100 can also provide UE 102 with an SN-terminated bearer, which uses only NR PDCP sublayer 210. The MN-terminated bearer can be an MCG bearer, an SCG bearer, or a split bearer. The SN-terminated bearer can be an MCG bearer, an SCG bearer, or a split bearer. The MN-terminated bearer can be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN-terminated bearer can be an SRB or a DRB.

[0060] Next, refer to Figures 3A-5E The discussion is in Figure 1A Several example scenarios are presented in the system where the base station restores the radio connection (i.e., MR-DC) between UE 102 and RAN 105. Generally speaking, Figures 3A-5E Similar events are labeled with similar reference numerals (e.g., event 322A is similar to events 322B-E, 422A-E, and 522A-E), and the differences are discussed appropriately below.

[0061] First refer to Figure 3A In scenario 300A, base station 104 operates as the MN, and base station 106 operates as the SN. Initially, UE 102 in the DC transmits 302A uplink (UL) PDUs and / or downlink (DL) PDUs with MN 104 and SN 106, respectively, according to a first MN configuration and a first SN configuration. In some embodiments, UE 102 in the DC may transmit 302A UL PDUs and / or DL ​​PDUs via radio bearers that may include SRBs and / or DRBs. MN 104 and / or SN 106 may configure radio bearers for UE 102.

[0062] At a later time, MN 104 can determine that data inactivity exists for UE 102, and in response, determine 306A to configure UE 102 into an inactive state. In some implementations, MN 104 determines that data inactivity exists for UE 102 based on a message received by MN 104 from SN 106. For example, SN 106 can detect data inactivity for UE 102 and, in response, send an Activity Notification message with an inactivity indication (304A) to MN 104. MN 104 can then determine that data inactivity exists for UE 102 based on the received Activity Notification message. In other implementations, MN 104 can start a data inactivity timer to monitor data activity. In some of these implementations, for example, if the data inactivity timer expires and MN 104 has not transmitted or received data from UE 102 while the data inactivity timer is running, MN 104 detects data inactivity for UE 102. Conversely, if MN 104 has data to transmit to UE 102 or receive data from UE 102 while the data inactivity timer is running, MN 104 can restart the data inactivity timer.

[0063] In some alternative implementations, MN 104 may determine that 306A configures UE 102 to enter an idle state with a suspended radio connection, rather than an inactive state.

[0064] In response to determination 306A, MN 104 sends a 308A SN Modification Request message to SN 106. This SN Modification Request message includes an indication for UE 102 to release lower-layer resources (e.g., PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B). In response to the SN Modification Request message, SN 106 releases lower-layer resources 310A and sends a 312A SN Modification Request Acknowledge message to MN 104. More specifically, in some implementations, SN 106 may release lower-layer resources allocated for communication with UE 102. These resources may include, for example, software, firmware, memory (e.g., memory hardware or storage space within memory hardware), and / or the processing power of SN 106 for implementing the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communicating with UE 102. For example, SN 106 may allocate processing power from its ASIC, DSP, and / or CPU for communicating with UE 102, and may release the allocated processing power in response to an instruction to release a lower layer. In other embodiments, SN 106 may release a first SN configuration in response to an instruction to release a lower layer. In some embodiments, SN 106 may retain at least one interface identifier (ID) of UE 102 for exchanging interface messages between MN 104 and SN 106 in response to an instruction to release a lower layer. For example, if the interface between MN 104 and SN 106 is an Xn interface (e.g., ... Figure 1A If the interface between MN 104 and SN 106 is an X2 interface, then at least one interface ID may include a first UE XnAP ID assigned by SN 106 and a second UE XnAP ID assigned by MN 104. In another example, if the interface between MN 104 and SN 106 is an X2 interface, then at least one interface ID may include a first UE X2AP ID assigned by SN 106 and a second UE X2AP ID assigned by MN 104.

[0065] In some implementations, MN 104 stores the UE context of UE 102 (e.g., UE Access Layer (AS) context or UE inactive AS context, a portion of the UE AS context, or a portion of the UE inactive AS context as defined by the 3GPP specification). When UE 102 is in a connected state, MN 104 communicates with UE 102 based on the UE context. For example, the UE context may include security keys, MCG configuration (e.g., one or more cells including MN 104), and radio bearer configurations configuring 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 may include one or more SRBs and / or one or more DRBs.

[0066] In response to determination 306A, after MN 104 transmits a 308A SN Modification Request message or after SN 106 transmits a 312ASN Modification Request Confirmation message, MN 104 transmits a 314A RRC Suspension message to cause UE 102 to suspend its radio connection with MN 104 and SN 106. In response to the RRC Suspension message, UE 102 suspends the 316A radio connection but retains the 318A First MN Configuration (or at least some configurations within the 318A First MN Configuration). After suspending the 316A radio connection, UE 102 can transition to an inactive or idle state (e.g., an idle state with a suspended RRC connection). The RRC Suspension message may include a SuspendConfig IE, an RRC-InactiveConfig-r15 IE, or a ResumeIdentity-r13 IE. Events 302A, 304A, 306A, 308A, 310A, 312A, 314A, 316A, and 318A occur in... Figure 3A This is collectively referred to as MR-DC Pause Process 350A.

[0067] Continue to refer to Figure 3AUpon receiving a 314A RRC pause message, UE 102 may retain the 320A first SN configuration (or some configurations within the 320A first SN configuration). However, as discussed below, in some implementations, UE 102 does not retain the first SN configuration for a sufficient period to restore MR-DC with SN 106. In other implementations, UE 102 does not retain the 320A first SN configuration at all after pausing the 316A radio connection. After pausing the 316A radio connection, UE 102 may, for example, in response to determining to initiate data transmission with base station 104, or in response to a paging message received from base station 104, perform an RRC recovery procedure to transition from an inactive or idle state to a connected state. In response to this determination, UE 102 may send a 322A RRC recovery request message to MN 104 via cell 124, such that MN 104 may configure UE 102 to operate again in the connected state. In response to the RRC recovery request message, MN 104 can determine that MR-DC has been restored for UE 102. In response to this determination, MN 104 can send a 328A SN Modification Request message to SN 106, including an indication to rebuild the lower layer for UE 102. In some implementations, MN 104 instead sends a 328ASN Addition Request message to a base station other than SN 106 to configure the new base station as the SN for UE 102. In response to the SN Addition Request message, the base station sends an SN Addition Request Acknowledge message to MN 104, including the complete SN configuration.

[0068] In response to receiving an SN Modification Request message or an indication to rebuild a lower layer in event 328A, SN 106 obtains (e.g., generates) a complete SN configuration and sends an SN Modification Request Confirmation message including the complete SN configuration to MN 104 in event 332A. In some implementations, SN 106 may allocate lower layer resources for communication with UE 102 in response to an indication to rebuild a lower layer. For example, these resources may include software, firmware, memory, and / or processing power used by SN 106 to implement the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with UE 102. SN 106 may allocate processing power from its ASIC, DSP, and / or CPU for communication with UE 102.

[0069] In some implementations, MN 104 determines in the SN Modification Request message that the instruction to rebuild the lower layer for UE 102 should be included based on MN 104's prior indication to SN 106 to release the lower layer in Event 308A. In other implementations, MN 104 determines in the SN Modification Request message that the instruction to rebuild the lower layer for UE 102 should be included based on MN 104's determination that UE 102 releases the first SN configuration before transitioning to a connected state (e.g., before restoring radio connectivity or initiating an RRC recovery procedure). In some of these later implementations, MN 104 determines that UE 102 releases the first SN configuration based on UE 102's UE capabilities (e.g., as referenced below). Figure 3B (To be discussed in further detail). UE capabilities can indicate that UE 102 cannot retain (i.e., not delete) the SN configuration (i.e., SCG configuration) when initiating an RRC recovery procedure. MN 104 can receive UE capabilities from core network 110 (e.g., AMF 164 or MME 114) or another base station, or can receive UE capabilities from UE 102 in a UE Capability Information message at event 302A. In other implementations, SN 106 cannot retain the first SN configuration when the radio connection with UE 102 is suspended, or cannot reuse some configurations in the first SN configuration after the radio connection with UE 102 is restored. For example, in response to an SN modification request message received at event 308A, SN 106 can release the first SN configuration. In such an implementation, MN 104 determines, based on MN 104's determination that SN 106 will release the first SN configuration or not reuse some of the first SN configuration, to include the instruction to rebuild the lower layer for UE 102 in the SN modification request message sent by MN 104 at event 328A, regardless of whether UE 102 is able to retain the first SN configuration before transitioning to the connected state.

[0070] After receiving the 332A SN Modification Request Confirmation Message and in response to the RRC Resumption Request Message, MN 104 sends the 334A RRC Resumption Message, including the complete SN configuration, to UE 102. In response to the RRC Resumption Message, UE 102 releases the 336A First SN Configuration, restores the suspended radio connection with MN 104 (338A), and transitions to a connected state. UE 102 may transmit the 340A RRC Resumption Complete Message to MN 104 after restoring the suspended radio connection (338A) and in response to the RRC Resumption Message. This RRC Resumption Complete Message may include the RRC Reconfiguration Complete Message. After receiving the 340A RRC Resumption Complete Message, MN 104 may send the 342ASN Reconfiguration Complete Message to SN 106 to indicate to SN 106 that UE 102 has successfully received or applied the complete SN configuration. In one implementation, MN 104 may include the RRC Reconfiguration Complete Message from the RRC Resumption Complete Message in the SN Reconfiguration Complete Message.

[0071] exist Figure 3A In one implementation, UE 102 releases the first SN configuration (336A) after receiving the 334A RRC recovery message (e.g., in response to the RRC recovery message). However, in other implementations, UE 102 may release the first SN configuration (336A) at another time (e.g., in response to an RRC pause message not being retained at event 320A, or during the transmission of the 322A RRC recovery request message). In some implementations, UE 102 retains the radio bearers configured by MN 104 and / or SN 106 after receiving the 314A RRC pause message, and MN 104 and / or SN 106 may release or modify one or more of the radio bearers in the RRC recovery message transmitted at event 334A, such that UE 102 releases or modifies (one or more) the radio bearers accordingly. For example, MN 104 may include one or more radio bearer configurations (e.g., one or more RadioBearerConfig information elements) in an RRC recovery message to release, add, or modify one or more radio bearers, causing UE 102 to release, add, or modify (one or more) radio bearers accordingly. MN 104 may receive one or more radio bearer configurations from SN106 and include them in an RRC recovery message.

[0072] At some point after receiving the 334A full SN configuration, UE 102 can use one or more random access configurations from the full SN configuration on cell 126 and perform a 344A random access procedure with SN 106 to connect to SN 106. After UE 102 successfully completes the random access procedure on cell 126, UE 102 can transmit 346A data (user plane data and / or control plane data) through cell 126 in the DC of MN 104 and SN 106. If UE 102 is identified during the random access procedure, SN 106 can transmit 346A data (user plane data or control plane data) with UE 102 according to the full SN configuration received by UE 102 at event 334A. Events 334A, 336A, 338A, 340A, 342A, 344A, and 346A... Figure 3A This is collectively referred to as MR-DC recovery process 360A.

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

[0074] As discussed above, MN 104 and SN 106 may include at least one interface ID of UE 102 in messages transmitted between MN 104 and SN 106. For example, MN 104 may include one or more interface IDs in the SN Modification Request messages transmitted by MN 104 at events 308A and 328A, and in the SN Reconfiguration Complete message transmitted by MN 104 at event 342A. SN 106 may include one or more interface IDs in the SN Modification Request Confirmation messages transmitted by SN 106 at events 312A and 332A.

[0075] In some implementations, MN 104 may also include a second MN configuration in the RRC recovery message transmitted by MN 104 in event 334A. In this case, UE 102 uses the second MN configuration to communicate with MN 104 346A. In one implementation, MN 104 may generate a second MN configuration as a complete MN configuration that completely replaces the first MN configuration. Accordingly, UE 102 can use the complete MN configuration to communicate with MN 104 346A. In another implementation, MN 104 generates a second MN configuration as an incremental MN configuration that supplements only a portion of the first MN configuration. Accordingly, UE 102 uses the incremental MN configuration and the portion of the first MN configuration that is not supplemented by the incremental MN configuration to communicate with MN 104 346A.

[0076] The first MN configuration may include multiple configuration parameters that configure radio resources for UE 102 to communicate with MN 104 via the PCell (e.g., cell 124 or a cell other than cell 124) and zero or more secondary cells (SCells). For example, the first MN configuration may include one or more PHY configurations, one or more MAC configurations, and / or one or more RLC configurations. In another example, the first MN configuration may include one or more measurement configurations. The first MN configuration may include one or more radio bearer configurations that configure one or more radio bearers. UE 102 may receive multiple configuration parameters in one or more RRC messages from MN 104.

[0077] In some implementations, the MN configuration (i.e., the first MN configuration and / or the second MN configuration) includes configuration parameters in an RRCReconfiguration message, RRCReconfiguration-IE, or CellGroupConfig information element (IE) conforming to 3GPP TS 38.331. In one implementation, the MN configuration may be an RRCReconfiguration message, RRCReconfiguration-IE, or CellGroupConfig IE conforming to 3GPP TS 38.331. In other implementations, the MN configuration may include configuration parameters in a RadioResourceConfigDedicated IE, an RRCConnectionReconfiguration message, or an RRCConnectionReconfiguration-IE. In one implementation, the MN configuration may be a RadioResourceConfigDedicated IE, an RRCConnectionReconfiguration message, or an RRCConnectionReconfiguration-IE conforming to 3GPP TS 36.331.

[0078] The SN configuration (e.g., a first SN configuration and / or a second SN configuration) may include multiple configuration parameters that configure radio resources for UE 102 to communicate with SN 106 via PSCell (e.g., cell 126 or a cell other than cell 126) and zero or more SCells. For example, the SN configuration may include one or more PHY configurations, one or more MAC configurations, and / or one or more RLC configurations. The SN configuration may include or may not include one or more measurement configurations. The first SN configuration may not include one or more radio bearer configurations that configure one or more radio bearers. The second SN configuration may be a complete and self-contained configuration (i.e., a complete configuration). UE 102 may communicate with SN 106 using the complete SN configuration without relying on the first SN configuration. UE 102 may receive one or more RRC messages from SN 106 via, for example, via MN 104 or on an SRB (e.g., SRB3) configured to exchange RRC messages between UE 102 and SN 106.

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

[0080] In some implementations where MN 104 is a gNB, the RRC recovery request message, RRC recovery message, and RRC recovery completion message can be RRCResumeRequest, RRCResume, and RRCResumeComplete messages, respectively. In other implementations where MN 104 is an eNB or ng-eNB, the RRC recovery request message, RRC recovery message, and RRC recovery completion message can be RRCConnectionResumeRequest, RRCConnectionResume, or RRCConnectionResumeComplete messages, respectively.

[0081] Next reference Figure 3B Scenario 300B involves another MR-DC recovery process. In Scenario 300B, base station 104 operates as the MN and base station 106 operates as the SN. As mentioned above, events in Scenario 300B similar to those discussed above regarding Scenario 300A are marked with similar reference numerals (e.g., Figure 3A Event 302A and Figure 3B (Event 302B corresponds to). Besides Figure 3B Apart from the differences shown and described below, any alternative implementations (e.g. for messaging and processing) discussed above regarding scenario 300A can be applied to scenario 300B.

[0082] Events 302B, 304B, and 306B can be similar to events 302A, 304A, and 306A, respectively. In response to determining 306B, MN 104 sends a 309B SN Modification Request message to SN 106, which includes an indication to suspend lower layers (e.g., PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B) used for communication with UE 102. In response to the SN Modification Request message, SN 106 suspends lower layers 311B and sends a 312B SN Modification Request Confirmation message to MN 104. In some implementations, SN 106 may release lower layer resources allocated for communication with UE 102 in response to the indication to suspend lower layers. These resources may include software, firmware, memory, and / or processing power of SN 106 for implementing the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with UE 102. For example, SN 106 may allocate processing power from its ASIC, DSP, and / or CPU for communication with UE 102 and release the allocated processing power in response to an instruction to suspend lower layers. In other embodiments, although an instruction to suspend lower layers is received, and although the operation of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers is suspended (i.e., communication with UE 102 is suspended), SN 106 retains the lower-layer resources allocated for communication with UE 102.

[0083] In other implementations, in response to an instruction to suspend a lower layer, SN 106 may retain or release the first SN configuration or a portion thereof. In some implementations, SN 106 may retain at least one interface ID of UE 102 in response to an instruction to suspend a lower layer for exchanging interface messages between MN 104 and SN 106. For example, if the interface between MN 104 and SN 106 is an Xn interface (e.g., as... Figure 1A As shown), then (one or more) interface IDs may include a first UE XnAP ID assigned by SN 106 and a second UE XnAP ID assigned by MN 104. In another example, if the interface between MN104 and SN 106 is an X2 interface, then at least one interface ID may include a first UE X2AP ID assigned by SN 106 and a second UE X2AP ID assigned by MN 104.

[0084] Events 314B, 316B, and 318B can be analogous to events 314A, 316A, and 318A, respectively. Events 302B, 304B, 306B, 309B, 311B, 312B, 314B, 316B, and 318B are... Figure 3B This is collectively referred to as MR-DC pause process 351B.

[0085] Events 320B and 322B can be similar to events 320A and 322A, respectively. In response to the RRC recovery request message received by MN 104 in event 322B, MN 104 can determine that MR-DC has been restored for UE 102. In response to this determination, MN 104 can send a 327B SN modification request message to SN 106, which includes an indication to restore the lower layers (e.g., PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B) used for communication with UE 102. Before sending the 327B SN modification request message, MN 104 determines 324B that UE 102 has released the first SN configuration. As discussed above, MN 104 can determine 324B based on the UE capabilities of UE 102. UE capabilities can indicate that UE 102 cannot retain (i.e., not delete) the SN configuration (i.e., SCG configuration) when initiating an RRC recovery procedure. MN 104 can receive UE capabilities from core network 110 (e.g., AMF 164 or MME 114) or another base station, or it can receive UE capabilities in a UECapabilityInformation message from UE 102 at event 302B. In some implementations, similar to event 328A, MN 104 may send an SN modification request message at 327B that includes an indication to rebuild the lower layer for communicating with UE 102, rather than restoring the lower layer indication.

[0086] If MN 104 determines that UE 102 releases the first SN configuration before radio connectivity is restored (or determines that UE 102 cannot apply the first SN configuration upon restoration of radio connectivity for other reasons), MN 104 includes a full configuration request (e.g., Full Configuration IE) in the SN Modification Request message. The Full Configuration Request is an instruction to SN 106 to provide a full SN configuration. In response to the SN Modification Request message 327B or the Full Configuration Request, SN 106 obtains (e.g., generates) the full SN configuration and sends an SN Modification Request Confirmation message 332B, including the full SN configuration, to MN 104. In some implementations, in response to an instruction to restore a lower layer, SN 106 may allocate lower layer resources for communication with UE 102. These resources may include software, firmware, memory, and / or processing power used by SN 106 to implement the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with UE 102. SN 106 may allocate processing power from its ASIC, DSP, and / or CPU for communication with UE 102. In other embodiments, if SN 106 retains the lower-layer resources allocated for communication with UE 102 despite receiving an indication to suspend lower layers in event 309B, then SN 106 resumes operation of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers, allowing SN 106 to resume communication with UE 102 using the reserved resources. In the latter case, SN 106 may or may not modify the reserved resources before resuming communication.

[0087] In some implementations, based on the fact that MN 104 has instructed SN 106 to suspend the lower layer at event 309B, MN 104 determines that the instruction to resume the lower layer for communication with UE 102 is included in the SN Modification Request message transmitted at event 327B.

[0088] After MN 104 receives the 332B SN Modification Request Confirmation Message, MN 104 can transmit the full SN configuration to UE 102 during MR-DC Recovery Procedure 360B, which can be similar to MR-DC Recovery Procedure 360A. UE 102 can then communicate in the DC with MN 104 and with SN 106 according to the full SN configuration.

[0089] In some implementations, SN 106 may be unable to retain the first SN configuration when its radio connection with UE 102 is suspended, or may be unable to reuse some of the configurations in the first SN configuration after the radio connection with UE 102 is restored. For example, in response to receiving a 309BSN Modification Request message, SN 106 may release the first SN configuration. In such an implementation, based on MN 104's determination that SN 106 has released the first SN configuration or is not reusing some of the configurations, MN 104 includes a full configuration request in the SN Modification Request message sent by MN 104 at event 327B, regardless of whether UE 102 is able to retain the first SN configuration before transitioning to a connected state.

[0090] Next reference Figure 3C In scenario 300C, base station 104 operates as the MN, and base station 106 operates as the SN. Scenario 300C is generally similar to scenario 300B, but SN 106, instead of MN 104, determines that UE 102 releases the first SN configuration. Except... Figure 3C Apart from the differences shown and described below, any alternative implementations (e.g. for messaging and processing) discussed above regarding scenario 300B can be applied to scenario 300C.

[0091] Events 351C, 320C, and 322C can be similar to events 351B, 320B, and 322B, respectively. Subsequently, MN 104 sends an SN Modification Request message (329C) to SN 106, which includes an indication to restore the lower layers used for communication with UE 102. Unlike the message sent by MN 104 in event 327B, the SN Modification Request message does not include a full configuration request because MN 104 is unsure whether UE 102 has released the first SN configuration. Instead, SN 106 determines (325C) that UE 102 has released the first SN configuration before restoring radio connectivity, similar to determination (324B) of MN 104. SN 106 can determine that UE 102 has released the first SN configuration based on UE capabilities. For example, SN 106 can receive UE capabilities from another base station, core network 110, or in the UECapabilityInformation message from UE 102 in event 302C.

[0092] In response to determination 325C, SN 106 obtains (e.g., generates) a complete SN configuration. SN 106 sends an SN modification request confirmation message 333C to MN 104, which includes the complete SN configuration and a complete configuration indication (e.g., indicating to MN 104 that the configuration is a complete SN configuration).

[0093] After MN 104 receives the 333C SN Modification Request Confirmation Message, MN 104 can transmit the full SN configuration to UE 102 during MR-DC Recovery Procedure 360C, which can be similar to MR-DC Recovery Procedure 360B.

[0094] In some implementations, SN 106 may be unable to retain the first SN configuration when suspending radio connection with UE 102, or may be unable to reuse some of the configurations in the first SN configuration after resuming radio connection with UE 102. For example, SN 106 may release the first SN configuration in response to receiving a 309BSN Modification Request message. In such an implementation, the SN obtains (e.g., generates) the complete SN configuration and sends a 333C SN Modification Request Acknowledgment message to MN 104 because SN 106 releases the first SN configuration or does not reuse some of the configurations, regardless of whether UE 102 is able to retain the first SN configuration before transitioning to a connected state.

[0095] Next reference Figure 3D In scenario 300D, base station 104 operates as the MN and base station 106 operates as the SN. Scenario 300D is generally similar to scenario 300B, but MN 104 determines that UE 102 does not release the first SN configuration. Except... Figure 3D Apart from the differences shown and described below, any alternative implementations (e.g. for messaging and processing) discussed above regarding scenario 300B can be applied to scenario 300D.

[0096] Events 351D, 320D, and 322D can be similar to events 351B, 320B, and 322B. Subsequently, MN 104 determines 326D that UE 102 does not release the first SN configuration before (or when) radio connectivity is restored. MN 104 can determine 326D based on UE capabilities (such as UE capabilities received from another base station, core network 110, or UE 102). UE capabilities can indicate, for example, that UE 102 retains (i.e., does not delete) the SN configuration when initiating an RRC recovery procedure. In response to determining 326D, MN 104 sends a 329D SN Modification Request message to SN 106, which includes an indication to restore the lower layer but does not include a full configuration request.

[0097] In some implementations, MN 104 can determine whether SN 106 can retain the first SN configuration when the radio connection with UE 102 is suspended, or can reuse some configurations of the first SN configuration after the radio connection with UE 102 is restored. If SN 106 can retain the first SN configuration when the radio connection with UE 102 is suspended, or can reuse some configurations of the first SN configuration after the radio connection with UE 102 is restored, then as follows Figure 3D As depicted, MN104 sends SN Modification Request Message 329D to SN 106, which includes an indication to restore the lower layer. Otherwise, MN104 sends SN Modification Request Message 329D to SN 106, which includes an indication to rebuild the lower layer, similar to the message sent in Event 328A, or an SN Modification Request Message that includes an indication to restore the lower layer and includes a full configuration request, similar to the message sent in Event 327B.

[0098] In response to receiving message 329D, SN 106 obtains (e.g., generates) an incremental SN configuration and sends message 331D, including the incremental SN configuration, to MN 104. Unlike a full SN configuration (i.e., a complete and self-contained configuration), the incremental SN configuration includes only a subset of the configuration parameters, specifically those that SN 106 is changing relative to the first SN configuration. The incremental SN configuration supplements or modifies a portion of the first SN configuration.

[0099] In response to the RRC recovery request message, MN 104 sends an RRC recovery message (335D) to UE 102, including the incremental SN configuration. In response to the RRC recovery message, UE 102 restores the suspended radio connection with MN 104 (338D) and transitions to a connected state. In response to the RRC recovery message, UE 102 may transmit an RRC recovery completion message (340D) to MN 104, including an RRC reconfiguration completion message. After receiving the 340D RRC recovery completion message, MN 104 sends an SN reconfiguration completion message (342D) to SN 106 to indicate to SN 106 that UE 102 has successfully received or applied the incremental SN configuration. In one implementation, MN 104 may include the RRC reconfiguration completion message from the RRC recovery completion message in the SN reconfiguration completion message.

[0100] UE 102 can use one or more random access configurations from the incremental SN configuration or the portion of the first SN configuration not supplemented by the incremental SN configuration on cell 126 and perform a 344D random access procedure with SN 106 to connect to SN 106. If UE 102 successfully performs the random access procedure, UE 102 communicates with the DC of MN and SN using the incremental SN configuration and the portion of the first SN configuration not supplemented by the incremental SN configuration 346D. Events 335D, 338D, 340D, 342D, 344D, and 346D occur in... Figure 3D This is collectively referred to as the MR-DC recovery process 361D.

[0101] Next reference Figure 3E In scenario 300E, base station 104 operates as the MN and base station 106 operates as the SN. Scenario 300E is generally similar to scenario 300D, but SN 106, instead of MN 104, determines that UE 102 does not release the first SN configuration. Except... Figure 3E Apart from the differences shown and described below, any alternative implementations (e.g. for messaging and processing) discussed above regarding scenario 300D can be applied to scenario 300E.

[0102] Events 351E, 320E, and 322E can be similar to events 351D, 320D, and 322D. MN 104 sends a 329D SN Modification Request message to SN 106, which includes an indication to restore the lower layer used for communication with UE 102. Subsequently, SN 106 determines 330E that UE 102 will not release the first SN configuration until radio connectivity is restored. SN 106 can determine 330E based on UE capabilities (such as UE capabilities received from another base station, core network 110, or UE 102), similar to the determination made by MN 104 in 326D. In response to determining 330E, SN 106 obtains (e.g., generates) an incremental SN configuration and sends a 331E SN Modification Request Confirmation message including the incremental SN configuration to MN 104.

[0103] MN 104 sends an incremental SN configuration to UE 102 at event 361E, which can be similar to MR-DC recovery procedure 361D. UE 102 can then communicate in the DC with MN 104 and SN 106 based on the incremental SN configuration and a portion of the first SN configuration.

[0104] Figures 4A-4E It is similar to Figures 3A-3E The example message sequence, but in which SN 106 includes CU and DU. Therefore, Figures 4A-4E The scene depicted in the text and related to... Figures 3A-3ESimilar events to those discussed are labeled with similar reference numerals (e.g., event 402A is similar to event 302A or 302B, etc.). Apart from the differences shown in the figures and described below, any alternative implementations discussed above with respect to scenarios 300A-E (e.g., for messaging and processing) can be applied to scenarios 400A-E respectively.

[0105] First go to Figure 4A In scenario 400A, base station 104 operates as the MN, and base station 106 operates as the SN, including CU 172 and DU 174. Except that SN 106 includes CU 172 and DU 174, scenario 400A is generally similar to scenario 300A. Therefore, at the beginning of scenario 400A, UE 102 communicates with MN 104 in the DC according to the first MN configuration, with DU 174 according to the first DU configuration, and with CU 172 via DU 174 402A. Then, MN 104 determines 406A to configure UE 102 to enter an inactive state, or an idle state with a suspended radio connection, similar to event 306A.

[0106] In response to determination 406A, MN 104 sends a 408A SN Modification Request message to CU 172. This SN Modification Request message includes an indication to release lower-layer resources (e.g., PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B) used for communication with UE 102. In response to the indication to release lower layers, CU 172 sends a 472A UE Context Release Command message to DU 174. In response to the UE Context Release Command message, DU 174 releases the lower-layer resources allocated for communication with UE 102. These resources may include software, firmware, memory, and / or processing power used by DU 174 to implement the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with the UE. For example, DU 174 can release processing capabilities from its ASIC, DSP, and / or CPU, which are allocated to communicate with UE 102. In example scenario 400A, DU 174 also or alternatively releases the 410A first DU configuration in response to a UE context release command message. DU 174 sends a 474A UE context release complete message to CU 172 in response to the UE context release command message. In some implementations, CU 172 can release at least one interface ID of UE 102 used for exchanging interface messages between CU 172 and DU 174 after receiving the 474A UE context release complete message. Similarly, DU 174 can release at least one interface ID after transmitting the 474A UE context release complete message. For example, at least one interface ID may include a first UE F1AP ID allocated by DU 174 and a second UE F1AP ID allocated by CU 172.

[0107] Then, CU 172 can send a 412ASN modification request confirmation message to MN 104. Except for UE 102 suspending the radio connection between 416A and MN 104 and DU 174, events 414A, 416A, and 418A can be similar to events 314A, 316A, and 318A, respectively. Events 402A, 404A, 406A, 408A, 472A, 410A, 474A, 412A, 414A, 416A, and 418A are... Figure 4A This is collectively referred to as MR-DC pause procedure 450A. Except that UE 102 retains or releases the first DU configuration instead of the first SN configuration, event 420A can be similar to event 320A.

[0108] At a later time, UE 102 sends a 422A RRC Recovery Request message to MN 104, and in response, MN 104 sends a 428ASN Modification Request message to CU 172, including an indication to rebuild the lower layer. As discussed above regarding event 328A, this indication could be to establish the lower layer. For example, MN 104 could send a 428ASN Add Request to another base station that did not previously communicate with UE 102, and that base station might need to (newly) establish the lower layer for communication with UE 102 rather than rebuild the lower layer. The base station responds to the SN Add Request message by sending an SN Add Request Confirmation message to MN 104, including the complete SN configuration.

[0109] In response to receiving the 428ASN modification request, CU 172 sends a 482A UEContext Setup Request message to DU 174. In response to the UEContext Setup Request, DU 174 obtains (e.g., generates) a complete DU configuration for UE 102 to communicate with DU 174. In some implementations, DU 174 may allocate lower-layer resources for communication with UE 102 in response to the UEContext Setup Request. These resources may include software, firmware, memory, and / or processing power used by DU 174 to implement the functionality of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with UE 102. DU 174 may allocate processing power from its ASIC, DSP, and / or CPU for communication with UE 102.

[0110] DU 174 sends a 484A complete DU configuration to CU 172, and CU 172 sends a 432A SN modification request confirmation message including the complete DU configuration to MN 104. During MR-DC recovery procedure 460A, MN 104 transmits the complete DU configuration to UE 102, and UE 102 resumes its suspended radio connections with MN 104 and DU 174. Except for UE 102 releasing the first DU configuration, UE 102 performs a random access procedure with SN 106 by exchanging messages with DU 174 (e.g., random access preamble, random access response, message 3, or message A), and after successfully performing the random access procedure, UE 102 communicates with MN 104 in the DC, with DU 174 according to the complete DU configuration, and with CU 172 via DU 174. MR-DC recovery procedure 460A can generally be similar to MR-DC recovery procedure 360A.

[0111] Next reference Figure 4BIn scenario 400B, base station 104 operates as the MN and base station 106 operates as the SN, including CU172 and DU174. Scenario 400B is generally similar to scenario 400A, but MN 104 determines that UE 102 releases the first DU configuration. Scenario 400B is also generally similar to scenario 300B, but SN 106 includes CU 172 and DU 174.

[0112] Events 402B, 404B, and 406B can be similar to events 402A, 404A, and 406A, respectively. In response to determining 406B, MN104 sends a 409BSN Modification Request message to CU172, which includes an indication to suspend lower layers (e.g., PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B) used for communication with UE 102. In response, CU172 sends a 471B UE Context Modification Request message to DU174, including an indication to suspend lower layers. Accordingly, DU174 suspends 411B lower layers used for communication with UE 102 and sends a 473B UE Context Modification Response message to CU172. In some implementations, DU174 may release the resources allocated for lower layers used for communication with UE 102 in response to the indication to suspend lower layers. These resources may include software, firmware, memory, and / or processing power used by DU 174 to implement the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with UE 102. For example, DU 174 may allocate processing power from its ASIC, DSP, and / or CPU for communication with UE 102, and release the allocated processing power in response to an instruction to suspend lower layers. In other embodiments, despite receiving an instruction to suspend lower layers, and despite suspending the operation of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers (i.e., despite suspending communication with UE 102), DU 174 may retain the lower-layer resources allocated for communication with UE 102. DU 174 may retain or release a first DU configuration or a portion of the first DU configuration in response to an instruction to suspend lower layers. In some implementations, CU 172 may retain at least one interface ID of UE 102 after receiving a 473B UE context modification response message for exchanging interface messages between CU 172 and DU 174. Similarly, DU 174 may retain at least one interface ID after transmitting a 473B UE context modification response message. For example, the at least one interface ID may include a first UE F1AP ID assigned by DU 174 and a second UE F1AP ID assigned by CU 172.

[0113] After receiving the 473B UE context modification response message, CU 172 sends a 412B SN modification request confirmation message to MN 104. Events 412B, 414B, 416B, and 418B can be similar to events 412A, 414A, 416A, and 418A. Events 402B, 404B, 406B, 409B, 471B, 411B, 473B, 412B, 414B, 416B, and 418B are collectively referred to herein as MR-DC pause procedure 451B.

[0114] Events 420B and 422B can be similar to events 420A and 422A, respectively. In response to the RRC recovery request message received by MN 104 in event 422B, MN 104 determines that MR-DC has been restored for UE 102. In response to this determination, MN 104 sends a 427B SN modification request message to CU 172, which includes an indication to restore the lower layers (e.g., PHY202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B) used for communication with UE 102. Before sending the 427B SN modification request message, MN 104 determines 424B that UE 102 has released the first DU configuration. As discussed above, MN 104 can determine 424B based on the UE capabilities of UE 102. For example, MN 104 can receive UE capabilities from core network 110 (e.g., AMF 164 or MME 114) or another base station, or it can receive UE capabilities from UE 102 in the UECapabilityInformation message in event 402B.

[0115] If MN 104 determines that UE 102 releases the first DU configuration before radio connectivity is restored (or determines that UE 102 cannot apply the first DU configuration upon restoration of radio connectivity for other reasons), then MN 104 includes a full configuration request (e.g., a full configuration IE) in the SN modification request message. The full configuration request is an instruction to SN 106 (or more specifically, to DU 174) to provide a full DU configuration. In some implementations, based on MN 104 having already instructed SN 106 to suspend lower layers at event 409B, MN 104 determines that an instruction to restore lower layers for communication with UE 102 at event 427B will be included in the SN modification request message.

[0116] In response to receiving a 427B SN Modification Request message or a Full Configuration Request, CU 172 sends a 481B UE Context Modification Request message to DU 174, including an indication of providing a full configuration. In some embodiments, the UE Context Modification Request message also includes an indication to restore lower-layer resources for communication with the UE. In response to the UE Context Modification Request message, DU 174 obtains (e.g., generates) a full DU configuration and sends a 483B UE Context Modification Response to CU 172, including the full DU configuration. In some embodiments, DU 174 may allocate lower-layer resources in response to the UE Context Modification Request message for communication with UE 102. These resources may include software, firmware, memory, and / or processing power of SN 106 for implementing the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with UE 102. DU 174 may allocate processing power from its ASIC, DSP, and / or CPU for communication with UE 102. In other implementations, if DU 174 retains the lower-layer resources allocated for communication with UE 102 despite receiving an instruction to suspend lower layers in event 409B, then DU 174 resumes operation of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers, allowing DU 174 to resume communication with UE 102 using the reserved resources. In this latter case, DU 174 may or may not modify the reserved resources before resuming communication.

[0117] In some implementations, MN 104 may send a 427B SN Modification Request message, which includes an indication to rebuild the lower layer used for communication with UE 102 instead of restoring the lower layer indication, similar to event 428A. In such an implementation, CU 172 may send a 481B UE Context Modification Request message to DU 174, and DU 174 may respond by sending a 483B UE Context Modification Response message to CU 172. Alternatively, instead of the messages exchanged by CU 172 and DU 174 in 481B and 483B, CU 172 may send a UE Context Setup Request message to DU 174, and DU 174 may respond by sending a UE Context Setup Response message to CU 172, similar to events 482A and 484A.

[0118] After receiving the UE context modification response 483B including the full DU configuration, CU 172 sends the SN modification request confirmation message 432B including the full DU configuration to MN 104.

[0119] In some implementations, based on MN 104 having indicated to SN 106 to suspend lower layers at event 409B, MN 104 determines in the SN Modification Request message that the indication to resume lower layers for communication with UE 102 at event 427B will be included. MN 104 may transmit the full DU configuration to UE 102 during MR-DC recovery procedure 460B, which may be similar to MR-DC recovery procedure 460A. UE 102 can then communicate with MN 104 in the DC, with DU 174 according to the full DU configuration, and with CU 172 via DU 174.

[0120] As discussed above, CU 172 and DU 174 may include at least one interface ID of UE102 in messages transmitted between CU 172 and DU 174. For example, CU 172 may include one or more interface IDs in the UE context modification request messages transmitted by CU 172 in events 471B and 481B. DU 174 may include one or more interface IDs in the UE context modification response messages transmitted by DU 174 in events 473B and 483B.

[0121] Next reference Figure 4C In scenario 400C, base station 104 operates as the MN, and base station 106 operates as the SN, including CU172 and DU 174. Scenario 400C is generally similar to scenario 400B, but SN 106 (more specifically, CU 172) determines that UE 102 releases the first DU configuration. Scenario 400C is also generally similar to scenario 300C, but SN 106 includes CU172 and DU 174.

[0122] Events 451C, 420C, and 422C can be similar to events 451B, 420B, and 422B, respectively. Subsequently, MN 104 sends an SN modification request message 429C to CU172, including an indication to restore the lower layer. CU 172 determines 425C that UE 102 releases the first DU configuration before radio connectivity is restored (or determines that UE 102 cannot apply the first DU configuration upon restoration of radio connectivity for other reasons), similar to determination 424B of MN 104. CU 172 can determine that UE 102 releases the first DU configuration based on UE capabilities of UE 102. For example, CU 172 can receive UE capabilities from DU 174, another base station, core network 110, or from the UE capability information message from UE 102 in event 402C.

[0123] In response to determination 425C, CU 172 sends a UE context modification request message 481C, including a full configuration request, to DU 174. The UE context modification request may also include an indication to restore the lower layer used for communication with UE 102. DU 174 obtains (e.g., generates) the full DU configuration for UE 102 to communicate with DU 174 and sends a UE context modification response message 483C, including the full DU configuration, to CU 172. CU 172 sends an SN modification request confirmation message 433C, including the full DU configuration, to MN 104. The SN modification request confirmation message may also include a full configuration indication (e.g., indicating to MN 104 that the configuration is a full DU configuration). MN 104 may transmit the full DU configuration to UE 102 during MR-DC recovery procedure 460C, which may be similar to MR-DC recovery procedure 460B.

[0124] Next reference Figure 4D In scenario 400D, base station 104 operates as the MN and base station 106 operates as the SN, including CU172 and DU174. Scenario 400D is generally similar to scenario 300D, except that SN 106 includes CU172 and DU174. Scenario 400D is also generally similar to scenario 400B, except that MN 104 determines that UE 102 does not release the first DU configuration.

[0125] Events 451D, 420D, and 422D can be similar to events 451B, 420B, and 422B. Subsequently, in scenario 400D, MN104 determines 426D that UE 102 will not release the first DU configuration before radio connectivity is restored. MN 104 can determine 426D based on UE capabilities (such as UE capabilities received from another base station, core network 110, or UE 102). UE capabilities can indicate, for example, that UE 102 retains (i.e., does not delete) the DU configuration when initiating an RRC recovery procedure. In response to determining 426D, MN 104 sends a 429D SN Modification Request message to CU172, which includes an indication to restore the lower layer but does not include a full configuration request.

[0126] In response to receiving message 429D, CU 172 sends a UE context modification request message 486D to DU 174, including an indication to restore the lower layer used for communication with UE 102. In response, DU 174 obtains (e.g., generates) an incremental DU configuration that supplements or modifies a portion of the first DU configuration. DU 174 sends a UE context modification response message 488D to CU 172, including the incremental DU configuration, and CU 172 sends an SN modification request confirmation message 431D to MN 104, including the incremental DU configuration. Based on the UE context modification request message that does not include a full configuration request, DU 174 may include the incremental DU configuration instead of the full DU configuration.

[0127] During MR-DC recovery procedure 461D, MN 104 transmits the incremental DU configuration to UE 102. Except that UE 102 performs a random access procedure with SN 106 by exchanging messages with DU 174, and after successfully performing the random access procedure, UE 102 communicates in the DC with MN 104 (communicating with DU 174 according to the incremental DU configuration and a portion of the first DU configuration, and communicating with CU 172 via DU 174), MR-DC recovery procedure 461D can be generally similar to MR-DC recovery procedure 361D.

[0128] Next reference Figure 4E In scenario 400E, base station 104 operates as the MN and base station 106 operates as the SN, including CU172 and DU174. Scenario 400E is generally similar to scenario 400D, but CU172, instead of MN 104, determines that UE102 does not release the first DU configuration. Scenario 400E is also generally similar to scenario 300E, but SN 106 includes CU172 and DU174.

[0129] Events 451E, 420E, and 422E can be similar to events 451D, 420D, and 422D. MN 104 sends a 429D SN Modification Request message to CU 172, which includes an indication to restore the lower layer used for communication with UE 102. Subsequently, CU 172 determines 430E that UE 102 will not release the first DU configuration until radio connectivity is restored. CU 172 can determine 430E based on UE capabilities (such as UE capabilities received from DU 174, another base station, core network 110, or UE 102). Events 486E, 488E, 431E, and 461E can be similar to events 486D, 488D, 431D, and 461D, respectively.

[0130] Figures 5A-5E It is similar to Figures 4A-4EThe example message sequence, but in which the portion from a single base station acts as both the MN and SN. Accordingly, Figures 5A-5E The scenes depicted in the text are related to... Figures 4A-4E Similar events discussed are labeled with similar reference numerals in the accompanying figures. Apart from the differences shown in the figures and described below, any alternative implementations discussed above regarding scenarios 400A-E (e.g., for messaging and processing) can be applied to scenarios 500A-E respectively. As an example difference, Figures 5A-5E MN and SN in the text do not need to be as follows Figures 3A-4E They exchange SN modification request and SN modification request confirmation messages in the same way.

[0131] Go to Figure 5A In scenario 500A, base station 106 operates as both MN and SN, where MN includes the CU (e.g., CU 172) and first DU (e.g., DU 174A among one or more DU 174, referred to herein as M-DU 174A), and SN includes the same CU and a second different DU (e.g., DU 174B among one or more DU 174, referred to herein as S-DU 174B). Scenario 500A is generally similar to scenario 400A, except that a single base station 106 includes both MN and SN.

[0132] Initially, UE 102 is configured with M-DU 174A using the first M-DU, with S-DU 174B using the first S-DU, and communicates with CU 172 via M-DU 174A and S-DU 174B in the DC 502A. Similar to events 306A and 406A, CU 172 determines that 506A configures UE 102 to enter an idle or inactive state with a suspended radio connection. In response to determining 506A, CU 172 sends a UE context release command message 572A to S-DU 174B, which causes S-DU 174B to release the lower layers (e.g., PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B) used for communication with UE 102. These resources may include the software, firmware, memory, and / or processing power of the S-DU 174B used to implement the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC206A / 206B layers for communication with the UE. For example, the S-DU 174B can release processing power from the ASIC, DSP, and / or CPU of the S-DU 174B allocated for communication with the UE 102. In scenario 500A, in response to the UE context release command message, the S-DU 174B also or alternatively releases the 510A first S-DU configuration. In response to the UE context release command message, the S-DU 174B sends a 574A UE context release complete message to the CU 172.

[0133] In some implementations, in response to determination 506A, CU 172 sends a UE context release command message to M-DU 174A, which causes M-DU 174A to release lower-layer resources (e.g., PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B) used for communication with UE 102. These resources may include software, firmware, memory, and / or processing power used by M-DU 174A to implement the functions of the PHY 202A / 202B, MAC 204A / 204B, and / or RLC 206A / 206B layers for communication with the UE. For example, M-DU 174A may release processing power from its ASIC, DSP, and / or CPU allocated for communication with UE 102. In scenario 500A, in response to the UE context release command message, M-DU 174A also or alternatively releases a first M-DU configuration. In response to the UE context release command message, the M-DU 174A sends a UE context release complete message to the CU 172.

[0134] Subsequently, CU 172 sends a 513A RRC inactivity message to M-DU 174A, and M-DU 174A in turn sends a 514A RRC pause message to UE 102. Events 516A and 518A can be similar to events 416A and 418A, where UE 102 pauses the radio connection of 516A with MN and SN, and retains the first M-DU configuration of 518A. Events 502A, 506A, 572A, 510A, 574A, 513A, 514A, 516A, and 518A are... Figure 5A This is collectively referred to as MR-DC pause procedure 550A. Event 520A can be similar to event 420A, in which UE 102 retains or releases the first S-DU configuration.

[0135] Subsequently, UE 102 sends a 522A RRC recovery request message to M-DU 174A, and M-DU 174A in turn sends a 523ARRC recovery request message to CU 172. In some implementations, CU 172 sends a 562A UE context setting request message to M-DU 174A, and M-DU 174A responds by sending a 563A UE context setting response message to CU 172.

[0136] Events 582A and 584A can be similar to events 482A and 484A, wherein CU 172 receives 584A a complete S-DU configuration from S-DU 174B for UE 102 to use for communication with S-DU 174B. CU 172 transmits 564A an RRC recovery message including the complete S-DU configuration to M-DU 174A, and M-DU 174A transmits 534A an RRC recovery message to UE 102. In response to the RRC recovery message, UE 102 releases 536A a first S-DU configuration, restores 538A a suspended radio connection with M-DU 174A, and transitions to a connected state. In response to the RRC recovery message, UE 102 can transmit 540A an RRC recovery completion message including an RRC reconfiguration completion message to M-DU 174A. After receiving the 540A RRC recovery complete message, the M-DU 174A can send the 566A RRC recovery complete message to the CU 172. Events 534A, 536A, 538A, and 540A can be similar to events 334A, 336A, 338A, and 340A, respectively.

[0137] After receiving the 534A full S-DU configuration, UE 102 can perform a random access procedure 544A with S-DU 174B using one or more random access configurations from the full S-DU configuration, similar to random access procedure 344A. After successfully performing the random access procedure, UE 102 communicates 546A with M-DU 174A in the DC, with S-DU 174B according to the full S-DU configuration, and with CU 172 via M-DU 174A and S-DU 174B. Events 564A, 534A, 536A, 538A, 540A, 566A, 544A, and 546A occur in... Figure 5A This is collectively referred to as MR-DC recovery process 560A.

[0138] Next reference Figure 5B Scenario 500B involves another MR-DC recovery process, in which base station 106 operates as both MN and SN. The MN includes CU 172 and a first DU 174A, and the SN includes CU 172 and a second DU 174B. Scenario 500B is generally similar to Scenario 500A, except that CU 172 determines that UE 102 releases the first S-DU configuration. Apart from base station 106 including MN and SN, Scenario 500B is also generally similar to Scenario 400B.

[0139] Events 502B and 506B can be similar to events 502A and 506A, respectively. Subsequently, CU 172 sends a 571B UE Context Modification Request message to S-DU 174B, which includes an indication to suspend the lower layer used for communication with UE 102. In response, S-DU 174B suspends the 511B lower layer, similar to event 411B. After suspending the lower layer, S-DU 174B transmits a 573B UE Context Release Complete message to CU 172.

[0140] Events 513B, 514B, 516B, and 518B can be analogous to events 513A, 514A, 516A, and 518A, respectively. Events 502B, 506B, 571B, 511B, 573B, 513B, 514B, 516B, and 518B are collectively referred to in this document as MR-DC pause procedure 551B.

[0141] Events 520B, 522B, 523B, 562B, and 563B can be similar to events 520A, 522A, 523A, 562A, and 563A, respectively. Subsequently, CU 172 determines that UE 102 releases the first DU configuration before restoring radio connectivity, similar to event 424B. In response to determining 524B, CU 172 sends a 581B UE Context Modification Request message to S-DU 174B, which includes an indication to restore the lower layer and a full configuration request. In response, S-DU 174B obtains (e.g., generates) a full S-DU configuration and transmits a 583B UE Context Modification Response message including the full S-DU configuration to CU 172. During MR-DC recovery process 560B, CU 172 can transmit the full S-DU configuration to UE 102 via M-DU 174A. MR-DC recovery process 560B can be similar to MR-DC recovery process 560A.

[0142] Next reference Figure 5C Scenario 500C involves another MR-DC recovery process, in which base station 106 operates as both MN and SN. MN includes CU 172 and M-DU 174A, and SN includes CU 172 and S-DU 174B. Scenario 500C is generally similar to Scenario 500B, but S-DU 174B instead of CU 172 determines that UE 102 releases the first S-DU configuration. Scenario 500C is also generally similar to Scenario 400C, but base station 106 includes both MN and SN.

[0143] Events 551C, 520C, 522C, 523C, 562C, and 563C can be similar to events 551B, 520B, 522B, 523B, 562B, and 563B, respectively. Subsequently, CU 172 sends a UE context modification request message 581C including an indication to restore the lower layer. S-DU 174B determines 525C that UE 102 releases the first S-DU configuration before restoring radio connectivity, similar to determining 425C. In response, S-DU 174B obtains or generates a complete S-DU configuration. S-DU 174B sends a UE context modification response message 583C including the complete S-DU configuration to CU 172. During MR-DC recovery procedure 560C, CU 172 transmits the complete S-DU configuration to UE 102 via M-DU 174A; MR-DC recovery procedure 560C can be similar to MR-DC recovery procedure 560B.

[0144] Next reference Figure 5DScenario 500D involves another MR-DC recovery process, in which base station 106 operates as both MN and SN. MN includes CU 172 and M-DU 174A, and SN includes CU 172 and S-DU 174B. Scenario 500D is generally similar to Scenario 500B, but CU 172 determines that UE 102 does not release the first S-DU configuration. Scenario 500D is also generally similar to Scenario 400D, but base station 106 includes both MN and SN.

[0145] Events 551D, 520D, 522D, 523D, and 563D can be similar to events 551B, 520B, 522B, 523B, 562B, and 563B, respectively. Subsequently, CU 172 determines 526D that UE 102 will not release the first S-DU configuration before radio connectivity is restored, similar to determination 426D. In response to determination 526D, CU 172 sends a UE context modification request message 586D, including an indication to restore the lower layer, to S-DU 174B. In response to this indication, S-DU 174B obtains or generates an incremental S-DU configuration for UE 102 and transmits a UE context modification response message 588D, including the incremental S-DU configuration, to CU 172.

[0146] Except that the DU configuration is an incremental S-DU configuration, events 565D and 535D can be similar to events 564A and 534A, respectively. Events 538D, 540D, and 566D can be generally similar to events 538A, 540A, and 566A, respectively. Except that UE 102 performs a random access procedure with S-DU 174B using the random access configuration in the incremental S-DU configuration (or a portion of the first S-DU configuration not supplemented by the incremental SN configuration). UE 102 communicates with M-DU 174A in the DC, with S-DU 174B according to the incremental S-DU configuration and the portion of the first DU configuration not supplemented by the incremental SN configuration, and with CU 172 via M-DU 174A and S-DU 174B in event 546D. Events 565D, 535D, 538D, 540D, 566D, 544D, and 546D are collectively referred to in this paper as MR-DC recovery procedure 561D.

[0147] Next reference Figure 5EScenario 500E involves another MR-DC recovery process, in which base station 106 operates as both MN and SN. MN includes CU 172 and M-DU 174A, and SN includes CU 172 and S-DU 174B. Scenario 500E is generally similar to Scenario 500D, but S-DU 174B instead of CU 172 determines that UE 102 does not release the first S-DU configuration. Scenario 500E is also generally similar to Scenario 400E, but base station 106 includes both MN and SN.

[0148] Events 551E, 520E, 522E, 523E, 562E, 563E, and 586E can be similar to events 551D, 520D, 522D, 523D, 562D, 563D, and 586D, respectively. Instead of CU 172 determining 530E that UE102 does not release the first S-DU configuration, S-DU 174B sends a UE context modification response message 588E to CU 172, including the incremental S-DU configuration. During MR-DC recovery procedure 561E, CU 172 sends the incremental S-DU configuration to UE 102 via M-DU 174A. MR-DC recovery procedure 561E can be similar to MR-DC recovery procedure 561D.

[0149] Figure 6-22 It is a flowchart depicting a method that a RAN node or UE (such as UE 102) can perform to restore the MR-DC between UE 102 and RAN 105.

[0150] Figure 6 This is a flowchart depicting a method 600 for restoring MR-DC with a UE (e.g., UE 102), which may be implemented by an MN (e.g., MN 104) of this disclosure. At block 602, the MN sends an SN modification request message to an SN (e.g., to SN 106 or a node of SN 106, such as CU 172), the SN modification request message including an indication to release or suspend lower-level communication with the UE (e.g., events 308A, 309B, 408A, or 409B, or similar events within processes 351C, 351D, 351E, 451C, 451D, or 451E). At block 604, the MN transmits an RRC suspension message to the UE to suspend the radio connection between the UE and the MN and SN (e.g., events 314A, 314B, 414A, or 414B, or similar events within processes 351C, 351D, 351E, 451C, 451D, or 451E). Next, at box 606, the MN receives an RRC recovery request message from the UE to restore radio connectivity with the RAN (e.g., event 322A-E or 422A-E).

[0151] In response to the RRC recovery request, the MN sends an SN modification request message to the SN at block 608. This SN modification request message includes an indication to rebuild, establish, or restore the lower layer used for communication with the UE (e.g., 328A, 327B, 329C, 329D, 329E, 428A, 427B, 429C, 429D, or 429E). At block 610, the MN receives an SN modification request confirmation message from the SN, which includes the SN configuration. This SN configuration can be a full SN configuration or an incremental SN configuration (e.g., events 332A, 332B, 333C, 331D, 331E, 432A, 432B, 433C, 431D, or 431E). Next, at block 612, the MN transmits an RRC recovery message to the UE, including the full SN configuration, in response to the RRC recovery request message (e.g., event 334A or 335D, or a similar event within procedures 360B, 360C, or 361E).

[0152] Figure 7 This is a flowchart depicting a method 700 for responding to an SN modification request message received from an MN, which may be implemented by an SN (e.g., SN 106 and / or one or more nodes of SN 106, such as CU 172 and / or DU 174). At block 702, the SN communicates with the UE (e.g., UE 102) according to a first SN configuration (e.g., events 302A, 302B, 402A, or 402B). In embodiments where the SN includes CU and DU, the SN may communicate with the UE via the DU and with the MN (e.g., MN 104) via the CU, in which case the first SN configuration may be a first DU configuration.

[0153] At a later time, the SN receives an SN Modification Request message related to UE 102 from the MN at box 704. Next, at box 706, the SN determines whether the SN Modification Request message includes an indication to release, suspend, rebuild, or resume the lower layer used for communication with the UE.

[0154] If the SN modification request message includes an indication to release a lower layer (e.g., event 308A or 408A), the process proceeds to box 708. At box 708, the SN releases the first SN configuration and retains the UE interface ID (e.g., event 310A or 410A). At box 710, the SN transmits an SN modification request confirmation message to the MN (e.g., event 312A or 412A).

[0155] If the SN modification request message includes an indication to rebuild or restore a lower layer (e.g., events 328A, 327B, 329C, 329D, 329E, 428A, 429C, 429D, or 429E), the process proceeds to block 712. If, for example, between blocks 702 and 704, the SN receives an earlier SN modification request including an indication to release or pause a lower layer, the SN modification request message may include such an indication. At block 712, the SN generates a second SN configuration, which may be a full configuration or an incremental configuration, and may or may not be a DU configuration, depending on the implementation. At block 714, the SN transmits an SN modification request confirmation message including the second SN configuration to the MN (e.g., events 332A, 332B, 333C, 331D, 331E, 432A, 432B, 433C, 431D, or 431E).

[0156] If the SN modification request message includes an indication to pause lower levels (e.g., event 309B or 409B, or a similar event within processes 351C, 351D, 351E, 451C, 451D, or 451E), the process proceeds to box 716. At box 716, the SN transmits an SN modification request confirmation message to the MN (e.g., event 312B or 412B, or a similar event within processes 351C, 351D, 351E, 451C, 451D, or 451E).

[0157] In some implementations, method 700 omits the path to blocks 708 / 710 or the path to block 716. In implementations where the SN modification request message cannot include an indication to pause lower levels, for example, the SN may determine whether to proceed to block 708 or block 712 only at block 706.

[0158] Figure 8This is a flowchart depicting a method 800 for facilitating the recovery of MR-DC using a full or incremental SN configuration, which may be implemented by an MN (e.g., MN 104). At block 802, the MN sends an SN modification request message to the SN (e.g., SN 106 or a node of SN 106, such as CU 172), which includes an indication to release or suspend lower-layer communication with the UE (e.g., UE 102) (e.g., events 308A, 309B, 408A, or 409B, or similar events within processes 351C, 351D, 351E, 451C, 451D, or 451E). At block 804, the MN transmits an RRC suspension message to the UE to suspend the radio connection between the UE and the MN and SN (e.g., events 314A, 314B, 414A, or 414B, or similar events within processes 351C, 351D, 351E, 451C, 451D, or 451E). At a later time, at box 806, the MN receives an RRC recovery request message from the UE to restore radio connectivity with the RAN (e.g., event 322A-E or 422A-E).

[0159] At box 808, the MN determines whether the UE releases the configuration used to communicate with the SN (or a node of the SN, such as DU 174) before restoring radio connectivity with the RAN. If the MN determines that the UE releases the SN configuration before restoring radio connectivity (e.g., event 324B or 424B), the procedure proceeds to box 810. If the MN determines that the UE does not release the SN configuration before restoring radio connectivity (e.g., event 326D or 426D), the procedure proceeds to box 816. The MN may make this determination at box 808 based on the UE's UE capabilities, which the MN may receive from the core network (e.g., core network 110), another base station, or the UE itself.

[0160] If the process proceeds to box 810, the MN sends an SN Modification Request message to the SN, which includes an indication to restore the lower layer used for communication with the UE and includes a full configuration request (e.g., event 327B or 427B). Subsequently, at box 812, the MN receives an SN Modification Request Confirmation message from the SN including the full SN configuration, which can be a full DU configuration (e.g., event 332B or 432B). Next, at box 814, the MN transmits an RRC Restore message to the UE including the full SN configuration (e.g., an event within process 360B or 460B).

[0161] If the process proceeds to box 816, the MN sends an SN Modification Request message to the SN, which includes an indication to restore the lower layer used for communication with the UE and exclude the full configuration request (e.g., event 329D or 429D). Subsequently, at box 818, the MN receives an SN Modification Request Confirmation message from the SN including an incremental SN configuration, which can be an incremental DU configuration (e.g., event 331D or 431D). Next, at box 820, in response to an RRC Resumption Request message, the MN transmits an RRC Resumption message to the UE including the incremental SN configuration (e.g., an event during event 335D or process 461D).

[0162] Figure 9 This is a flowchart of a method 900 for facilitating the recovery of MR-DC using a full or incremental SN configuration, which may be implemented by an SN (e.g., SN 106, or one or more nodes of SN 106, such as DU 174 and / or CU 172). At block 902, the SN communicates with the UE (e.g., UE 102) according to a first SN configuration, which may be a first DU configuration (e.g., events 302A, 302B, 402A, or 402B, or similar events within processes 351C, 351D, 351E, 451C, 451D, or 451E). At block 904, the SN receives an SN modification request message from an MN (e.g., MN 104), which includes an indication to suspend lower-level communication with the UE (e.g., events 309B or 409B, or similar events within processes 351C, 351D, 351E, 451C, 451D, or 451E). At box 906, in response to an instruction to suspend lower layers, the SN suspends lower layers used for communication with the UE (e.g., events 311B or 411B, or similar events within procedures 351C, 351D, 351E, 451C, 451D, or 451E).

[0163] At a later time, in box 908, the SN receives an SN modification request from the MN, which includes an indication to restore the lower-layer configuration used for communication with the UE (e.g., event 329C, 329E, 429C, or 429E). In box 910, the SN determines whether the UE releases the configuration used for communication with the SN (or a node of the SN, such as DU 174) before restoring radio connectivity with the RAN. If the SN determines that the UE releases the SN configuration before restoring radio connectivity (e.g., event 325C or 425C), the process proceeds to box 912. If the SN determines that the UE does not release the SN configuration before restoring radio connectivity (e.g., event 330E or 430E), the process proceeds to box 916. The SN may make this determination in box 910 based on the UE's UE capabilities, which the SN may receive from the core network (e.g., core network 110), another base station, or the UE itself.

[0164] If the process proceeds to box 912, the SN generates a complete SN configuration, which may be a complete DU configuration. At box 914, the SN sends an SN modification request confirmation message (e.g., event 333C or 433C) to the MN, which includes the complete SN configuration.

[0165] If the process proceeds to box 916, the SN generates an incremental SN configuration, which can be an incremental DU configuration. At box 918, the SN sends an SN modification request confirmation message (e.g., event 331E or 431E) to the MN, which includes the incremental SN configuration.

[0166] Figure 10 This is a flowchart of a method 1000 for responding to an SN modification request message received from an MN that includes an indication for releasing a lower layer for a UE. This method can be implemented by a CU of the SN (e.g., CU 172 of SN 106). At block 1002, the CU receives an SN modification request message from the MN (e.g., MN 104) that includes an indication to release a lower layer for communication with the UE (e.g., UE 102) (e.g., event 408A). At block 1004, in response to the indication to release the lower layer, the CU sends a UE context release command for the UE to the DU (e.g., DU 174) (e.g., event 472A). At block 1006, the CU sends an SN modification request confirmation message to the MN (e.g., event 412A).

[0167] Figure 11This is a flowchart of a method 1100 for responding to an SN modification request message received from an MN that includes an indication to suspend lower layers for a UE. This method can be implemented by a CU of the SN (e.g., CU 172 of SN 106). At block 1102, the CU receives an SN modification request message from the MN (e.g., MN 104) that includes an indication to suspend lower layers used for communication with the UE (e.g., UE 102) (e.g., event 409B, or a similar event within procedures 451C, 451D, or 451E). At block 1104, in response to the indication to suspend lower layers, the CU sends a UE context modification request for the UE to a DU (e.g., DU 174) that includes an indication to suspend lower layers used for communication with the UE (e.g., event 471B, or a similar event within procedures 451C, 451D, or 451E). At box 1106, CU sends an SN modification request confirmation message to MN (e.g., event 412B, or a similar event within procedures 451C, 451D, or 451E).

[0168] Figure 12 This is a flowchart of a method 1200 for responding to an SN modification request message received from an MN that includes an indication for rebuilding a lower layer for a UE. This method can be implemented by a CU of the SN (e.g., CU 172 of SN 106). At block 1202, the CU receives an SN modification request message from the MN (e.g., MN 104) that includes an indication for rebuilding a lower layer for communication with the UE (e.g., UE 102) (e.g., event 428A). At block 1204, in response to the indication for rebuilding the lower layer, the CU sends a UE context setting request message for the UE to the DU (e.g., DU 174) (e.g., event 482A). At block 1206, the CU receives a UE context setting response message from the DU that includes a complete DU configuration for the UE (e.g., event 484A). At block 1208, the CU sends an SN modification request confirmation message to the MN that includes the complete DU configuration (e.g., event 432A).

[0169] Figure 13This is a flowchart of a method 1300 for responding to an SN modification request message received from an MN and including an indication for restoring a lower layer for a UE. This method can be implemented by a CU of the SN (e.g., CU 172 of SN 106). At block 1302, the CU receives an SN modification request message from the MN (e.g., MN 104) that includes an indication (e.g., events 427B, 429C, 429D, or 429E) for restoring a lower layer for communication with the UE (e.g., UE 102). At block 1304, in response to the indication for restoring the lower layer, the CU sends a UE context modification request message for the UE to a DU (e.g., DU 174) that includes an indication (e.g., events 481B, 481C, 486D, 486E) for restoring a lower layer for communication with the UE. At box 1306, the CU receives a UE context modification response message from the DU, which includes the DU configuration for the UE. This DU configuration can be a full or incremental DU configuration (e.g., events 483B, 483C, 488D, 488E). At box 1308, the CU sends an SN modification request confirmation message to the MN, which includes the DU configuration (e.g., events 432B, 433C, 431D, 431E).

[0170] Figure 14 This is a flowchart of method 1400 for providing a DU configuration that a UE can use to restore MR-DC to a CU. This method can be implemented by a DU of an SN (e.g., DU 174 or S-DU 174B of base station 106). At block 1402, the DU receives a UE context modification request message from the CU (e.g., CU 172 of base station 106). The UE context modification request message includes an indication to suspend lower-layer communication with the UE (e.g., event 471B or 571B, or a similar event within processes 451C, 451D, 451E, 551C, 551D, or 551E). At block 1404, in response to the indication to suspend lower layers, the DU suspends lower-layer communication with the UE (e.g., event 411B or 511B, or a similar event within processes 451C, 451D, 451E, 551C, 551D, or 551E). At box 1406, the DU receives a UE context modification request message from the CU, which includes an indication to restore the lower layer for communication with the UE and / or includes SpCell IE (e.g., events 481B, 481C, 486D, 486E, 581B, 581C, 586D, or 586E).

[0171] In response to an instruction to restore a lower layer and / or a SpCell IE, the DU generates a DU configuration at block 1408 that includes at least one random access configuration. The DU configuration can be a full configuration or an incremental configuration. At block 1410, the DU sends a UE context modification request confirmation message (e.g., event 483B, 483C, 488D, 488E, 583B, 583C, 588D, or 588E) to the CU, including the DU configuration. At block 1412, after the DU transmits the UE context modification request confirmation message, the DU restores the lower layer used for communication with the UE.

[0172] Go to Figure 15-16 Depending on the implementation method and / or scenario, the UE (e.g., UE 102) may receive configuration parameters from RAN 105 in an RRC recovery message, or may utilize the retained configuration parameters after the MR-DC with RAN 105 is restored.

[0173] For example, in some implementations, the MN (e.g., MN 104) may include one or more configuration parameters in the RRC recovery message (e.g., during events 334A, 335D, 534A, or 535D, or during processes 360B, 360C, 361E, 460A, 460B, 460C, 461D, 461E, 560B, 560C, or 561E) that the UE can use to communicate with the MN and / or SN (e.g., SN 106). For example, one of the configuration parameters may indicate the maximum uplink power that the UE can use to transmit to the MN and / or SN. UE 102 limits uplink transmissions toward the MN or SN to no more than the maximum uplink power indicated by the configuration parameter. In scenarios involving EUTRA / NR DC (EN-DC) or NG-RAN EUTRA / NR DC (NGEN-DC), the configuration parameter may be a p-MaxEUTRA field with a P-Max value. As another example, one of the configuration parameters can indicate the maximum uplink power that the UE can use for transmissions across all cell groups (e.g., across primary and secondary cell groups) to the MN and SN for a specific frequency range. The UE limits uplink transmissions to the MN and SN across the serving cell and across all cell groups for the specific frequency range to not exceed the maximum uplink power indicated by the configuration parameter. In scenarios involving EN-DC or NGEN-DC, the configuration parameter can be the p-MaxUE-FR1 field with a P-Max value. As a further example, one of the configuration parameters can indicate the time instance in which the UE in MR-DC is allowed to transmit to the MN or SN. The UE limits uplink transmissions to the MN or SN according to the indicated time instance. For example, the configuration parameter can be a parameter indicating the time division multiplexing mode, such as the tdm-PatternConfig-r15 field or the tdm-PatternConfig-r16 field in scenarios involving EN-DC or NGEN-DC.

[0174] Figure 15 This is a flowchart of method 1500 for providing power and / or timing parameters to be used by the UE after MR-DC recovery, which may be implemented by an MN (e.g., MN 104). At block 1502, the MN receives an RRC recovery request message from the UE (e.g., UE 102) to restore one or more radio connections (e.g., events 322A-E, 422A-E, or 522A-E). At block 1504, the MN determines whether to restore the UE's MR-DC (i.e., whether to configure the UE to restore MR-DC).

[0175] If the MN determines that the UE's MR-DC needs to be restored, the procedure proceeds to box 1506. At box 1506, the MN generates an RRC recovery message that includes at least one of p-MaxEUTRA, p-MaxUE-FR1, and tdm-PatternConfig. Next, at box 1508, the MN includes the SN configuration in the RRC recovery message. From box 1508, the procedure proceeds to box 1510.

[0176] If the MN determines that it will not restore the UE's MR-DC, the procedure proceeds to box 1512. At box 1512, the MN generates an RRC recovery message excluding at least one of p-MaxEUTRA, p-MaxUE-FR1, and tdm-PatternConfig. From box 1512, the procedure proceeds to box 1510. At box 1510, the MN transmits the RRC recovery message to the UE (e.g., during events 334A, 335D, 534A, or 535D, or during procedures 360B, 360C, 361E, 460A, 460B, 460C, 461D, 461E, 560B, 560C, or 561E).

[0177] Figure 16 This is a flowchart of method 1600 for retaining power and / or timing parameters that the UE can use after the MR-DC is restored, which can be implemented by the UE (e.g., UE 102). Initially, at block 1602, the UE is configured to communicate in the DC of the MN (e.g., MN 104 or CU 172 and M-DU 174A of base station 106) and the SN (e.g., SN 106 or CU 172 and S-DU 174B of base station 106) according to the MN configuration and SN configuration respectively (e.g., similar events within processes 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D or 551E). When communicating in the DC with the MN (e.g., MN104) and the SN, the UE receives at least one of p-MaxEUTRA, p-MaxUE-FR1 and tdm-PatternConfig from the MN at box 1604.

[0178] At box 1606, the UE receives an RRC pause message from the MN (e.g., events 314A, 314B, 414A, 414B, 514A, or 514B, or similar events within procedures 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D, or 551E). At box 1608, in response to the RRC pause message, the UE suspends its radio connections with the MN and SN (e.g., events 316A, 316B, 416A, 416B, 516A, or 516B, or similar events within procedures 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D, or 551E). At a later time, the UE transmits an RRC recovery request message to a base station (e.g., either base station 104 or 106) in block 1610 to restore the suspended radio connection (e.g., events 322A-E, 422A-E, or 522A-E). In response, at block 1612, the UE receives an RRC recovery message indicating the restoration of the suspended radio connection (e.g., events 334A, 335D, 534A, or 535D, or similar events within processes 360B, 360C, 361E, 460A, 460B, 460C, 461D, 461E, 560B, 560C, or 561E).

[0179] At box 1614, the UE determines whether the RRC recovery message configures the UE for MR-DC. If the RRC recovery message configures the UE for MR-DC, the procedure proceeds to box 1616, where the UE retains at least one of the previously received p-MaxEUTRA, p-MaxUE-FR1, and tdm-PatternConfig. The UE can utilize the retained parameters after MR-DC recovery. If the RRC recovery message does not configure the UE for MR-DC, the procedure proceeds to box 1618, where the UE releases at least one of the previously received p-MaxEUTRA, p-MaxUE-FR1, and tdm-PatternConfig.

[0180] Furthermore, a UE (e.g., UE102) communicating in the DC with the MN and SN respectively using the first MN configuration and the first SN configuration can receive RRC recovery messages (e.g., 334A, 335D, 534A or 535D, or similar events within procedures 360B, 360C, 361E, 460A, 460B, 460C, 461D, 461E, 560B, 560C or 561E), which include the second MN configuration and the second SN configuration. If the UE determines that it cannot apply the second MN configuration or the second SN configuration, the UE can implement various techniques.

[0181] As an example, if the UE can comply with the second MN configuration but fails to comply with all or part of the second SN configuration, the UE can communicate with the MN using the second MN configuration but not the second SN configuration. In response to failure to comply with (at least part) the second SN configuration, the UE can transmit an SCG failure information message (e.g., SCGFailureInformationNR message, SCGFailureInformation message, or SCGFailureInformationEUTRA message) indicating the failure of SCG reconfiguration to the MN on the SRB (e.g., SRB1). In such a scenario, the UE can release the second SN configuration.

[0182] Alternatively, in response to failure to comply with at least a portion of the second SN configuration, the UE may initiate an RRC connection re-establishment procedure with the MN. In such a scenario, the UE may release the second SN configuration and the second MN configuration.

[0183] As an alternative, in response to failure to comply with (part of) the second SN configuration, the UE may transition to an idle state without interruption of radio connectivity. The UE does not notify the MN or SN of the transition to the idle state. In response to the state transition to the idle state without interruption of radio connectivity, the UE may release the stored UE context, first MN configuration, second MN configuration, and second SN configuration.

[0184] In other scenarios and implementations, if the UE fails to comply with at least a portion of the second MN configuration, the UE initiates an RRC connection reconstruction procedure with the MN, regardless of whether it succeeds or fails to comply with at least a portion of the second SN configuration. In this case, the UE can release the second SN configuration and the second MN configuration.

[0185] Alternatively, in response to failure to comply with (part of) the second MN configuration, the UE may transition to an idle state without interruption of radio connectivity. The UE does not notify the MN and SN of the transition to the idle state. The UE may release the stored UE context in response to the state transition to an idle state without interruption of radio connectivity. In response to the state transition to an idle state without interruption of radio connectivity, the UE may release the stored UE context, the first MN configuration, the second MN configuration, and the second SN configuration.

[0186] In response to initiating an RRC connection re-establishment procedure, the UE may transmit an RRC re-establishment request message to the MN. In response, the MN may transmit an RRC re-establishment message to the UE. In response to the RRC re-establishment message, the UE may transmit an RRC re-establishment complete message to the MN.

[0187] In some implementations where MN 104 is a gNB, the RRC Re-establishment Request message, RRC Re-establishment message, and RRC Re-establishment Complete message can be the RRCReestablishmentRequest message, RRCReestablishment message, and RRCReestablishmentComplete message, respectively. In other implementations where MN 104 is an eNB or ng-eNB, the RRC Recovery Request message, RRC Recovery message, and RRC Recovery Complete message can be the RRCConnectionReestablishmentRequest message, RRCConnectionReestablishment message, and RRCConnectionReestablishmentComplete message, respectively.

[0188] Figure 17-18 This is a flowchart illustrating an example method that a UE (e.g., UE 102) can implement in response to determining that the UE cannot comply with the MN or SN configuration in the RRC recovery message.

[0189] Figure 17 This is a flowchart of method 1700 that a UE (e.g., UE 102) may implement in response to determining that the UE cannot apply the SN configuration in the RRC recovery message. At block 1702, the UE receives an RRC message (e.g., 334A, 335D, 534A, or 535D, or a similar event within procedures 360B, 360C, 361E, 460A, 460B, 460C, 461D, 461E, 560B, 560C, or 561E) related to the SN (e.g., SN 106). At block 1704, the UE determines that it cannot comply with the RRC message. For example, the UE may determine that it cannot comply with the SN configuration included in the RRC message. At block 1706, the UE determines whether the RRC message is included in the RRC recovery message. If so, the process proceeds to block 1708, where the UE transitions to an idle state without a suspended radio connection. Otherwise, the process proceeds to box 1710, where the UE determines whether it has received an RRC message on SRB3. If an RRC message is received on SRB3, the process proceeds to box 1712, where the UE transmits an SCG failure information message to the MN. Otherwise, the process proceeds to box 1714, where the UE initiates an RRC connection reconstruction procedure with the MN.

[0190] Figure 18This is a flowchart of method 1800, which a UE (e.g., UE 102) may implement in response to determining that the UE cannot apply the MN or SN configuration in the RRC recovery message. At some point before executing method 1800, the UE communicates in the DC with the MN and SN (e.g., MN 104 and SN 106) (e.g., events 302A, 302B, 402A, 402B, 502A or 502B, or similar events within processes 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D or 551E). At box 1802, the UE suspends MR-DC (e.g., events 316A, 316B, 416A, 416B, 516A, or 516B, or similar events within procedures 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D, or 551E). At a later time, the UE transmits an RRC recovery request message to the MN at box 1804 (e.g., events 322A-E, 422A-E, or 522A-E), and receives an RRC recovery message as a response at box 1806 (e.g., events 334A, 335D, 534A, or 535D, or similar events within procedures 360B, 360C, 361E, 460A, 460B, 460C, 461D, 461E, 560B, 560C, or 561E).

[0191] At box 1810, the UE determines whether it cannot comply with all or part of the MN configuration in the RRC recovery message. If the UE cannot comply with all or part of the MN configuration, the procedure proceeds to box 1812, where the UE transitions to an idle state without interrupted radio connections. If the UE can comply with the MN configuration, the procedure proceeds to box 1814, where the UE determines whether it can comply with all or part of the SN configuration in the RRC recovery message. If the UE cannot comply with all or part of the SN configuration, the procedure proceeds to box 1816, where the UE transmits an SCG failure information message to the MN. If the UE can comply with the SN configuration, the procedure proceeds to box 1818, where the UE recovers the MR-DC according to the MN and SN configurations included in the RRC recovery message.

[0192] Figure 19This is a flowchart of a method 1900 for facilitating the recovery of the DC of a UE (e.g., UE 102), which may be implemented by a first node (e.g., MN 104 or CU 172) of a RAN (e.g., RAN 105). At block 1902, the first node transmits a first message (e.g., events 308A, 309B, 408A, 409B, 572A or 571B, or similar events within processes 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D or 551E) to a second node of the RAN (e.g., SN 106, CU 172 of SN 106 or S-DU174B of base station 106) that causes the second node to release or suspend communication with the UE at a lower layer. At block 1904, after transmitting the first message, the first node transmits a second message to the second node that causes the second node to rebuild or restore the lower-level information used for communication with the UE (e.g., events 328A, 327B, 329C, 329D, 329E, 428A, 427B, 429C, 429D, 429E, 582A, 581B, 581C, 586D, or 586E). At block 1906, in response to the second message, the first node receives from the second node a second configuration that the UE will use to communicate with the second node (e.g., events 332A, 332B, 333C, 331D, 331E, 432A, 432B, 433C, 431D, 431E, 584A, 583B, 583C, 588D, or 588E).

[0193] Figure 20 This is a flowchart of a method 2000 for facilitating the recovery of the DC of a UE (e.g., UE 102), which can be implemented by a first node of a RAN (e.g., RAN 105) (e.g., SN 106, CU 172 of SN 106, or S-DU 174B of base station 106). At block 2002, the first node receives a first message (e.g., events 308A, 309B, 408A, 409B, 572A, or 571B, or similar events within processes 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D, or 551E) from a second node of the RAN (e.g., MN 104 or CU 172 of base station 106). At block 2004, the first node responds to the first message by processing hardware to release or suspend the lower layer used for communication with the UE (e.g., events 310A, 311B, 410A, 411B, 510A or 511B, or similar events within processes 351C, 351D, 351E, 451C, 451D, 451E, 551C, 551D or 551E).

[0194] At block 2006, the first node receives a second message from the second node (e.g., events 328A, 327B, 329C, 329D, 329E, 428A, 427B, 429C, 429D, 429E, 582A, 581B, 581C, 586D, or 586E). At block 2008, in response to the second message, the first node (i) rebuilds or restores the lower layer used for communicating with the UE by processing hardware, and (ii) transmits a second configuration for the UE to use for communicating with the first node to the second node (e.g., events 332A, 332B, 333C, 331D, 331E, 432A, 432B, 433C, 431D, 431E, 584A, 583B, 583C, 588D, or 588E).

[0195] Figure 21 This is a flowchart of method 2100 for restoring DC with the RAN, which can be implemented by a UE (e.g., UE 102). At block 2102, the UE operates in DC via a first radio connection to the MN and via a second radio connection to the SN (e.g., block 1602). At block 2104, the UE receives from the MN one or more configuration parameters (e.g., power and / or timing requirements) for communicating with one or both of the primary and secondary nodes (e.g., block 1604). At block 2106, the UE transitions its operational state associated with a protocol for controlling radio resources from a connected state to an inactive state by at least partially suspending the first and second radio connections through hardware processing (e.g., block 1608).

[0196] At box 2108, the UE retains one or more configuration parameters when inactive (e.g., box 1616). Furthermore, at box 2110, when the UE is inactive, the UE receives a command from the RAN to restore radio connectivity with the RAN (e.g., box 1612). At box 2112, after restoring radio connectivity with the RAN, the UE communicates with the primary or secondary node using the retained one or more configuration parameters.

[0197] Figure 22This is a flowchart of method 2200 for restoring DC with the RAN, which can be implemented by a UE (e.g., UE 102). At block 2202, the UE receives a command from the RAN (e.g., from base station 104 or 106 of RAN 105) to restore the suspended DC with the RAN (e.g., block 1702 or block 1806). This command includes at least one configuration for the UE to use to communicate with the RAN's MN or SN. At block 2204, the UE determines through hardware processing that the UE cannot comply with at least a portion of at least one configuration (e.g., blocks 1704, 1810, or 1814). At block 2206, in response to the determination at block 2204, the UE transitions to an idle state (e.g., block 1708 or block 1812) or transmits a failure message to the master node (e.g., block 1816).

[0198] The following list of examples illustrates various embodiments explicitly contemplated in this disclosure.

[0199] Example 1. A method for facilitating the restoration of dual connectivity of a user equipment (UE) in a first node of a radio access network (RAN), the method comprising: transmitting to a second node of the RAN communicating with the UE according to a first configuration a first message causing the second node to release or suspend lower layers for communicating with the UE; transmitting to the second node, after transmitting the first message, a second message causing the second node to rebuild or resume lower layers for communicating with the UE; and, in response to the second message, receiving from the second node a second configuration for the UE to use for communicating with the second node.

[0200] Example 2. According to the method described in Example 1, wherein the second message instructs the second node to restore the lower layer.

[0201] Example 3. The method according to Example 2 further includes: determining, by the processing hardware of the first node, whether the UE releases the first configuration before radio connectivity is restored; and generating a second message by the processing hardware, wherein generating the second message includes or excludes a request to provide full configuration based on whether the UE releases the first configuration before radio connectivity is restored.

[0202] Example 4. The method according to Example 3, wherein: determining whether the UE releases the first configuration before restoring radio connectivity includes determining that the UE releases the first configuration; generating the second message includes including a request to provide the full configuration in the second message; and receiving the second configuration includes receiving the full configuration in response to the request to provide the full configuration.

[0203] Example 5. The method according to Example 3, wherein: determining whether the UE releases the first configuration before restoring radio connectivity includes determining that the UE does not release the first configuration; generating the second message includes not including a request to provide the full configuration in the second message; and receiving the second configuration includes receiving the incremental configuration.

[0204] Example 6. According to the method of Example 2, receiving the second configuration includes receiving a third message, the third message including an indication that the second configuration and the second configuration are fully configured.

[0205] Example 7. The method described in Example 2, wherein receiving the second configuration includes receiving an incremental configuration.

[0206] Example 8. The method according to any one of Examples 2-7, wherein: transmitting a first message includes transmitting a first request to modify the UE context; transmitting a second message includes transmitting a second request to modify the UE context; the first node is a central unit of a base station; the second node is a first distributed unit of a base station; the central unit and the first distributed unit together operate as auxiliary nodes supporting dual connectivity with the UE; the central unit and the second distributed unit of the base station together operate as master nodes supporting dual connectivity with the UE; and the second configuration is a configuration for the UE to use to communicate with the first distributed unit.

[0207] Example 9. The method according to any one of Examples 1-7, wherein: transmitting the first message includes transmitting a first auxiliary node modification request; and transmitting the second message includes transmitting a second auxiliary node modification request.

[0208] Example 10. The method according to Example 9, wherein the first node is a first base station operating as a master node supporting dual connectivity with the UE, and the second node is a second base station operating as a secondary node supporting dual connectivity with the UE.

[0209] Example 11. The method according to Example 10, wherein: transmitting the second message includes transmitting the second message to the central unit of the second base station, the second base station further including a distributed unit; receiving the second configuration includes receiving the second configuration from the central unit; and the second configuration is a configuration that the UE wants to use to communicate with the distributed unit.

[0210] Example 12. According to the method described in Example 1, wherein: the second message instructs the second node to rebuild the lower layer; and receiving the second configuration includes receiving the full configuration.

[0211] Example 13. The method according to any one of Examples 1 or 12, wherein: transmitting a first message includes transmitting a command to release the UE context; transmitting a second message includes transmitting a request to set the UE context, the request causing a second node to rebuild a lower layer for communicating with the UE; the first node is a central unit of a base station; the second node is a first distributed unit of a base station; the central unit and the first distributed unit together operate as a secondary node supporting dual connectivity with the UE; the central unit and the second distributed unit of the base station together operate as a primary node supporting dual connectivity with the UE; and the second configuration is a complete configuration for the UE to use for communicating with the first distributed unit.

[0212] Example 14. The method according to Example 1 further includes: receiving a request to restore radio connectivity from the UE; and transmitting a second configuration to the UE in response to the request to restore radio connectivity.

[0213] Example 15. The method according to Example 14, wherein the second configuration includes one or more parameters indicating one or both of the power and timing requirements for UE uplink transmission to one or both of the first and second nodes.

[0214] Example 16. A method for facilitating the restoration of dual connectivity of a user equipment (UE) in a first node of a radio access network (RAN), wherein the first node previously communicates with the UE according to a first configuration, the method comprising: receiving a first message from a second node of the RAN; releasing or suspending a lower layer for communicating with the UE via processing hardware of the first node in response to the first message; receiving a second message from the second node; and reconstructing or restoring the lower layer for communicating with the UE via processing hardware in response to the second message, and transmitting a second configuration for the UE to use for communicating with the first node to the second node.

[0215] Example 17. The method according to Example 16, wherein rebuilding or restoring the lower layer used for communicating with the UE includes restoring the lower layer.

[0216] Example 18. The method according to Example 17, wherein: the second message includes a request to provide a full configuration; and transmitting the second configuration includes transmitting the full configuration in response to the request to provide a full configuration.

[0217] Example 19. The method according to Example 17, wherein the second transmission configuration includes a transmission incremental configuration.

[0218] Example 20. The method according to Example 17 further includes: determining, by processing hardware, whether the UE releases a first configuration before restoring radio connectivity, wherein transmitting a second configuration includes transmitting a full configuration or an incremental configuration based on whether the UE releases the first configuration before restoring radio connectivity.

[0219] Example 21. The method according to Example 20, wherein: determining whether the UE releases the first configuration before restoring radio connectivity includes determining that the UE releases the first configuration; and transmitting the second configuration includes transmitting a third message including the full configuration, and in response to determining that the UE releases the first configuration includes an indication that the second configuration is fully configured.

[0220] Example 22. The method according to Example 20, wherein: determining whether the UE releases the first configuration before restoring radio connectivity includes determining that the UE does not release the first configuration; and transmitting the second configuration includes transmitting an incremental configuration in response to determining that the UE does not release the first configuration.

[0221] Example 23. The method according to any one of Examples 17-22, wherein: receiving a first message includes receiving a first request to modify the UE context; receiving a second message includes receiving a second request to modify the UE context; the second node is a central unit of a base station; the first node is a first distributed unit of a base station; the central unit and the first distributed unit together operate as auxiliary nodes supporting dual connectivity with the UE; the central unit and the second distributed unit of the base station together operate as master nodes supporting dual connectivity with the UE; and the second configuration is a configuration for the UE to use to communicate with the first distributed unit.

[0222] Example 24. The method according to any one of Examples 16-22, wherein: receiving the first message includes receiving a first auxiliary node modification request; and receiving the second message includes receiving a second auxiliary node modification request.

[0223] Example 25. The method according to Example 24, wherein: the first message includes an indication to release the lower layer; and the method further includes reserving one or more interface identifiers of the UE for use when dual connectivity with the UE is re-established or restored.

[0224] Example 26. The method according to Example 24, wherein: the first node is a first base station operating as a secondary node supporting dual connectivity with the UE; and the second node is a second base station operating as a primary node supporting dual connectivity.

[0225] Example 27. The method according to Example 16, wherein: rebuilding or restoring the lower layer used for communicating with the UE includes rebuilding the lower layer; and transmitting the second configuration includes transmitting the full configuration.

[0226] Example 28. The method according to Example 27, wherein: receiving a first message includes receiving a command to release the UE context; receiving a second message includes receiving a request to set the UE context; the second node is a central unit of the base station; the first node is a first distributed unit of the base station; the central unit and the first distributed unit together operate as auxiliary nodes supporting dual connectivity with the UE; the central unit and the second distributed unit of the base station together operate as master nodes supporting dual connectivity with the UE; the second configuration is a complete configuration for the UE to use for communication with the distributed units; and releasing or suspending the lower layer used for communication with the UE includes releasing the first configuration according to the first message.

[0227] Example 29. The method according to Example 16, wherein: the first node includes a central unit and a distributed unit that jointly operate as secondary nodes supporting dual connectivity with the UE; receiving a first message includes receiving a first secondary node modification request at the central unit; receiving a second message includes receiving a second secondary node modification request at the central unit; transmitting a second configuration includes transmitting the second configuration from the central unit to the second node; and the second configuration is a configuration that the UE wants to use to communicate with the distributed unit.

[0228] Example 30. The method according to Example 29, wherein releasing or suspending the lower layer used for communicating with the UE includes releasing the lower layer, and wherein the method further includes: in response to a first auxiliary node modification request, transmitting a command to release the UE context from the central unit to the distributed unit.

[0229] Example 31. The method according to Example 30, wherein rebuilding or restoring the lower layer for communicating with the UE includes rebuilding the lower layer, and wherein the method further includes: in response to a second auxiliary node modification request, transmitting a request to set the UE's context from the central unit to the distributed unit; and in response to the request to set the UE's context, receiving at the central unit a complete configuration of the UE to be used for communicating with the distributed unit from the distributed unit.

[0230] Example 32. The method according to Example 29, wherein releasing or suspending the lower layer for communicating with the UE includes suspending the lower layer, and wherein the method further includes: in response to a first auxiliary node modification request, transmitting a first request to modify the context of the UE from the central unit to the distributed unit, the first request to modify the context of the UE including an indication to suspend the lower layer.

[0231] Example 33. The method according to Example 32, wherein rebuilding or restoring the lower layer for communicating with the UE includes restoring the lower layer, and wherein the method further includes: in response to a second auxiliary node modification request, transmitting a second request to modify the context of the UE from the central unit to the distributed unit.

[0232] Example 34. The method according to Example 33, wherein: the second auxiliary node modification request includes a request to provide a full configuration; the second request to transmit the context of the modified UE includes a request to provide a full configuration; and the method further includes receiving the full configuration from the distributed unit at the central unit in response to the second request.

[0233] Example 35. The method according to Example 33 further includes: determining at the central unit whether the UE releases the first configuration before radio connectivity is restored; and requesting or not requesting full configuration from the distributed unit through the central unit based on whether the UE releases the first configuration before radio connectivity is restored.

[0234] Example 36. The method according to Example 35, wherein: determining whether the UE releases the first configuration before restoring radio connectivity includes determining that the UE releases the first configuration; transmitting a second request to modify the context of the UE includes transmitting a request to provide a full configuration; the method further includes receiving a full configuration from a distributed unit at a central unit in response to the second request to modify the context of the UE; and the second configuration is a full configuration.

[0235] Example 37. The method according to Example 35, wherein: determining whether the UE releases the first configuration before restoring radio connectivity includes determining that the UE does not release the first configuration; transmitting a second request to modify the context of the UE includes transmitting a request to restore a lower layer for communicating with the UE without transmitting a request to provide a full configuration; the method further includes receiving an incremental configuration from a distributed unit at a central unit in response to the second request to modify the context of the UE; and the second configuration is an incremental configuration.

[0236] Example 38. The method according to Example 33, wherein: transmitting a second request to modify the context of the UE includes transmitting an indication for the UE to restore a lower layer; the method further includes receiving an incremental configuration from a distributed unit at a central unit; and the second configuration is an incremental configuration.

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

[0238] Example 40. A method for restoring dual connectivity in a radio access network (RAN) in a user equipment (UE), the method comprising: operating in dual connectivity with a primary node via a first radio connection and with a secondary node via a second radio connection; receiving from the primary node one or more configuration parameters for the UE to communicate with one or both of the primary and secondary nodes; transitioning an operational state of the UE associated with a protocol for controlling radio resources from a connected state to an inactive state by, at least in part, suspending the first and second radio connections via the UE's processing hardware; retaining one or more configuration parameters while in the inactive state; receiving from the RAN a command to restore radio connectivity with the RAN while in the inactive state; and communicating with the primary or secondary node using the retained one or more configuration parameters after restoring radio connectivity with the RAN.

[0239] Example 41. The method according to Example 40, wherein at least one of one or more configuration parameters indicates the requirements for UE uplink transmission to one or both of the primary and secondary nodes.

[0240] Example 42. The method according to Example 41, wherein at least one of one or more configuration parameters indicates the maximum power limit for UE uplink transmission.

[0241] Example 43. The method according to Example 41, wherein at least one of one or more configuration parameters indicates timing requirements for UE uplink transmission.

[0242] Example 44. The method according to Example 40, wherein: receiving a command to restore radio connectivity includes receiving a configuration for the UE to use in communicating with a primary or secondary node; and communicating with the primary or secondary node after restoring radio connectivity includes communicating with the primary or secondary node according to the configuration.

[0243] Example 45. A method for restoring dual connectivity in a radio access network (RAN) in a user equipment (UE), the method comprising: receiving from the RAN a command to restore suspended dual connectivity with the RAN, the command including at least one configuration for the UE to use to communicate with a primary node or a secondary node; determining by processing hardware that the UE cannot comply with at least a portion of the at least one configuration; and in response to the determination, transitioning to an idle state or transmitting a failure message to the primary node.

[0244] Example 46. The method according to Example 45, wherein: receiving at least one configuration includes receiving a configuration for the UE to use to communicate with the secondary node; determining that the UE cannot comply with at least a portion of the at least one configuration includes determining that the UE cannot comply with at least a portion of the configuration for the UE to use to communicate with the secondary node; and transitioning to an idle state or transmitting a failure message to the primary node includes transitioning to an idle state.

[0245] Example 47. The method according to Example 45, wherein: receiving at least one configuration includes receiving a first configuration for the UE to use to communicate with a master node and a second configuration for the UE to use to communicate with a secondary node; determining that the UE cannot comply with at least a portion of the at least one configuration includes determining that the UE cannot comply with at least a portion of the second configuration; the method further includes determining that the UE can comply with at least a portion of the first configuration; and transitioning to an idle state or transmitting a failure message to the master node includes transmitting a failure message to the master node.

[0246] Example 48. The method described in Example 47, wherein the failure message indicates that the secondary cell group has failed.

[0247] Example 49. A user equipment (UE) includes processing hardware and is configured to implement the method according to any one of Examples 40-48.

[0248] Additional considerations

[0249] The following additional considerations apply to the above discussion.

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

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

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

[0253] Upon reading this disclosure, those skilled in the art will understand additional and alternative structural and functional designs for restoring MR-DC between the UE and RAN using the principles disclosed herein. Therefore, while specific embodiments and applications have been described and illustrated, it should be understood that the disclosed embodiments are not limited to the precise constructions and components disclosed herein. Various modifications, alterations, and variations that are obvious to those skilled in the art may be made to the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined by the appended claims.

Claims

1. A method for facilitating the restoration of dual connectivity of a user equipment (UE) in a node of a radio access network (RAN), the method comprising: Receive a request from the UE to restore radio connectivity with the UE; Determine whether to restore dual connectivity with the UE; In response to receiving the request, a message is generated instructing the UE to restore radio connectivity with the node, the generation including: In response to determining that dual connectivity should be restored, the message includes an indication for restoring said dual connectivity, wherein the message including said indication causes the UE to retain one or more of the following: (i) previously received p-MaxEUTRA configuration parameters, (ii) previously received p-MaxUE-FR1 configuration parameters, or (iii) previously received tdm-PatternConfig configuration parameters for use in UE uplink transmissions; and In response to determining that dual connectivity should not be restored, the indication is excluded from the message; and The message is transmitted to the UE.

2. The method of claim 1, further comprising, in response to determining that dual connectivity has been restored, including in the message an indication of timing constraints for uplink transmissions of the UE.

3. The method according to any one of the preceding claims, wherein, The message instructs the UE to retain the previously received p-MaxEUTRA configuration parameters.

4. The method according to any one of claims 1-2, wherein, The message instructs the UE to retain the previously received p-MaxUE-FR1 configuration parameters.

5. The method according to any one of claims 1-2, wherein, The determination includes: determining whether to restore multi-radio dual connectivity with the UE.

6. The method according to claim 1, wherein, The node is a first node and the first node determines to restore dual connectivity, the method further includes: Before receiving a request from the UE, a first message is transmitted to a second node of the RAN that communicates with the UE according to a first configuration, causing the second node to release or suspend the lower layer used for communicating with the UE, wherein the lower layer includes one or more of the following: (i) physical PHY layer, (ii) media access control MAC layer, or (iii) radio link control RLC layer; After receiving a request from the UE, determine whether the UE releases the first configuration before restoring radio connectivity; Generate a second message that enables the second node to resume communication with the UE at a lower layer, wherein generating the second message includes or excludes a request to provide a full configuration based on whether the UE releases the first configuration before restoring radio connectivity; In response to the second message, the second configuration to be used by the UE for communicating with the second node is received from the second node; and The message includes the second configuration.

7. The method according to claim 6, wherein: Determining whether the UE releases the first configuration before restoring radio connectivity includes determining whether the UE releases the first configuration; Generating the second message includes including a request to provide full configuration within the second message; and Receiving the second configuration includes receiving the full configuration in response to the request to provide the full configuration.

8. The method according to claim 6, wherein: Determining whether the UE releases the first configuration before restoring radio connectivity includes determining that the UE does not release the first configuration; Generating the second message includes omitting the request to provide full configuration from the second message; and Receiving the second configuration includes receiving incremental configuration.

9. The method according to claim 1, wherein, The node determines to restore dual connectivity with the UE, and the method further includes: After transmitting the message, it operates as the master node to support dual connectivity with the UE.

10. A network node of a radio access network (RAN) configured to implement the method according to claim 1 or any claim 1.

Images