Method and apparatus for recovering radio connection in multi-radio dual connectivity

Abstract

The present disclosure relates to a base station capable of resuming a suspended radio connection between a user equipment (UE) and a radio access network (RAN) receiving a request to resume a suspended radio connection (602) for a UE operating in dual connectivity (DC) with a first master node (MN) and a first secondary node (SN) such that previous configurations related to at least one of the first MN and the first SN are released (604), and sending a command to the UE in an inactive state to resume the suspended radio connection, the command including new configurations related to at least one of the first MN, a second MN, the first SN, or a second SN (606).

Description

Technical Field

[0001] This disclosure generally relates to wireless communications, and more specifically, to processing RRC recovery requests from communication devices. Background Technology

[0002] In some cases, a user equipment (or user gear, typically abbreviated as "UE") can simultaneously utilize the resources of multiple network nodes (e.g., base stations) interconnected via backhaul. When these network nodes support the same radio access technology (RAT) or different RATs, this type of connection is referred to as Dual Connectivity (DC) or Multi-Radio DC (MR-DC), respectively. When the UE operates in DC or MR-DC mode, one base station operates as the master node (MN), while the other base stations operate as secondary nodes (SN). For example, the backhaul may support the Xn interface.

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

[0004] When operating in DC mode, the UE can use several types of SRBs. SRB1 and SRB2 resources allow the UE and MN to exchange MN-related RRC messages and embed SN-related RRC messages, and can be referred to as MCG SRBs. SRB3 resources allow the UE and SN to exchange SN-related RRC messages and can be referred to as SCG SRBs. Decoupled SRBs allow the UE to exchange RRC messages directly with the MN using the 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 that terminates at the MN and uses only the MN's lower-layer resources can be referred to as an MCG DRB; a DRB that terminates at the SN and uses only the SN's lower-layer resources can be referred to as an SCG DRB; and a DRB that terminates at the MCG but uses the lower-layer resources of both the MN and SN can be referred to as a decoupled DRB.

[0005] In some cases, the base station (e.g., MN, SN) and / or CN causes the UE to transition from one state of the Radio Resource Control (RRC) protocol to another. More specifically, the UE can operate in an idle state (e.g., EUTRA-RRC_IDLE, NR-RRC IDLE), where the UE does not have a radio connection with the base station; a connected state (e.g., EUTRA-RRC_CONNECTED, NR-RRC CONNECTED), where the UE has a radio connection with the base station; or an inactive state (e.g., EUTRA-RRC INACTIVE, NR-RRC INACTIVE), where the UE has a suspended radio connection with the base station.

[0006] In some scenarios, a UE can operate in a connected state and subsequently transition to an inactive state. Generally, in the inactive state, the radio connection between the UE and the radio access network (RAN) is suspended. In response to a network-triggered event, such as when the MN pages the UE (e.g., for an incoming phone call), or when the UE is otherwise triggered to transmit data (e.g., for an outgoing phone call, browser launch), the UE can then transition back to the connected state. To perform this transition, the UE can request the MN to restore the suspended radio connection (e.g., by sending an RRC Resume Request message), allowing the MN to configure the UE to operate in the connected state again.

[0007] However, for example, due to UE mobility or other factors affecting signal quality, the RAN and / or the UE may decide to switch from the MN (“old” MN) that communicated with the UE before the radio connection was suspended to another base station. As a result, when the UE attempts to transition back to an active state, the other base station may be more suitable as the MN (“new” MN). Therefore, the UE may send a request to the new MN to resume the suspended radio connection, which may be within the same RAN notification area as the old MN or outside that RAN notification area. In either case, the UE may send the request to resume the radio connection to the new MN instead of the old MN.

[0008] However, the new MN may not be able to reach the old SN, or the UE may no longer support MR-DC. Furthermore, in some cases, the new SN may be more suitable than the old SN for supporting MR-DC at a UE with either the old or new MN. These example scenarios, as well as certain scenarios where the UE continues to communicate with the old MN, require some modifications to the UE's MR-DC operation. Summary of the Invention

[0009] According to the technology disclosed herein, after a UE operating in DC mode with an MN and an SN transitions to an inactive state, the base station can restore the radio connection between the UE and the RAN. To do this, the base station causes at least some of the previous DC configurations to be released. The released configurations may belong to the "old" MN (with which the UE communicated before transitioning to the inactive state), the "old" SN, or both. The base station can then send a command to the UE to restore the radio connection, wherein the new configuration belongs to one or more of the old MN, new MN, old SN, or new SN. The base station that can implement these technologies can be either the old MN or the new MN.

[0010] In some implementations, an old MN that has already selected a new SN can restore its MR-DC configuration with the new SN by adding the new SN and releasing the old SN. The old MN can then send an RRC recovery message to the UE that includes the configurations of both the old MN and the new SN. As yet another example, a new MN can restore its MR-DC configuration with the old SN by adding the old SN and sending an RRC recovery message to the UE that includes the configurations of both the new MN and the old SN. Another example of these techniques is that the new MN restores its MR-DC configuration with the new SN. In this case, the new MN releases the old SN and sends an RRC recovery message to the UE with the new MN and the new SN configurations.

[0011] In some implementations, a new MN that cannot reach the old SN can release its MR-DC configuration with the old SN by switching the SN-terminating bearer to the MN-terminating bearer and sending an RRC recovery message to the UE. The new MN then operates in stand-alone mode, and the UE communicates with the network with a single connection accordingly.

[0012] Example embodiments of these technologies are methods in a base station for restoring a suspended radio connection between a UE and a RAN, which the base station can execute using processing hardware. The method includes receiving a request to restore a suspended radio connection for a UE operating in dual-connectivity DC with an old MN and an old SN. The method also includes releasing a previous configuration associated with at least one of the old MN and old SN. The method further includes sending a command to the UE to restore the suspended radio connection, the command including a new configuration associated with at least one of the old MN, new MN, old SN, or new SN.

[0013] Another example embodiment of these technologies is a base station having processing hardware configured to implement the methods described above.

[0014] Another example embodiment of these technologies is a method for restoring a radio connection to the RAN in a UE suspended during dual connectivity (DC) operation, wherein the UE may use processing hardware to perform the method. The method includes transitioning from a state of connection associated with a protocol for controlling radio resources to an inactive state that includes suspending the radio connection. The method also includes receiving a command to resume the suspended radio connection from an old MN or a new MN when in an inactive state. The command includes a new configuration associated with at least one of the old MN, new MN, old SN, or new SN.

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

[0016] Figure 1A and Figure 1B This is a block diagram of an example system in which one or more base stations and / or UEs can implement the techniques of this disclosure for restoring a suspended radio connection between the UE and the radio access network (RAN);

[0017] Figure 2 This is a message diagram illustrating an example scenario where a new MN resumes RRC connection when the UE is inactive, based on the technology disclosed herein.

[0018] Figure 3 This is a message diagram illustrating an example scenario where, when the UE is in an inactive state, the old MN resumes radio connection with the new SN, according to the technology disclosed herein.

[0019] Figure 4 This is a message diagram illustrating an example scenario where, when the UE is in an inactive state, the new MN resumes radio connection with the old SN, according to the technology disclosed herein.

[0020] Figure 5This is a message diagram illustrating an example scenario where, when the UE is in an inactive state, the new MN resumes radio connection with the new SN, according to the technology disclosed herein.

[0021] Figure 6 This is a flowchart of an example method for restoring a radio connection, which can be used in... Figure 1A or Figure 1B Implemented in the old MN or the new MN; and

[0022] Figure 7 This is a flowchart of an example method for restoring radio connectivity to a radio access network (RAN), which can be implemented in... Figure 1A or Figure 1B Implemented in the UE.

[0023] Specific implementation

[0024] Figure 1A An example wireless communication system 100 is depicted, wherein UE 102 operates in DC with MN 104A and SN 106A of RAN 108, and after UE 102 transitions to an inactive state, MN 104A and / or UE 102 use the techniques of this disclosure to restore the radio connection between UE 102 and RAN 108.

[0025] In different configurations of the wireless communication system 100, MN 104A can be implemented as a primary eNB (MeNB) or primary gNB (MgNB) node, and SN 106A can be implemented as a secondary eNB (SeNB) or secondary gNB (SgNB) node. UE 102 communicates with MN 104A and SN 106A via the same RAT (such as EUTRA or NR) or a different RAT. In some cases, the MeNB or SeNB is implemented as an ng-eNB instead of an eNB. In any case, MN 104A and SN 106A can connect to CN 110, which can be, for example, a 5G core network (5GC) or an evolved packet core (EPC). MN 104A and SN 106A can therefore support the S1 interface for communication with the EPC, or the NG interface for communication with the 5GC. Furthermore, to directly exchange messages during the scenarios discussed below, MN 104A and SN 106A can support the Xn interface.

[0026] like Figure 1AAs shown, MN 104A supports cell 124A, and SN 106A supports cell 126A. Cells 124A and 126A can partially overlap, allowing UE 102 to communicate with MN 104A and SN 106A via DC (throughout this disclosure, "DC" refers to either a single-radio DC or an MR-DC). Generally, RAN 108 can include any suitable number of base stations supporting cells 124A and 126A, and references are given below. Figure 1B Discuss an example configuration of CN 110 connected to an additional base station.

[0027] exist Figure 1A In the example configuration, CN 110 is 5GC. Among other components, 5GC 110 includes a User Plane Function (UPF) 112 and an Access and Mobility Management Function (AMF) 114. Generally, UPF 112 is configured to transmit user plane packets related to audio calls, video calls, Internet services, etc., and AMF 114 is configured to manage mobility management, authentication, registration, paging, and other related functions. 5GC 110 may also include... Figure 1A The Session Management Function (SMF) is not shown in the diagram.

[0028] Although the following examples specifically involve 5GC and certain RAT types, 5G NR and EUTRA, in general, the technologies disclosed herein can also be applied to other suitable core network types and / or radio access technologies.

[0029] MN 104A is equipped with processing hardware 130A, 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. The processing hardware 130A in the example implementation includes an RRC recovery controller 132A, configured to restore the radio connection between UE 102 and RAN 108 with a new DC configuration and / or release a previous DC configuration. SN 106A is equipped with processing hardware 140A, 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. The processing hardware 140A in the example implementation includes an RRC recovery controller 142A, configured to handle an SN add or SN release procedure in response to an RRC recovery request from UE 102. Typically, because base stations can operate as MN or SN in different scenarios, RRC recovery controllers 132A and 142A can implement a similar set of functions and support both MN and SN operations.

[0030] UE 102 is equipped with processing hardware 120, 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 120 includes an RRC recovery controller 122 configured to restore radio connectivity with RAN 108 (e.g., MN 104A).

[0031] Figure 1B Another implementation of network 100 is shown, in which CN 110 is connected to MN 104B and SN 106B in addition to MN 104A and SN 106A. Although not shown to avoid confusion, each of MN 104B and SN 106B is equipped with processing hardware including an RRC recovery controller similar to RRC recovery controller 132A or 142A. MN 104B supports cell 124B, and SN 106B supports cell 126B. As described below, for example, MN 104A and 104B can support inter-MN handover, allowing UE 102 to continue DC operation after releasing the connection with MN 104A and selecting cell 124B of MN 104B.

[0032] Next, refer to Figures 2-5 Discussion in Figure 1A or Figure 1BSeveral example scenarios of base stations operating in the system restoring the radio connection between UE 102 and RAN 108.

[0033] First refer to Figure 2 At the start of scenario 200, UE 102 operates in a 202-connected state with RAN 108 (e.g., EUTRA-RRC_CONNECTED, NR-RRC CONNECTED). SN 106A provides UE 102 with a DRB terminated at SN 106A, i.e., an SN-terminated DRB, enabling UE 102 to transmit data with SN 106A via the SN-terminated DRB and the radio resources of SN 106A. MN 104A can also provide UE 102 with a DRB terminated at MN 104A, i.e., an MN-terminated DRB. Therefore, MN 104A and SN 106A thus support 204DC operation at UE 102.

[0034] In one implementation, to configure a SN-terminated DRB so that UE 102 can communicate with SN 106A, SN 106A sends a higher-layer DC configuration to MN 104A, which in turn sends a higher-layer DC configuration to UE 102. The higher-layer DC configuration can be a RadioBearerConfig, a DRB-ToAddModList, or a DRB-ToAddMod Information Element (IE), which configures the SN-terminated DRB.

[0035] In another implementation, SN 106A sends a low-level DC configuration to MN 104A, which in turn sends the low-level DC configuration to UE 102. The low-level DC configuration can configure the Media Access Control (MAC) entity, logical channels with associated Radio Link Control (RLC) entities, and the primary secondary cell (PSCell). The low-level DC configuration can be the CellGroupConfig of an SCG (e.g., cell 126A). SN 106A can optionally update the low-level DC configuration to UE 102 via radio resources of SN 106A (e.g., SRB3) or via radio resources of MN 104A (e.g., SRB1).

[0036] In some implementations, MN 104A stores the UE context of UE 102 (e.g., the "UE context" defined in the 5G specification). When UE 102 is connected, MN 104A communicates with UE 102 based on the UE context. For example, the UE context may include security keys, MCG (e.g., cell 124A) configuration, radio bearer configuration for the bearer to which MN terminates, higher-layer DC configuration, and / or lower-layer DC configuration. Similarly, in some implementations, SN 106A stores the UE context of UE 102, which may include the higher-layer DC configuration and / or lower-layer DC configuration discussed above. When UE 102 is connected, SN 106A communicates with UE 102 based on the UE context.

[0037] If MN 104A determines that there is no data activity associated with UE 102 (no traffic to or from UE 102), the RRC recovery controller 132A of MN 104A sends a 210RRC inactive message to cause UE 102 to change its state from connected to inactive. In some implementations, if MN 104A is a gNB, the RRC inactive message is an RRCRelease message. In other implementations, if MN 104A is an ng-eNB, the RRC inactive message is an RRCConnectionRelease message.

[0038] Continue to refer to Figure 2 Upon receiving an RRC inactivity message, UE 102 transitions from a connected state to an inactive state (212). In response to a triggering event, such as when the MN (e.g., MN 104A) pages UE 102 (e.g., for an incoming phone call), or when UE 102 otherwise determines to send data (e.g., for an outgoing phone call or when a browser launches), UE 102 can then initiate a transition back to a connected state. Before or at the time of initiating the transition, UE 102 can choose a new cell (e.g., cell 124B) of the new MN (e.g., MN 104B) instead of the old cell (e.g., cell 124A) of the old MN (e.g., MN 104A). In the example scenario, MN 104B is more suitable for serving UE 102 than the old MN because MN 104B is closer to UE 102. As discussed in further detail below, MN 104B can help release the DC configuration associated with MN 104A and SN 104A, allowing UE 102 to operate with MN 104B as an independent base station. Therefore, UE 102 can send a 214RRC recovery request message to MN 104B, enabling MN 104B to configure UE 102 to operate in a connected state again.

[0039] In response to the RRC recovery request message, the RRC recovery controller 132B of MN 104B sends a 216 UE context retrieval request message for UE 102 to MN 104A. In response, the RRC recovery controller 132A of MN 104A includes the stored UE context in the UE context retrieval response message and sends a 218 UE context retrieval response message to MN 104B.

[0040] The content of the retrieved UE context response message can be implementation-specific. In some implementations, MN 104A includes a HandoverPreparationInformation IE or a CellGroupConfig IE in the retrieved UE context response message. In some implementations, before releasing SN 106A, MN 104A performs an SN modification procedure to query the higher-level DC configuration and / or lower-level DC configuration stored as UE context at SN 104A before MN 104A includes the HandoverPreparationInformation IE or CellGroupConfig IE in the retrieved UE context response message. In other implementations, MN 104A does not perform an SN modification procedure at all. In addition, in some implementations, MN 104A includes the UE Context Reference IE at SN 104A in the UE Context Response message (e.g., the UE Context Reference at the S-NG-RAN node, including the Global NG-RAN Node ID and the S-NG-RAN node UE XnAP ID).

[0041] The RRC recovery controller 132B of MN 104B then releases the higher-layer DC configuration and lower-layer DC configuration (if stored), and for the new radio bearer configuration, reconfigures the DRB previously terminated at SN 106A from the bearer terminated at SN to the bearer terminated at MN, causing the DRB to terminate at MN 104B. In some implementations, taking into account the UE context stored and retrieved from MN 104A, the received RRC recovery request message, or other suitable pre-configuration deployment metrics, MN 104B releases the previous configuration with SN 106A based on the determination that MN 104A cannot recover at least one layer of DC configuration for UE 102. In other implementations, MN 104B releases the previous configuration with SN 106A based on the determination that UE 102 is outside the coverage area of ​​SN 106A, for example, based on location measurements performed by MN 104B.

[0042] Subsequently, the RRC recovery controller 132B of MN 104B sends a 222RRC recovery message to UE 102. In some implementations, MN 104B includes a new configuration in the RRC recovery message. For example, the new configuration may include instructions to release higher-layer DC configurations (e.g., release SN-terminated DRBs) and reconfigure the DRBs from SN-terminated bearers to MN-terminated bearers. In some implementations, the new configuration includes one or more of the physical (PHY) layer configuration, MAC layer configuration, or RLC configuration for communication between UE 102 and MN 104B.

[0043] In response to an RRC recovery message, the RRC recovery controller 122 of UE 102 transitions from an inactive state to a connected state (224). The RRC recovery controller 122 releases the higher-layer DC configuration (e.g., SN-terminated DRB) and reconfigures the DRB from an SN-terminated bearer to an MN-terminated bearer. In an implementation where MN 104B includes a new higher-layer DC configuration in the RRC recovery message to replace the existing higher-layer DC configuration, the RRC recovery controller 122 can replace the existing higher-layer DC configuration with the new higher-layer DC configuration. For example, the new higher-layer DC configuration may include instructions to reconfigure one or more (or all) SN-terminated bearers to MN-terminated bearers, allowing UE 102 to reconfigure one or more (or all) SN-terminated bearers to MN-terminated bearers based on the new higher-layer DC configuration. In some implementations, the RRC recovery controller 122 may release the lower-layer DC configuration in response to receiving a 210 RRC inactivity message, receiving a 222 RRC recovery message, or sending a 214 RRC recovery request message.

[0044] In response to the RRC recovery message, the RRC recovery controller 122 sends an indication to MN 104B that UE 102 has restored its radio connection with the RAN according to the new configuration (e.g., an RRC recovery complete message). In some implementations, in response to sending the 226 RRC recovery complete message, the RRC recovery controller 122 releases the lower-layer DC configuration. Therefore, MN 104B has a 242 single connectivity (SC) with UE 102 and communicates with UE 102 via the DRB (i.e., the bearer terminated by the MN).

[0045] Still referencing Figure 2 After sending a 222RRC recovery message or receiving a 226RRC recovery complete message, the RRC recovery controller 132B of MN 104B executes the 231 path update procedure to redirect the user plane connection to the new MN. Specifically, the RRC recovery controller 132B sends a 228 path switching request message to the AMF 114 of CN 110. The AMF 114 then sends a 230 path switching request response message to MN 104B.

[0046] In some implementations, after sending a 222RRC recovery message or receiving a 226RRC recovery complete message, the RRC recovery controller 132B executes the 241UE context release procedure. Specifically, the RRC recovery controller 132B sends a 232UE context release message to MN 104A to release the stored UE context. In response, the RRC recovery controller 132A of MN 104A may optionally send a 234SN release request message (e.g., an S-Node Release Request message) to SN 106A to release SN 106A for UE 102. Upon receiving the SN release request message, the RRC recovery controller 142A may optionally send a 236SN release request confirmation message (e.g., an S-Node Release Request Acknowledge message) to MN 104A as a response.

[0047] After receiving a 232UE context release message from MN 104B or a 236SN release request confirmation message, the RRC recovery controller 132A of MN104A can send a 240UE context release message to SN 106A to release the UE context (e.g., including higher-layer DC configuration and lower-layer DC configuration) stored in SN106A.

[0048] In some implementations, the RRC recovery controller 132B of MN 104B can perform the UE context release procedure 241 before performing the path update procedure 231. In other implementations, the RRC recovery controller 132B can perform the UE context release procedure 241 after performing the path update procedure 231.

[0049] Now for reference Figure 3 At the beginning of scenario 300, UE 102 operates in a state of connection 302 with RAN (e.g., SN 106A and MN 104A), similar to event 202 discussed above. Also similar to event 204 discussed above, MN 104A and SN 106A support 304DC at UE 102.

[0050] If MN 104A determines that there is no data activity associated with UE 102, then the RRC recovery controller 132A of MN 104A sends a 310RRC inactivity message to configure UE 102 with resources to change its state from connected to inactive, similar to event 210 discussed above.

[0051] When RRC recovery controller 122 receives a 310 RRC inactivity message, UE 102 transitions from a connected state to a 312 inactive state, similar to event 212 discussed above. In response to the triggering event, UE 102 can then transition back to a connected state. To perform this transition, UE 102 can send a 314 RRC recovery request message to MN 104A, allowing MN 104A to configure UE 102 to operate again in a connected state. However, UE 102 and / or RAN 108 can determine that a new SN (SN 106B in this example scenario) is more suitable to serve UE 102 than the old SN, rather than resuming operation with the old SN (e.g., SN 106A) using DC. As discussed further in detail below, MN 104A can facilitate the release of the DC configuration associated with SN 104A, allowing UE 102 to operate with both MN 104A and the new SN (e.g., SN 104B).

[0052] In response to receiving the 314RRC recovery request message, the RRC recovery controller 132A of MN 104A determines to restore 315 with SN 106B at UE 102 instead of the old SN 106A's DC. In some implementations, MN 104A determines to use SN 106B based on the received RRC recovery request message or appropriate pre-configured deployment metrics.

[0053] RRC recovery controller 132A may send a 317SN Add Request message (e.g., an S-Node Add Request message) to RRC recovery controller 142B of SN 106B to request SN 106B to allocate resources for UE 102. In some implementations, prior to releasing SN 106A, RRC recovery controller 132A may optionally perform an SN modification procedure to query the higher-layer DC configuration and / or lower-layer DC configuration stored at SN 106A and include the higher-layer DC configuration and / or lower-layer DC configuration in the SN Add Request message. In some implementations, the SN Add Request message may include a security key (SK) for communication between SN 106B and UE 102. SN ).

[0054] Subsequently, the RRC recovery controller 142B of SN 106B sends a 319 SN Add Request Confirmation Message (e.g., an S-Node Add Request Confirmation Message) to the RRC recovery controller 132A of MN 104A. In some implementations, the RRC recovery controller 142B includes the SN configuration in the SN Add Request Confirmation Message. In response, the RRC recovery controller 132A sends a 322 RRC Recovery Message to UE 102 to configure UE 102 with the new configuration from both MN 104A and SN 106B, replacing the previous configuration from MN 104A and SN 106A. In some implementations, the MN configuration includes one or more of the PHY layer configuration, MAC layer configuration, or RLC configuration, and the SN configuration may include the lower-layer DC configuration. In one implementation, the SN configuration may be an RRC reconfiguration message (or an RRC connection reconfiguration message).

[0055] In some implementations, to optionally release the UE context stored at SN 106A, RRC recovery controller 132A sends a 334 SN release request message to RRC recovery controller 142A of SN 106A to release SN 106A for UE 102. In response, RRC recovery controller 142A may send a 336 SN release request confirmation message to RRC recovery controller 132A, similar to events 234 and 236 discussed above. Therefore, the new configuration may include an indication that the DRB terminated at SN 106A has been released. After receiving the 336 SN release request confirmation message, RRC recovery controller 132A may send a 340 UE context release message to RRC recovery controller 142A to release the UE context in SN 106A, similar to event 236 discussed above.

[0056] In response to the RRC recovery message, the RRC recovery controller 122 of UE 102 transitions from an inactive state to a connected state (324) and performs a random access procedure (325) with SN 106B. After applying the MN configuration, the RRC recovery controller 122 sends an RRC recovery complete message (326) to MN 104A, which may then optionally send an SN reconfiguration complete message (327) to the new SN 106B. In some implementations, UE 102 includes the RRC reconfiguration complete message (or RRC connection reconfiguration complete message) in the RRC recovery complete message at event 326, and MN 104A also includes the RRC reconfiguration complete message (or RRC connection reconfiguration complete message) in the SN reconfiguration complete message at event 327. In some implementations, UE 102 sends the RRC recovery complete message to MN 104A before performing a random access procedure with SN 106B. The RRC recovery controller 122 may apply the SN configuration before or after sending the RRC recovery complete message. In some implementations, UE 102 performs the random access procedure according to the random access configuration included in the SN configuration. Therefore, MN 104A supports 342DC at UE 102, where SN 106B communicates with UE 102 via the SN-terminated DRB.

[0057] Still referencing Figure 3 After SN 106B receives the SN reconfiguration complete message, MN 104A can execute the 331 path update procedure to redirect the user plane connection to the new SN. Specifically, MN 104A can send a 328 Protocol Data Unit (PDU) session resource modification indication message to AMF 114, and in response, AMF 114 can execute the 329 bearer modification procedure with UPF 112. Then, UPF 112 can send a 330 end marker packet to SN 106B (via SN 106A and MN 104A) and establish a 332 new path to SN 106B, at least for the bearer terminated by the SN. AMF 114 can send a PDU session resource modification confirmation message to MN 104A to terminate the path update procedure for redirecting the user plane connection to the new SN. Although not shown to avoid confusion, in some implementations, SN 106A may send a secondary RAT data usage report message to SN 106A in response to receiving the 334SN release request message or before receiving the 340UE context release message.

[0058] Now for reference Figure 4At the start of scenario 400, UE 102 operates in a state of connection 402 with RAN 108 (e.g., SN 106A and MN 104A), similar to events 202 and 302 discussed above. Also similar to events 204 and 304 discussed above, MN 104A and SN 106A support 404DC at UE 102.

[0059] If MN 104A determines that there is no data activity associated with UE 102, then the RRC recovery controller 132A of MN 104A sends a 410RRC inactivity message to configure UE 102 with resources to change its state from connected to inactive, similar to events 210 and 310 discussed above.

[0060] Upon receiving an RRC inactivity message, UE 102 transitions from a connected state to an inactive state (412), similar to events 212 and 312 discussed above. In response to the triggering event, UE 102 begins transitioning back to a connected state. Before or during the transition, UE 102 can select a new cell (e.g., cell 124B) of a new MN (e.g., MN 104B) instead of reselecting an old cell (e.g., 124A) of the old MN (e.g., MN 104A). As discussed further below, MN 104B can release the DC configuration associated with MN 104A, allowing UE 102 to operate with MN 104B and SN 106A. Therefore, UE 102 can send a 414 RRC recovery request message to MN 104B, enabling MN 104B to configure UE 102 to operate in a connected state again, similar to event 214 discussed above.

[0061] In response to the RRC recovery request message, the RC recovery controller 132B of MN 104B sends a 416 UE context retrieval request message for UE 102 to MN 104A, similar to event 216 discussed above. In response, the RRC recovery controller 132A of MN 104A includes the stored UE context in the UE context retrieval response message and sends a 418 UE context retrieval response message to MN 104B, similar to event 218 described above.

[0062] Subsequently, MN 104B determines to restore the DC configuration of 415 with SN 106A at UE 102. In some implementations, taking into account the UE context stored and retrieved from MN 104A, received RRC recovery request messages, or appropriate pre-configured deployment metrics, MN 104B determines to use SN 106A based on the determination that MN 104A cannot restore at least one layer of DC configuration for UE 102. In other implementations, MN 104B determines to use SN 106A based on the determination that UE 102 is still within the coverage area of ​​SN 106A, for example, based on location measurements performed by MN 104B.

[0063] The RRC recovery controller 132B of MN 104B can send a 417SN Add Request message (e.g., an S-Node Add Request message) to SN 106A to request SN 106A to allocate resources (e.g., DRB for SN termination) for UE 102. In some implementations, the SN Add Request message may include a security key (SK) for communication between SN 106A and UE 102. SN The SN UE XnAP ID serves as a reference to the UE context stored in SN106A. MN 104B may receive the SN UE XnAP ID in the UE context retrieval response message.

[0064] Subsequently, the RRC recovery controller 142A of SN 106A sends a 419 SN Add Request Confirmation Message (e.g., an S-Node Add Request Confirmation Message) to MN 104B. In some implementations, SN 106A includes the SN configuration in the SN Add Request Confirmation Message. In response, the RRC recovery controller 132B of MN 104B sends a 422 RRC Recovery Message to UE 102 to configure UE 102 with a new configuration from both MN 104B and SN 106A, replacing the previous configuration from MN 104A and SN 106A. The new configuration includes the MN configuration and the SN configuration. In some implementations, the MN configuration includes one or more of the PHY layer configuration, MAC layer configuration, or RLC configuration, and the SN configuration may include the lower-layer DC configuration. In one implementation, the SN configuration may be an RRC reconfiguration message (or an RRC connection reconfiguration message).

[0065] In response to the RRC recovery message, the RRC recovery controller 122 of UE 102 transitions from an inactive state to a connected state (424) and performs a random access procedure (425) with SN 106A. After applying the MN configuration, the RRC recovery controller 122 sends an RRC recovery complete message (426) to MN 104B, which may then optionally send an SN reconfiguration complete message (427) to SN 106A. In some implementations, UE 102 includes the RRC reconfiguration complete message (or RRC connection reconfiguration complete message) in the RRC recovery complete message at event 426, and MN 104A also includes the RRC reconfiguration complete message (or RRC connection reconfiguration complete message) in the SN reconfiguration complete message at event 427. In some implementations, the RRC recovery controller 122 sends the RRC recovery complete message to MN 104B before performing the random access procedure with SN 106A. The RRC recovery controller 122 may apply the SN configuration before or after sending the RRC recovery complete message. In one implementation, UE 102 performs a random access procedure based on the random access configuration included in the SN configuration. Therefore, MN 104B supports 442DC at UE 102, where SN 106A communicates with UE 102 via a SN-terminated DRB.

[0066] Still referencing Figure 4 After sending a 427 SN reconfiguration complete message to SN 106A or receiving a 426 RRC recovery complete message, the RRC recovery controller 132B of MN 104B executes the 431 path update procedure to redirect the user plane connection to the new MN, similar to event 231.

[0067] In some implementations, after sending a 427 SN reconfiguration complete message to SN 106A or receiving a 426 RRC recovery complete message, the RRC recovery controller 132B executes the 441 UE context release procedure, similar to event 241. Therefore, SN 106A may release the MN UE XnAP ID allocated by MN 104A, the UE-related signaling connection (or Xn-C connection) associated with UE 102, the Xn-U connection associated with UE 102, and / or not release the radio resources configured by SN configuration.

[0068] exist Figure 5 At the start of scenario 500, UE 102 operates in a state connected to RAN 108 (e.g., SN 106A and MN 104A) at 502, similar to events 202, 302, and 402 discussed above. Also similar to events 204, 304, and 404 discussed above, MN 104A and SN 106A support DC at UE 102.

[0069] If MN 104A determines that there is no data activity associated with UE 102, then the RRC recovery controller 132A of MN 104A sends a 510RRC inactivity message to configure UE 102 with resources to change its state from connected to inactive, similar to events 210, 310 and 410 discussed above.

[0070] When the RRC recovery controller 122 receives an RRC inactivity message, UE 102 transitions from an inactive state to a connected state (512), similar to events 212, 312, and 412 discussed above. In response to the triggering event, UE 102 can then initiate a transition back to the connected state. Before or during the transition, UE 102 can select a new cell (e.g., cell 124B) of a new MN (e.g., MN 104B) instead of reselecting an old cell (e.g., 124A) of the old MN (e.g., MN 104A). As discussed further in detail below, MN 104B can facilitate the release of DC configurations associated with MN 104A and SN 104A, allowing UE 102 to operate with MN 104B and SN 106B. Therefore, similar to events 214 and 414 discussed above, UE 102 can send an RRC recovery request message (514) to MN 104B.

[0071] In response to the RRC recovery request message, the RRC recovery controller 132B of MN 104B sends a 516 UE context retrieval request message for UE 102 to MN 104A, similar to events 216 and 416 discussed above. In response, the RRC recovery controller 132A of MN 104A includes the stored UE context in a UE context retrieval response message and sends a 518 UE context retrieval response message to MN 104B, similar to events 218 and 418 described above.

[0072] In response, the RRC recovery controller 132B restores the 515DC with SN 106B at UE 102, instead of restoring the DC with SN 106A at UE 102. In some implementations, MN 104B determines to use SN 106B based on the received RRC recovery request message, the UE context stored and retrieved from MN 104A, or appropriate pre-configured deployment metrics. In other implementations, MN 104B determines to use SN 106A based on determining that UE 102 is still within the coverage area of ​​SN 106A, for example, based on location measurements performed by MN 104B.

[0073] The RRC recovery controller 132B can send a 517SN Add Request message (e.g., an S-Node Add Request message) to the SN 106B to request the SN 106B to allocate resources for the UE 102. In some implementations, the SN Add Request message may include a security key (SK) for communication between the SN 106B and the UE 102. SN ).

[0074] Subsequently, the RRC recovery controller 142B of SN 106B sends a 519 SN Add Request Confirmation Message (e.g., an S-Node Add Request Confirmation Message) to MN 104B. In some implementations, the RRC recovery controller 142B includes the SN configuration in the SN Add Request Confirmation Message. In response, the RRC recovery controller 132B sends a 522 RRC Recovery Message to UE 102 to configure UE 102 with parameters associated with MN 104B and SN 106B, replacing the previous configuration from MN 104A and SN 106A. These parameters include the MN configuration and the SN configuration. In some implementations, the MN configuration may include one or more of the PHY layer configuration, MAC layer configuration, or RLC configuration, and the SN configuration may include the lower-layer DC configuration. In one implementation, the SN configuration may be an RRC reconfiguration message (or an RRC connection reconfiguration message).

[0075] In response to the RRC recovery message, the RRC recovery controller 122 of UE 102 transitions from an inactive state to a connection-inactive state (524) and performs a random access procedure (525) with SN 106B. After applying the MN configuration, the RRC recovery controller 122 sends an RRC recovery complete message (526) to MN 104B, which may then optionally send an SN reconfiguration complete message (527) to SN 106B. In some implementations, UE 102 includes the RRC reconfiguration complete message (or RRC connection reconfiguration complete message) in the RRC recovery complete message at event 526, and MN 104A also includes the RRC reconfiguration complete message (or RRC connection reconfiguration complete message) in the SN reconfiguration complete message at event 527. In some implementations, the RRC recovery controller 122 sends the RRC recovery complete message to MN 104A before performing the random access procedure with SN 106B. The RRC recovery controller 122 can apply the SN configuration before or after sending the RRC recovery complete message. In one implementation, UE 102 performs a random access procedure based on the random access configuration included in the SN configuration. Therefore, MN 104B supports 542DC at UE 102, where SN 106B communicates with UE 102 via the SN-terminated DRB.

[0076] Still referencing Figure 5After sending an SN reconfiguration complete message to SN 106B or receiving an RRC recovery complete message, the RRC recovery controller 132B of MN 104B executes the 531 path update procedure. Specifically, MN 104B can send a 528 path switch request to AMF 114, and in response, AMF 114 can perform the 529 bearer modification procedure with UPF 112, similar to... Figure 3 Event 329. UPF 112 establishes at least a new path 530a for MN-terminated bearers to the new MN 104B. UPF 112 establishes at least a new path 530b for SN-terminated bearers to the new SN 106B. UPF 112 may provide MN 104B with a Path Switch Request Acknowledgment message 532 to terminate the path update process used to redirect user plane connections to the new MN and the new SN.

[0077] In some implementations, after sending an SN reconfiguration complete message to SN 106B or receiving an RRC recovery complete message, the RRC recovery controller 132B executes the 541 UE context release procedure, similar to events 241 and 441.

[0078] If the above are Figures 2-5 If the MN 104A or MN 104B discussed herein is an ng-eNB, then the RRC recovery request message is an RRCConnectionResumeRequest message, the RRC recovery message is an RRCConnectionResume message, and the RRC recovery completion message is an RRCConnectionResumeComplete message. If the MN 104A or MN 104B is a gNB, then the RRC recovery request message is an RRCResumeRequest message, the RRC recovery message is an RRCResume message, and the RRC recovery completion message is an RRCResumeComplete message.

[0079] Figure 6 An example method 600 for restoring a suspended radio connection between UE 102 and the RAN is depicted. Method 600 begins at block 602, in which the base station receives a request to restore a suspended radio connection for a UE operating with the DC of the first MN and the first SN. Figures 2-5 Events 214, 314, 414, and 514). In response to this request, in block 604, the base station causes the previously configured information associated with at least one of the first MN and the first SN to be released ( Figures 2-5Events 216, 218, 334, 336, 340, 416, 418, 516, and 518. Subsequently, in box 606, the base station sends a command to UE 102 to restore the suspended radio connection. Figures 2-5 (Events 222, 322, 422, and 522). The command may include a new configuration associated with at least one of the first MN, the second MN, the first SN, or the second SN.

[0080] Figure 7 An example method 700 for restoring a suspended radio connection between UE 102 and RAN is described.

[0081] Method 700 begins at block 702, where the UE operates with DC in conjunction with the first MN and the first SN. Figures 2-5 Events 204, 304, 404, and 504. Then, in box 704, the UE transitions from a connected state to an inactive state associated with protocols used to control radio resources, including suspending radio connections. Figures 2-5 Events 212, 312, 412, and 512. In block 706, when in an inactive state, the UE receives a command from the first MN or the second MN to resume the suspended radio connection. Figures 2-5 (Events 222, 322, 422, and 522). The command may include a new configuration associated with at least one of the first MN, the second MN, the first SN, or the second SN.

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

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

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

[0085] 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.

[0086] By reading this disclosure, those skilled in the art will understand that alternative and alternative structural and functional designs for restoring the radio connection between the UE and the RAN can be derived using the principles disclosed herein. Therefore, although specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise constructions and components disclosed herein. Various modifications, alterations, and variations can be made to the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims, as will be apparent to those skilled in the art.

[0087] Aspect 1. A method in a base station for restoring a suspended radio connection between a user equipment (UE) and a radio access network (RAN), the method comprising: receiving, by processing hardware, a request to restore a suspended radio connection for a UE operating in dual connectivity (DC) with a first primary node (MN) and a first secondary node (SN); by processing hardware, releasing a previous configuration associated with at least one of the first MN and the first SN; and by processing hardware sending to the UE a command to restore the suspended radio connection, the command including a new configuration associated with at least one of the first MN, a second MN, a first SN, or a second SN.

[0088] Aspect 2. The method of aspect 1 implemented in the second MN, wherein releasing the previous configuration includes releasing the DC configuration of the UE so that the UE can operate with the second MN as an independent base station.

[0089] Aspect 3. The method according to aspect 2, wherein the new configuration includes an indication that the data radio bearer (DRB) terminated at the first SN is reconfigured to terminate at the second MN.

[0090] Aspect 4. The method of Aspect 1 implemented in the first MN, wherein: releasing the previous configuration includes releasing the first SN, and the UE operates in DC mode with the first MN and the second SN according to the new configuration.

[0091] Aspect 5. The method of Aspect 1 implemented in the second MN, wherein: releasing the previous configuration includes sending a request to the first MN to release the stored UE context; and the UE operates with the DC of the second MN and the first SN according to the new configuration.

[0092] Aspect 6. The method of Aspect 1 implemented in the second MN, wherein: releasing the previous configuration includes: sending a request to the first MN to release the stored UE context, and releasing the first SN, and the UE operating with the second MN and the second SN according to the new configuration.

[0093] Aspect 7. The method according to aspects 2, 3, 5 or 6 further includes: receiving a stored UE context from a first MN by processing hardware; wherein causing the previous configuration to be released is in response to determining, based on the stored UE context, that the first MN cannot restore the DC configuration of the UE at least one layer.

[0094] Aspect 8. The method according to aspect 7 further includes: in response to receiving an instruction from the UE to restore radio connectivity, sending a request to the first MN to release the stored UE context.

[0095] Aspect 9. The method according to any one of aspects 4-6 further includes: sending a security key for communication between the first or second SN and the UE by processing hardware to the first or second SN.

[0096] Aspect 10. The method according to aspects 2-4 or 6, wherein the new configuration includes an indication that the DRB terminated at the first SN is released.

[0097] Aspect 11. The method according to aspect 4 or 6, the method further comprising: sending a request from processing hardware to a second SN to allocate resources for DC operation of the UE.

[0098] Aspect 12. The method according to aspects 2-4 further includes, before releasing the first SN: querying the first SN by processing hardware to obtain the radio bearer configuration stored at the first SN.

[0099] Aspect 13. The method according to any of the preceding aspects further includes: performing a path handover procedure with the core network (CN) in response to receiving an instruction from the UE to restore radio connectivity.

[0100] Aspect 14. The method according to any of the foregoing aspects, wherein receiving a request to resume a suspended radio connection includes receiving a Radio Resource Control (RRC) Resumption Request message from a UE operating in an inactive state associated with an RRC protocol.

[0101] Aspect 15. The method according to aspect 14, wherein sending a command to the UE to restore a suspended radio connection includes sending an RRC restore message.

[0102] Aspect 16. The method according to any of the preceding aspects, wherein the new configuration includes at least one of the following: (i) physical (PHY) layer configuration, (ii) media access control (MAC) layer configuration, (iii) radio link control (RLC) layer configuration, or (iv) radio bearer configuration.

[0103] Aspect 17. The method according to any of the preceding aspects, wherein the release of the previous configuration is based on at least one of: (i) information in a request to resume a suspended radio connection, (ii) one or more pre-configured deployment metrics, or (iii) the stored context of the UE.

[0104] Aspect 18. A base station including processing hardware and configured to implement the method of any one of aspects 1-17.

[0105] Aspect 19. A method for restoring a suspended radio connection to a radio access network (RAN) under dual connectivity (DC) operation in a user equipment (UE), the method comprising: operating in dual connectivity (DC) with a first primary node (MN) and a first secondary node (SN); having processing hardware transition from a connected state to an inactive state associated with a protocol for controlling radio resources (including suspending the radio connection); and, while in the inactive state, receiving a command from a first MN or a second MN to restore the suspended radio connection, the command including a new configuration associated with at least one of the first MN, the second MN, the first SN, or the second SN.

[0106] Aspect 20. The method according to aspect 19, wherein: a command to resume a suspended radio connection is received from the second MN; the method further comprises: communicating with the second MN, which operates as an independent base station, according to a new configuration, wherein the new configuration includes an indication that a data radio bearer (DRB) terminated at the first SN is reconfigured to be terminated at the second MN.

[0107] Aspect 21. The method according to aspect 19, wherein: a command to resume a suspended radio connection is received from a first MN; the method further comprises: communicating with the DC of the first MN and the second SN according to a new configuration.

[0108] Aspect 22. The method according to aspect 19, wherein: a command to resume a suspended radio connection is received from the second MN; the method further includes: communicating with the DC of the second MN and the first SN according to a new configuration.

[0109] Aspect 23. The method according to aspect 19, wherein: a command to resume a suspended radio connection is received from the second MN; the method further includes: communicating with the DC of the second MN and the second SN according to a new configuration.

[0110] Aspect 24. The method according to any one of aspects 19-23, further comprising: sending an RRC recovery request message associated with a Radio Resource Control (RRC) protocol to a first MN or a second MN, wherein the command to receive the resumption of a suspended radio connection includes receiving an RRC recovery message in response to the sent RRC recovery message.

[0111] Aspect 25. The method according to any one of aspects 19-24, wherein the new configuration includes at least one of the following: (i) physical (PHY) layer configuration, (ii) media access control (MAC) layer configuration, (iii) radio link control (RLC) layer configuration, or (iv) radio bearer configuration.

[0112] Aspect 26. A user equipment (UE) including processing hardware and configured to implement the method described in any one of aspects 19-25.

Claims

1. A method for restoring a suspended radio connection between a user equipment (UE) and a radio access network (RAN), executed in a second master node (MN), the method comprising: The second MN receives a request to restore the suspended radio connection of the UE to dual-connection DC operation with the first MN and the secondary node SN; The second MN sends a request to the first MN to retrieve the stored UE context of the UE; The second MN causes the previous configuration associated with the first MN to be released; The second MN sends a request to the SN to allocate resources for the UE; and The second MN sends a command to the UE to restore the suspended radio connection. The command includes a new configuration associated with the second MN and SN, so that the UE can operate with the DC of the second MN and SN according to the new configuration.

2. The method according to claim 1, further comprising: The second MN receives the stored UE context from the first MN; The release of the previous configuration associated with the first MN is in response to at least one layer of the storage-based UE context determining that the first MN cannot recover the DC configuration of the UE.

3. The method according to claim 2, further comprising: In response to receiving an instruction from the UE to restore radio connectivity, a request to release the stored UE context is sent to the first MN.

4. The method according to claim 1, further comprising: The second MN sends a security key to the SN for communication between the SN and the UE.

5. The method according to any one of claims 1-4, further comprising: In response to receiving an instruction from the UE to restore radio connection, a path handover procedure with the core network CN is performed.

6. The method according to any one of claims 1-4, wherein, Receiving a request to restore a suspended radio connection includes receiving an RRC restore request message from a UE operating in an inactive state associated with the Radio Resource Control (RRC) protocol.

7. The method according to claim 6, wherein, Sending a command to the UE to restore a suspended radio connection includes sending an RRC restore message.

8. The method according to any one of claims 1-4, wherein, The new configuration includes at least one of the following: (i) physical PHY layer configuration, (ii) media access control (MAC) layer configuration, (iii) radio link control (RLC) layer configuration, or (iv) radio bearer configuration.

9. The method according to any one of claims 1-4, wherein, The request to retrieve the stored UE context is sent based on information from the request to resume the suspended radio connection.

10. A base station, comprising processing hardware and configured to implement the method of any one of claims 1-9.

11. A method for restoring a suspended radio connection to a radio access network (RAN) under dual connectivity DC operation, performed in a user equipment (UE), the method comprising: DC operations with the first primary node MN and the secondary node SN; The UE transitions from a connected state to an inactive state associated with protocols used to control radio resources, including suspending radio connections; When inactive, a command to resume the suspended radio connection is received from the second MN, the command including a new configuration associated with the second MN and the SN, and The new configuration is used to communicate with the DC of the second MN and SN.

12. The method of claim 11, further comprising: The UE sends an RRC recovery request message associated with the Radio Resource Control (RRC) protocol to the second MN, wherein the command to receive the resumption of the suspended radio connection includes receiving the RRC recovery message in response to the sent RRC recovery message.

13. The method according to any one of claims 11-12, wherein, The new configuration includes at least one of the following: (i) Physical PHY layer configuration (ii) Media access control MAC layer configuration. (iii) Radio Link Control (RLC) layer configuration, or (iv) Radio bearer configuration.

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

Images