CN118056435A - Configuration management for conditional secondary node addition and modification - Google Patents

Configuration management for conditional secondary node addition and modification Download PDF

Info

Publication number
CN118056435A
CN118056435A CN202280066145.4A CN202280066145A CN118056435A CN 118056435 A CN118056435 A CN 118056435A CN 202280066145 A CN202280066145 A CN 202280066145A CN 118056435 A CN118056435 A CN 118056435A
Authority
CN
China
Prior art keywords
conditional
container
configuration
procedure
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202280066145.4A
Other languages
Chinese (zh)
Inventor
C-H·吴
J·谢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Priority claimed from PCT/US2022/039405 external-priority patent/WO2023014872A1/en
Publication of CN118056435A publication Critical patent/CN118056435A/en
Pending legal-status Critical Current

Links

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

A Master Node (MN) may implement a method for managing conditional procedures involving a User Equipment (UE), a candidate secondary node (C-SN), and the MN. The method may include: transmitting a request to the C-SN to perform a conditional procedure related to the C-SN and the UE, the conditional procedure being associated with a condition and a conditional configuration according to which the UE is connected to the C-SN when the condition is satisfied; receiving a response to the request from the C-SN, the response including an SN-to-MN container; and retrieving the conditional configuration from the SN to MN container.

Description

Configuration management for conditional secondary node addition and modification
Technical Field
The present disclosure relates generally to wireless communications, and more particularly to managing conditional procedures for multiple connections, such as conditional secondary node addition or modification procedures.
Background
The background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
In a telecommunication system, user Equipment (UE) may sometimes utilize resources of multiple Radio Access Network (RAN) nodes, such as components of a base station or a distributed base station, simultaneously, interconnected by a backhaul. The simultaneous use of two base stations is known as Dual Connectivity (DC) and is standardized for LTE (i.e. "long term evolution" wireless mobile network) communication systems. In a 5G (standardized 5 th generation wireless network) communication system, multiple Connectivity (MC) refers to the simultaneous use of multiple independent communication paths, nodes, access points or base stations to transmit data to a UE. For simplicity, in this document, the term "dual connectivity" also encompasses "multiple connectivity". The network nodes serving the same UE may all be nodes using the same Radio Access Technology (RAT) or may include nodes using different RATs. Exemplary DC configurations include NR-only dual connectivity (NR-DC) and EUTRA and NR dual connectivity (EN-DC). When the UE operates in DC, one base station acts as a primary node (MN) covering a primary cell (PCell), and the other base station acts as a Secondary Node (SN) covering a primary secondary cell (PSCell). The UE communicates with the MN (via PCell) and SN (via PSCell). In other scenarios, the UE utilizes resources of one network node at a time in a Single Connection (SC).
The third generation partnership project (3 GPP) specification TS 37.340v16.6.0 describes a procedure in which a UE adds or alters SN in a DC scenario. These procedures involve messaging (e.g., RRC signaling and preparation) between RAN nodes. Such messaging typically causes delays, thereby increasing the likelihood of failure of the SN addition or SN modification process. These legacy procedures that do not involve the conditions checked at the UE may be referred to as "on-the-fly" SN addition and SN modification procedures.
Recently, for both SN or PSCell addition/change, a "conditional" procedure (i.e., conditional SN or PSCell addition/change) has been considered. Unlike the "instant" procedure discussed above, these conditional procedures do not add or alter SN or PSCell until the UE determines that the condition is met. As used herein, the term "condition" may refer to a single detectable state or event (e.g., a particular signal quality metric exceeding a threshold), or to a logical combination of such states or events (e.g., "condition a and condition B" or "(condition a or condition B) and condition C", etc.).
To configure the conditional procedure, the RAN provides the UE with the conditions and configurations (e.g., one or more random access preambles, etc.) that will enable the UE to communicate with the appropriate (target) base station or via the appropriate (target) cell when the conditions are met. For example, for conditionally adding a base station as SN or conditionally adding a candidate cell as PSCell, the RAN provides the UE with a condition to be met before the UE can add the base station as SN or add the candidate cell as PSCell, and a configuration to enable the UE to communicate with the base station or PSCell after the condition has been met.
In the instant PSCell addition or modification procedure, the RAN (i.e., MN or SN) transmits an RRC reconfiguration message including a plurality of configuration parameters to the UE, and the UE attempts to connect to the (target) PSCell configured by the RRC reconfiguration message. After the UE successfully connects to the SN via the PSCell, the UE communicates with the SN on the PSCell using security keys associated with the plurality of configuration parameters and with the PSCell and derived from one or more security configuration parameters in the RRC reconfiguration message. The SN also derives a security key that matches the security key derived from the UE. After the UE successfully connects to the PSCell, the RAN (e.g., SN) communicates data with the UE using the matched security key and the plurality of configuration parameters.
In some cases, a candidate SN (C-SN) may provide a variety of candidate configurations when, for example, multiple candidate pscells are available. When the MN completes the configuration of the conditional SN-related procedure (e.g., conditional SN addition or conditional SN cell change), the MN cannot determine which candidate secondary cell the UE will connect to in the future at this time. Furthermore, because the UE is connected to the secondary cell only needs to meet one or more conditions, the MN cannot determine whether the UE will connect to any of the candidate cells in the future or not.
Recently, 3GPP has discussed a method for distributing conditional configurations of candidate PSCells from C-SN to MN. However, how the existing information elements of the instant SN correlation procedure should be used (or not used) to exchange information during the conditional SN correlation procedure remains a pending problem. For example, in some 3GPP proposals, the C-SN sends a conditional configuration list to the MN in an SN addition request acknowledgement message. In such cases, it is not clear how the existing mandatory SN-to-MN container for sending configurations from the SN to the MN in the SN addition request acknowledgement message for the instant SN related procedure should be handled by the C-SN and MN.
Disclosure of Invention
To overcome the above problems, a network node acting as a C-SN or MN may implement the methods described below to distribute conditional configurations during SN-related procedures. To prepare for the SN-related procedure, the MN typically sends a request (e.g., SN addition request message) to the SN. The SN then sends the configuration of the SN (or one or more conditional configurations if the SN is a C-SN) to the MN in an acknowledgement (e.g., an SN addition request acknowledgement message). For the instant SN-related procedure, the SN conventionally includes a configuration in an SN-to-MN container (e.g., S-NG-RAN node-to-M-NG-RAN node container IE, or SgNB-to-MeNB container IE) in the acknowledgement.
In some embodiments, the C-SN includes an SN to MN container in the acknowledgement during the preparation condition SN correlation process. In such embodiments, the MN may ignore the SN-to-MN container. Instead of retrieving the conditional configuration from the SN to MN container, the MN retrieves the conditional configuration from a second container (e.g., RRC container in the conditional PSCell addition information confirm IE) that the C-SN includes in the confirmation. Alternatively, the MN may retrieve one condition configuration from the SN to MN container and the remaining condition configurations from the second container (if the second container is included in the acknowledgement).
In other embodiments, the C-SN excludes the SN to MN container from the acknowledgement. The MN does not generate an error message in response to determining that the acknowledgement is for a conditional SN-related procedure. This is in contrast to scenarios involving an immediate SN-related procedure, in which the MN typically sends an error message to the SN in response to receiving an acknowledgement of the lack of SN-to-MN container.
One example is a method implemented in a Master Node (MN) for managing a conditional procedure involving a User Equipment (UE), a candidate secondary node (C-SN), and the MN. The method comprises the following steps: transmitting a request to the C-SN to perform a conditional procedure related to the C-SN and the UE, the conditional procedure being associated with a condition and a conditional configuration according to which the UE is connected to the C-SN when the condition is satisfied; receiving a response to the request from the C-SN, the response including an SN-to-MN container; and retrieving the conditional configuration from the SN to MN container.
Another exemplary embodiment is a method implemented in a candidate secondary node (C-SN) for managing a conditional procedure involving a User Equipment (UE), a primary node (MN), and the C-SN. The method comprises the following steps: receiving a request from the MN to perform a conditional procedure related to the C-SN and the UE, the conditional procedure being associated with a condition and a conditional configuration according to which the UE is connected to the C-SN when the condition is satisfied; generating a response to the request, the response including an SN-to-MN container, the SN-to-MN container including the conditional configuration; and sending the response to the MN.
Another exemplary embodiment is a method implemented in a primary node (MN) for managing conditional process configurations associated with a User Equipment (UE) capable of communicating with the MN and a Secondary Node (SN) in a Dual Connectivity (DC). The method comprises the following steps: transmitting, by the MN, a request to the SN to perform a procedure related to communication between the UE and the SN; receiving, by the MN, a response to the request from the SN, the response including an SN-to-MN container; and determining, by the MN, whether the process is a conditional process based on the content of the SN-to-MN container.
Yet another exemplary embodiment is a network node comprising processing hardware and a transceiver configured to implement one of the above methods.
Drawings
Fig. 1A is a block diagram of an exemplary system in which a base station and/or User Equipment (UE) may manage conditional procedures related to a primary node (MN) or a Secondary Node (SN) in accordance with various embodiments;
Fig. 1B is another block diagram of an exemplary system in which a Radio Access Network (RAN) and user equipment may manage a conditional procedure related to a MN or SN in accordance with various embodiments;
FIG. 1C is a block diagram of an exemplary base station including a Central Unit (CU) and Distributed Units (DU) that may operate in the system of FIG. 1A or FIG. 1B;
Fig. 2 is a block diagram of an exemplary protocol stack according to which the UE of fig. 1A-1B may communicate with a base station;
fig. 3A illustrates an exemplary scenario in which the MN receives coordination information from the SN during the SN addition request procedure and refrains from applying the coordination information or restriction information until it is determined that the UE has connected to a particular cell of the SN;
Fig. 3B illustrates an exemplary scenario in which the MN performs an SN addition request procedure with the SN, but receives coordination information from the C-SN after the UE has connected to a particular cell of the SN;
fig. 3C illustrates an exemplary scenario in which the SN provides the MN with the same coordination information for all candidate cells during the SN addition request procedure and the MN immediately applies the coordination information;
Fig. 3D illustrates a scenario in which the MN initiates a conditional SN modification procedure and applies coordination information according to fig. 3A to 3C;
Fig. 3E shows a scenario in which the SN initiates a conditional SN modification procedure and the MN applies coordination information according to fig. 3A to 3C;
Fig. 4A is a flow chart of an exemplary method for delaying the application of coordination information received during a conditional SN configuration procedure until after determining which secondary cell the UE is connected to, wherein the method may be implemented in the base station of fig. 1A acting as a MN;
Fig. 4B is a flow chart of an exemplary method for receiving and applying coordination information after determining which secondary cell the UE is connected to, wherein the method may be implemented in the base station of fig. 1A acting as a MN;
fig. 5 is a flow chart of an exemplary method for determining whether to retrieve or ignore RRC messages in an SN-to-MN container received during an SN addition procedure, depending on whether the SN addition procedure is conditional, wherein the method may be implemented in the base station of fig. 1A acting as a MN;
Fig. 6A is a flow chart of an exemplary method for determining whether to include an RRC message in an SN-to-MN container in an SN request acknowledgment message during an SN addition procedure based on whether the SN addition procedure is conditional, wherein the method may be implemented in the base station of fig. 1A acting as an SN or a candidate SN;
fig. 6B is a flow chart of an exemplary method similar to fig. 6A, but for the base station to avoid including an SN-to-MN container in an SN request acknowledgment message if the SN addition process is conditional, wherein the method may be implemented in the base station of fig. 1A acting as an SN or a candidate SN;
fig. 7 is a flow chart of an exemplary method for initiating a conditional SN correlation procedure and determining that an SN request acknowledgment excluding a mandatory SN to MN container is valid, wherein the method may be implemented in the base station of fig. 1A acting as a MN;
Fig. 8 is a flow chart of an exemplary method for determining whether a received SN request acknowledgment message that excludes a mandatory SN to MN container is valid based on whether the SN related procedure is conditional, wherein the method may be implemented in the base station of fig. 1A acting as a MN;
FIG. 9 is a flow chart of an exemplary method for generating and including a C-SN configuration in a SN-to-MN container or different container during a conditional SN correlation process, which may be implemented in the base station of FIG. 1A acting as an SN or candidate SN;
Fig. 10 is a flow chart of an exemplary method for retrieving one or more C-SN configurations from an SN-to-MN container or different container during a conditional SN correlation procedure, wherein the method may be implemented in the base station of fig. 1A acting as an MN;
Fig. 11 is a flow chart of an exemplary method for generating (i) an RRC container including an RRC message or (ii) a conditional configuration including an RRC message retrieved from an SN to MN container, depending on whether the SN-related procedure is conditional, wherein the method may be implemented in the base station of fig. 1A acting as an MN;
Fig. 12 is a flow chart of an exemplary method for managing SN-related procedures, wherein the method may be implemented in the base station of fig. 1A acting as a MN; and
Fig. 13 is a flow chart of an exemplary method for managing SN-related procedures, wherein the method may be implemented in the base station of fig. 1A acting as a C-SN.
Detailed Description
As discussed in detail below, the UE and/or one or more base stations manage conditional procedures, such as conditional PSCell addition or modification (CPAC). The present disclosure may also refer to the conditional PSCell addition procedure and the conditional PSCell modification procedure separately using the abbreviations CPA and CPC, respectively.
Referring first to fig. 1A, an exemplary wireless communication system 100 includes a UE 102, a Base Station (BS) 104A, a base station 106A, and a Core Network (CN) 110. The base stations 104A and 106A may operate in a RAN 105 connected to the same Core Network (CN) 110. CN 110 may be implemented as, for example, evolved Packet Core (EPC) 111 or fifth generation (5G) core (5 GC) 160.
EPC 111 may include, among other components, a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a packet data network gateway (PGW) 116.SGW 112 is generally configured to communicate user plane packets related to audio calls, video calls, internet traffic, etc., and MME 114 is configured to manage authentication, registration, paging, and other related functions. PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an internet network and/or an Internet Protocol (IP) multimedia subsystem (IMS) network. The 5gc 160 includes a User Plane Function (UPF) 162, an access and mobility management function (AMF) 164, and/or a Session Management Function (SMF) 166. In general, the UPF 162 is configured to communicate user plane packets related to audio calls, video calls, internet traffic, and the like; AMF 164 is configured to manage authentication, registration, paging, and other related functions; and SMF 166 is configured to manage PDU sessions.
As shown in fig. 1A, base station 104A supports cell 124A and base station 106A supports cell 126A. Furthermore, each of the base stations 104A, 106A may support more than one cell. For example, base station 106A may also support cell 126C. Cells 124A and 126A may partially overlap such that UE 102 may communicate in DC with base station 104A and base station 106A, which act as a primary node (MN) and a Secondary Node (SN), respectively. In order to exchange messages directly during the DC scenario and other scenarios discussed below, MN 104A and SN 106A may support an X2 or Xn interface. Generally, CN 110 may be connected to any suitable number of base stations supporting NR cells and/or EUTRA cells. An exemplary configuration in which EPC 111 is connected to an additional base station is discussed below with reference to fig. 1B.
The base station 104A is equipped with processing hardware 130, which may include one or more general-purpose processors (e.g., 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. The processing hardware 130 in the exemplary embodiment includes a condition configuration controller 132 configured to manage a condition configuration of one or more condition procedures, such as a Condition Handoff (CHO), a condition PSCell addition or change (CPAC), or a condition SN addition or change (CSAC), when the base station 104A acts as a MN. The base station 104A also includes hardware, such as antennas, transceivers, transmitters, and/or receivers, for wireless communication with other devices including the UE 102.
The base station 106A is equipped with processing hardware 140, which may include one or more general-purpose processors (e.g., 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. The processing hardware 140 in the exemplary embodiment includes a condition configuration controller 142 configured to manage a condition configuration of one or more condition processes, such as CHO, CPAC, or CSAC, when the base station 106A acts as a SN. The base station 106A also includes hardware, such as antennas, transceivers, transmitters, and/or receivers, for wireless communication with other devices including the UE 102.
Still referring to fig. 1a, the ue 102 is equipped with processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors and/or special-purpose processing units. The processing hardware 150 in the exemplary embodiment includes a UE condition configuration controller 152 configured to manage the condition configuration of one or more conditional processes. UE 102 also includes hardware, such as antennas, transceivers, transmitters, and/or receivers, for wireless communication with other devices including RAN 105.
More specifically, the condition configuration controllers 132, 142, and 152 may perform at least some of the methods discussed below with reference to messaging and flow diagrams. Although fig. 1A shows the condition configuration controllers 132 and 142 as separate components, in at least some scenarios, the base stations 104A and 106A may have similar structures and act as MN or SN nodes in different scenarios. In other words, each of the base stations 104A and 106A may implement both the conditional configuration controller 132 and the conditional configuration controller 142 to support MN and SN functionality, respectively.
In operation, the UE 102 may use radio bearers (e.g., DRBs or SRBs) that terminate at the MN 104A or SN 106A at different times. The UE 102 may apply one or more security keys when communicating in the uplink (from the UE 102 to the BS) and/or downlink (from the base station to the UE 102) directions on the radio bearer. In some cases, the UE may use different RATs to communicate with the base stations 104A and 106A. Although the following examples may refer specifically to a particular RAT type, 5GNR, or EUTRA, the methods generally discussed below may also be applied to other suitable radio access and/or core network technologies.
Fig. 1B depicts additional base stations 104B and 106B that may be included in the wireless communication system 100. UE 102 is initially connected to base station 104A. BSs 104B and 106B can have similar processing hardware to base station 106A.
In some scenarios, the base station 104A performs instant SN addition to configure the UE 102 to operate in Dual Connectivity (DC) with the base station 104A (via PCell) and the base station 106A (via PSCell other than cell 126A). Base stations 104A and 106A act as MNs and SNs, respectively, for UE 102. The UE 102 may operate using an MR-DC connection mode in some cases, for example, communicating with the base station 104A using 5G NR and with the base station 106A using EUTRA, or communicating with the base station 104A using EUTRA and with the base station 106A using 5G NR.
In one scenario, when the UE 102 communicates with the MN 104A and the S-SN 106A in DC, the MN 104A performs an immediate SN change to change the SN of the UE 102 from the base station 106A (source SN, or "S-SN") to the base station 104B (target SN, or "T-SN"). In another scenario, the SN 106A performs an immediate PSCell change to change the PSCell of the UE 102 to the cell 126A. In one implementation, the SN 106A sends a configuration to the UE 102 to change the PSCell to cell 126A for immediate PSCell change via a Signaling Radio Bearer (SRB) (e.g., SRB 3). In another embodiment, the SN 106A sends a configuration to the UE 102 via the MN 104A to change PSCell to cell 126A for immediate PSCell change. MN 104A may send to UE 102 via SRB 1a configuration that immediately changes PSCell to cell 126A.
In other scenarios, the base station 104A may perform a conditional SN addition procedure to first configure the base station 106B as the C-SN of the UE 102, i.e., conditional SN addition or modification (CSAC). At this time, the UE 102 may be in a Single Connection (SC) state with the base station 104A or in a DC state with the base station 104A and the base station 106A. If the UE 102 is DC with the base station 104A and the base station 106A, the MN 104A determines whether a condition associated with the conditional SN addition procedure is satisfied in response to a request received from the base station 106A or in response to one or more measurements received from the UE 102 or obtained by the MN 104A from measurements of signals received from the UE 102. In contrast to the immediate SN addition discussed above, the UE 102 does not immediately attempt to connect to the C-SN 106B. In this scenario, base station 104A again acts as a MN, but base station 106B initially acts as a C-SN instead of SN.
More specifically, when the UE 102 receives a configuration for the C-SN 106B, the UE 102 is not connected to the C-SN 106B until the UE 102 determines that certain conditions are met (the UE 102 may consider multiple conditions in some cases, but for convenience, the following discussion refers to only a single condition). When the UE 102 determines that the condition has been met, the UE 102 connects to the C-SN 106B such that the C-SN 106B begins to act as the SN 106B of the UE 102. Thus, while base station 106B acts as a C-SN, rather than an SN, base station 106B has not yet been connected to UE 102, and thus has not yet served UE 102. In some implementations, the UE 102 disconnects from the SN 106A to connect to the C-SN 106B.
In yet other scenarios, the UE 102 is in DC with the MN 104A (via PCell) and SN 106A (via PSCell other than cell 126A and not shown in fig. 1A). The SN 106A may perform conditional PSCell addition or modification (CPAC) to configure candidate PSCell (C-PSCell) 126A for the UE 102. If the UE 102 is configured to signal a radio bearer (SRB) (e.g., SRB 3) to exchange RRC messages with the SN 106A, the SN 106A may send configuration for the C-PSCell 126A to the UE 102 via the SRB, e.g., in response to one or more measurements that may be received from the UE 102 via the SRB or via the MN 104A, or may be obtained by the SN 106A from measurements of signals received from the UE 102. In some embodiments, the SN 106A sends the configuration for the C-PSCell 126A via the MN 104A. In contrast to the immediate PSCell change discussed above, UE 102 does not immediately disconnect from PSCell and attempts to connect to C-PSCell 126A.
More specifically, when the UE 102 receives a configuration for the C-PSCell 126A, the UE 102 is not connected to the C-PSCell 126A until the UE 102 determines that certain conditions are met (the UE 102 may consider multiple conditions in some cases, but for convenience, the following discussion refers to only a single condition). When the UE 102 determines that the condition has been met, the UE 102 connects to the C-PSCell 126A such that the C-PSCell 126A begins to act as the PSCell 126A of the UE 102. Thus, although cell 126A acts as a C-PSCell, rather than a PSCell, SN 106A may not have been connected to UE 102 via cell 126A. In some implementations, the UE 102 may disconnect from the PSCell to connect to the C-PSCell 126A.
In some scenarios, the condition associated with CSAC or CPAC may be the signal strength/quality detected by the UE 102 on the C-PSCell126A of the SN 106A or on the C-PSCell 126B of the C-SN 106B. This condition is met if the signal strength/quality exceeds a certain threshold or corresponds to an acceptable measurement. For example, the UE 102 determines that the condition is met when one or more measurements obtained by the UE 102 on the C-PSCell126A are above a threshold configured by the MN 104A or SN 106A or above a pre-configured threshold. When the UE 102 determines that the signal strength/quality on the C-PSCell126A of the SN 106A is sufficiently good (again measured relative to one or more quantitative thresholds or other quantitative metrics), the UE 102 may perform a random access procedure with the SN 106A on the C-PSCell126A to connect to the SN 106A. After the UE 102 successfully completes the random access procedure on the C-PSCell126A, the C-PSCell126A becomes the PSCell126A of the UE 102. The SN 106A may then begin transmitting data (user plane data or control plane data) with the UE 102 via the PSCell 126A. In another example, the UE 102 determines that the condition is met when one or more measurements obtained by the UE 102 on the C-PSCell 126B are above a threshold configured by the MN 104A or the C-SN 106B or above a pre-configured threshold. When the UE 102 determines that the signal strength/quality on the C-PSCell 126B of the C-SN 106B is sufficiently good (again measured relative to one or more quantitative thresholds or other quantitative metrics), the UE 102 may perform a random access procedure with the SN 106B on the C-PSCell 126B to connect to the C-SN 106B. After the UE 102 successfully completes the random access procedure on the C-PSCell 126B, the C-PSCell 126B becomes the PSCell 126B of the UE 102 and the C-SN 106B becomes the SN 106B. The SN 106B may then begin transmitting data (user plane data or control plane data) with the UE 102 via the PSCell 126B.
In various configurations of the wireless communication system 100, the base station 104A may act as a master eNB (MeNB) or a master gcb (MgNB), and the base station 106A or 106B may act as a secondary gcb (SgNB) or candidate SgNB (C-SgNB). The UE 102 may communicate with the base station 104A and the base station 106A or 106B (106A/B) via the same RAT, such as EUTRA or NR, or different RATs. When base station 104A is a MeNB and base station 106A is SgNB, UE 102 may be in EUTRA-NR DC (EN-DC) with MeNB and SgNB. In such a scenario, the MeNB 104A may or may not configure the base station 106B as C-SgNB of the UE 102. In this scenario SgNB a may configure cell 126A as the C-PSCell of UE 102. When base station 104A is a MeNB and base station 106A is C-SgNB of UE 102, UE 102 may be in SC with the MeNB. In such a scenario, the MeNB 104A may or may not configure the base station 106B as another C-SgNB of the UE 102.
In some cases, the MeNB, seNB, or C-SgNB is implemented as a ng-eNB instead of an eNB. When base station 104A is a master NG-eNB (Mng-eNB) and base station 106A is SgNB, UE 102 may be in the Next Generation (NG) EUTRA-NR DC (NGEN-DC) with Mng-eNB and SgNB. In such a scenario, mng-eNB 104A may or may not configure base station 106B as C-SgNB of UE 102, and SgNB a may configure cell 126A as C-PSCell of UE 102. When base station 104A is a Mng-NB and base station 106A is C-SgNB of UE 102, UE 102 may be in SC with the Mng-NB. In this scenario, mng-eNB 104A may or may not configure base station 106B as another C-SgNB of UE 102.
When base station 104A is MgNB and base station 106A/B is SgNB, UE 102 may be in NR-NR DC (NR-DC) with MgNB and SgNB. In such a scenario MgNB a may or may not configure base station 106B as C-SgNB of UE 102, and SgNB a may configure cell 126A as C-PSCell of UE 102. When base station 104A is MgNB and base station 106A is C-SgNB of UE 102, UE 102 may be in SC with MgNB. In such a scenario, mgNB a may or may not configure base station 106B as another C-SgNB of UE 102.
When base station 104A is MgNB and base station 106A/B is a secondary ng-eNB (Sng-eNB), UE 102 may be in NR-EUTRA DC (NE-DC) with MgNB and Sng-eNBs. In such a scenario MgNB a may or may not configure base station 106B as a C-Sng-eNB for UE 102, and Sng-eNB 106A may configure cell 126A as a C-PSCell for UE 102. When base station 104A is MgNB and base station 106A is a candidate Sng-eNB (C-Sng-eNB) for UE 102, UE 102 may be in SC with MgNB. In this scenario MgNB a may or may not configure base station 106B as another C-Sng-eNB for UE 102.
The base stations 104A, 106A, and 106B may be connected to the same Core Network (CN) 110, which may be an Evolved Packet Core (EPC) 111 or a fifth generation core (5 GC) 160. Base station 104A may be implemented as an eNB supporting an S1 interface for communicating with EPC111, as a NG-eNB supporting an NG interface for communicating with 5gc 160, or as a base station supporting an NR radio interface and an NG interface for communicating with 5gc 160. Base station 106A may be implemented as EN-DC gNB (EN-gNB) with an S1 interface to EPC111, an EN-gNB not connected to EPC111, a gNB supporting an NR radio interface and an NG interface to 5gc 160, or a NG-eNB supporting an EUTRA radio interface and an NG interface to 5gc 160. To exchange messages directly during the scenarios discussed below, base stations 104A, 106A, and 106B may support an X2 or Xn interface.
As shown in fig. 1B, base station 104A supports cell 124A, base station 104B supports cell 124B, base station 106A supports cell 126A, and base station 106B supports cell 126B. Cells 124A and 126A may partially overlap, and cells 124A and 124B may also partially overlap, such that UE 102 may communicate with base station 104A (acting as MN) and base station 106A (acting as SN) in DC, and with base station 104A (acting as MN) and SN 104B when the SN modification is completed. More specifically, when UE 102 operates in DC with base station 104A and base station 106A, base station 104A acts as a MeNB, mng-eNB, or MgNB, and base station 106A acts as a SgNB or Sng-eNB. When the UE 102 and the base station 104A are in SC, the base station 104A acts as a MeNB, mng-eNB, or MgNB, and the base station 106B acts as a C-SgNB or C-Sng-eNB. When UE 102 operates in DC with base station 104A and base station 106A, base station 104A acts as a MeNB, mng-eNB, or MgNB, base station 106A acts as a SgNB or Sng-eNB, and base station 106B acts as a C-SgNB or C-Sng-eNB.
In general, the wireless communication network 100 may include any suitable number of base stations supporting NR cells and/or EUTRA cells. More specifically, EPC 111 or 5gc 160 may be connected to any suitable number of base stations supporting NR cells and/or EUTRA cells. Although the following examples relate specifically to specific CN types (EPC, 5 GC) and RAT types (5G NR and EUTRA), in general the methods discussed below may also be applied to other suitable radio access and/or core network technologies, such as sixth generation (6G) radio access and/or 6G core networks or 5G NR-6G DC.
Fig. 1C depicts an example of a distributed implementation of a base station, such as base station 104A, 104B, 106A, or 106B. The base stations in the distributed embodiment may include a Central 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 (e.g., CPUs) and a 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 exemplary embodiment includes a (C-) SN RRC controller configured to manage or control one or more RRC configurations and/or RRC procedures when the base station 106A acts as an SN or candidate SN (C-SN). Base station 106B may have the same or similar hardware as base station 106A. In some embodiments, the CU 172 may include a logical node CU-CP 172A that hosts a control plane portion of a Packet Data Convergence Protocol (PDCP) protocol of the CU 172. CU 172 may also include a logical node CU-UP 172B that hosts a PDCP protocol and/or a user plane portion of a Service Data Adaptation Protocol (SDAP) protocol of CU 172.
DU 174 is also equipped with processing hardware that may include one or more general purpose processors (e.g., CPUs) and a non-transitory computer readable memory storing machine readable instructions executable on the one or more general purpose processors and/or special purpose processing units. In some examples, the processing hardware in the exemplary embodiments includes a Medium Access Control (MAC) controller configured to manage or control one or more MAC operations or processes (e.g., random access processes) and a Radio Link Control (RLC) controller configured to manage or control one or more RLC operations or processes when the base station 106A acts as a MN, SN, or C-SN. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or processes.
Fig. 2 illustrates in simplified form an exemplary protocol stack 200 according to which a UE 102 may communicate with an eNB/ng-eNB or a gNB (e.g., one or more of the base stations 104, 106).
In the exemplary stack 200, the physical layer (PHY) 202A of EUTRA provides transport channels to an EUTRA MAC sublayer 204A, which in turn provides logical channels to an EUTRA RLC sublayer 206A. EUTRA RLC sublayer 206A in turn provides RLC channels to EUTRA PDCP sublayer 208 and, in some cases, to NR PDCP sublayer 210. Similarly, NR PHY 202B provides transport channels to NR MAC sublayer 204B, which in turn provides logical channels to NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210, in turn, may provide data transfer services to a Service Data Adaptation Protocol (SDAP) 212 or a Radio Resource Control (RRC) sublayer (not shown in fig. 2). In some embodiments, the UE 102 supports both EUTRA and NR stacks, as shown in fig. 2, to support handover between EUTRA and NR base stations and/or to support DC over the EUTRA and NR interfaces. Further, as shown in fig. 2, the UE 102 may support layering of NR PDCP 210 on EUTRA RLC 206A, and layering of an SDAP sublayer 212 on NR PDCP sublayer 210.
The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly on the PDCP layer 208 or 210) that may be referred to as Service Data Units (SDUs) and output packets (e.g., to the RLC layer 206A or 206B) that may be referred to as Protocol Data Units (PDUs). Except where the difference between SDUs and PDUs is relevant, the present disclosure refers to both SDUs and PDUs as "packets" for simplicity.
On the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 may provide Signaling Radio Bearers (SRBs) or RRC sublayers (not shown in fig. 2) to exchange, for example, RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide Data Radio Bearers (DRBs) to support data exchanges. The data exchanged on the NR PDCP sublayer 210 may be an SDAP PDU, an Internet Protocol (IP) packet, or an ethernet packet.
Next, several exemplary scenarios in which the UE and/or RAN performs a method for supporting conditional procedures are discussed with reference to fig. 3A-3E. In general, similar events in fig. 3A through 3E are labeled with the same reference numerals, with differences discussed below where appropriate. In these figures, time flows from the upper part to the lower part.
Referring first to fig. 3A, in scenario 300A, the MN receives coordination information from the SN during an SN addition request procedure and refrains from applying coordination information or restriction information until it is determined that the UE has connected to a particular cell of the SN. In the scenario 300A, the base station 104A acts as a MN and the base station 106A acts as a C-SN. Initially, UE 102 operates in a Single Connection (SC) with MN 104A (302). While in SC, UE 102 communicates UL PDUs and/or DL PDUs with MN 104A (e.g., via PCell 124A) according to the MN configuration.
/>
Table 1: exemplary fields in MN and/or SN limitation information
In some implementations, MN 104A can determine MN restriction information and SN restriction information based on the capabilities of UE 102. More specifically, the MN104 determines MN restriction information and SN restriction information such that when the UE 102 communicates with both the MN104 and the C-SN 106A, the communication with the MN104 and the C-SN 106A does not exceed the capabilities of the UE 102. For example, the MN104 can determine a maximum uplink power in the MN restriction information that the MN104 can transmit when the UE 102 is permitted to communicate with the MN104, and the MN104 can determine a maximum uplink power in the SN restriction information that the C-SN 106A can permit the UE 102 to transmit when communicating with the C-SN 106A.
In response to receiving (304) the SN addition request message, the C-SN 106A determines (306) one or more C-pscells (C-pscells) and generates one or more C-SN configurations (C-SN configurations) for the UE 102, each C-SN configuration being associated with a particular one of the C-pscells. For example, the C-PScell may be cell 126A and cell 126C. In some embodiments, the C-SN 106A determines the C-PScell and C-SN configuration after considering the candidate cell information and SN limitation information. C-SN 106A sends 308 an SN addition request acknowledgement message to MN 104A including the ID of the C-PScell and the C-SN configuration. The SN addition request acknowledgement message may or may not include a SN to MN container. In some embodiments, the SN-to-MN container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined in the 3gpp 38.423 release 15 specification. In other embodiments, the SN-to-MN container is SgNB-to-MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification.
/>
/>
/>
Table 2: exemplary coordination parameters
Upon receiving (308) the SN addition request acknowledgement message, the MN 104A refrains (310) from applying coordination information and/or MN restriction information. That is, when MN 104A performs communication with UE 102, MN 104A does not consider coordination information and/or MN restriction information.
MN 104A can include the C-SN configuration in an RRC reconfiguration message (e.g., RRCConnectionReconfiguration message or RRCReconfiguration message) and send (312) the RRC reconfiguration message to UE 102. In response, the UE 102 sends 314 an RRC reconfiguration complete message (e.g., RRCConnectionReconfigurationComplete message or RRCReconfigurationComplete message) to the MN 104A. In some implementations, the MN 104A can assign a particular configuration ID to each of the C-SN configurations. For example, in the case where the C-SN configuration includes C-SN configurations 1, …, N (N is an integer greater than zero), MN 104A may assign configuration IDs 1, …, ID N to C-SN configurations 1, … N, respectively. In such cases, MN 104A may include configuration ID 1, …, ID N in the RRC reconfiguration message. In such embodiments, MN 104A may include trigger condition configurations 1, …, N for C-SN configurations 1, …, N, respectively, in RRC reconfiguration. The MN 104A may generate or receive a trigger condition configuration from the C-SN 106A. Each of the trigger condition configurations may configure one or more conditions that trigger the UE 102 to connect to the C-SN 106A via a particular C-PSCell configured in the particular C-SN configuration. In such a case, MN 104A may include the conditional configuration identifiers CID 1, …, CID N in the RRC reconfiguration message. In some embodiments, MN 104A may generate a conditional (reconfiguration) field/IE 1, …, N comprising C-SN configuration 1, …, N and trigger condition configuration 1, …, N, respectively, and send (312) an RRC reconfiguration message comprising the conditional configuration field/IE to UE 102. In other embodiments, MN 104A can generate RRC container messages (e.g., RRCConnectionReconfiguration messages or RRCReconfiguration messages) 1, …, N including C-SN configurations 1, …, N, respectively, generate conditional (re) configuration fields/IEs 1, …, N including RRC container messages 1, …, N and conditional configurations 1, …, N, respectively, and send (312) an RRC reconfiguration message including the conditional configuration fields/IEs to UE 102.
In some implementations, in response to or after receiving the RRC reconfiguration complete message, the MN 104A can send an SN message (e.g., an SN reconfiguration complete message) to the C-SN 106A to indicate that the UE 102 received the C-SN configuration. In other embodiments, the MN 104A refrains from sending an SN message to the C-SN 106 to instruct the UE 102 to receive the C-SN configuration. The events 304, 306, 307, 308, 310, 312, and 314 collectively define a conditional SN addition preparation process 380.
Upon receiving (314) an RRC reconfiguration complete message or an acknowledgement (e.g., RLC acknowledgement or hybrid automatic request retransmission (HARQ) acknowledgement) of a PDU (e.g., RLC PDU or MAC PDU) comprising the RRC reconfiguration message, the MN 104A can send (316) an early state transition message to the C-SN 106A to convey the COUNT value of the first downlink SDU forwarded by the MN 104A to the C-SN 106A or the COUNT value of the already forwarded downlink SDU for each of the DRBs of the UE 102. The early state transition message may be an early sequence number state transition message. The MN 104A can send 316 an early state transition message without receiving an interface message indicating that the UE 102 is connected to the C-SN 106A.
After performing (380) the conditional SN addition preparation procedure to configure the C-SN 106A as a C-SN, the MN 104A may send (316) an early state transition message to the C-SN 106A. More specifically, after performing (380) the SN-related procedure with the C-SN 106A, the MN can determine (317) whether the SN-related procedure is a conditional procedure or an immediate procedure. Responsive to determining (317) that the SN-related process is a conditional process (and accordingly, early data forwarding is necessary), the MN sends (316) an early state transition message.
The UE 102 may use one or more conditions to determine whether to connect to one of the C-pscells. If the UE 102 detects (318) that the condition for connecting to the C-PSCell 126A is satisfied, the UE 102 connects to the C-PSCell 126A. That is, a condition (or "trigger condition") triggers the UE 102 to connect to the C-PSCell 126A or to perform a C-SN configuration involving the C-PSCell 126A. However, if the UE 102 does not detect that the condition is met, the UE 102 is not connected to the C-PSCell 126A. In response to the detection, the UE 102 initiates a random access procedure on the C-PSCell 126A. In response to the initiation, the UE 102 performs (320) a random access procedure with the C-SN 106A via the C-PScell 126A. In response to detecting or initiating (318), UE 102 sends (322) an RRC reconfiguration complete message to MN 104A. The UE 102 may send 322 an RRC reconfiguration complete message before, during, or after the random access procedure.
The UE 102 may indicate the selected C-PSCell, i.e., C-PSCell 126A, in an RRC reconfiguration complete message sent (322) by the UE 102. For example, the RRC reconfiguration complete message may indicate that the UE 102 has performed one of the C-SN configurations or a C-PSCell (i.e., C-PSCell 126A) that has been connected to a particular C-SN. The RRC reconfiguration complete message may include, for example, a conditional configuration ID corresponding to a specific C-SN configuration (as shown in fig. 3A). As another example, UE 102 may include the C-PSCell ID of C-PSCell 126A in an RRC reconfiguration complete message. Thus, based on the RRC reconfiguration complete message, MN 104A determines which C-PSCell was selected by UE 102.
In response to or after receiving (322) the RRC reconfiguration complete message, MN 104A sends (324) an SN message to C-SN 106A. In some implementations, the SN message can be an SN reconfiguration complete message. In other embodiments, the SN message may be an RRC transfer message. In still other implementations, the SN message may be a new interface message (e.g., xnAP or X2AP message) defined in the 3gpp release 17 specifications 38.423 or 36.423. In some embodiments, the UE 102 may include the SN RRC message (e.g., RRCReconfigurationComplete message) in an RRC reconfiguration complete message sent by the UE 102 at event 322. In such cases, MN 104A can include the SN RRC message in the SN message.
In some embodiments, the random access procedure may be a four-step random access procedure or a two-step random access procedure. In other embodiments, the random access procedure may be a contention-based random access procedure or a contention-free random access procedure. For example, the UE 102 may include the RRC reconfiguration complete message in message 3 of the four-step random access procedure or in message a of the two-step random access procedure.
After the UE 102 and the C-SN 106A successfully complete each other's random access procedure (i.e., successful contention resolution) via the C-PSCell 126A, the C-PSCell 126A and the C-SN 106A become PSCell and SN, respectively, for the UE 102. After the C-SN 106A successfully completes the random access procedure with the UE 102, the C-SN 106A may send 326 an interface message (e.g., an SN change requirement message or success indication message) to the MN 104A including PSCell information of the PSCell 126A. The PSCell information may include a Cell Global Identity (CGI), a Physical Cell Identity (PCI), and/or an Absolute Radio Frequency Channel Number (ARFCN) that identifies the DL carrier frequency of PSCell 126A. In some implementations, the C-SN 106A can send (326) the interface message in response to or after receiving the SN message.
In response to receiving (322) the RRC reconfiguration complete message or sending (326) the interface message or thereafter, the MN 104A applies (328) the coordination information and/or the MN restriction information. Responsive to applying (328) the coordination information and/or the MN restriction information, the MN 104A can send (330) an RRC reconfiguration message to the UE 102 including configuration parameters. In some embodiments, the configuration parameters 330 may reconfigure or release (the values of) the configuration parameters used by the UE 102 to communicate with the MN 104A. In other embodiments, the configuration parameters 330 may be new configuration parameters for configuring the UE 102 to communicate with the MN 104A. In response to the RRC reconfiguration message 330, the ue 102 may send (332) an RRC reconfiguration message to the MN 104A. Events 322, 324, 326, 328, 330, and 332 are collectively referred to in fig. 3A as conditional SN addition execution process 390.
In response to or after receiving (332) the RRC reconfiguration complete message or 326 interface message, the MN 104A can send (334) a sequence number state transition message to communicate uplink PDCP SN and Hyper Frame Number (HFN) receiver status and/or downlink PDCP SN and HFN transmitter status for each of the DRBs of the UE 102. In contrast to event 316, MN 104A sends 334A (non-early) sequence number state transition message.
After the UE 102 successfully completes 320 the random access procedure, the UE 102 communicates 336 with the MN and with the SN via the C-PSCell126A according to the C-SN configuration configuring the C-PSCell 126A.
With continued reference to fig. 3A, the C-SN configuration in some embodiments may be a complete and stand-alone configuration (i.e., a complete configuration). The C-SN configuration may include a complete configuration indication (information element (IE) or field) identifying the C-SN configuration as a complete configuration. In this case, the UE 102 can use the C-SN configuration to communicate with the SN 106A without relying on the SN configuration. On the other hand, the C-SN configuration in other cases may include a "delta" configuration, or one or more configurations that enhance the previously received SN configuration. In these cases, the UE 102 can use the delta C-SN configuration along with the SN configuration to communicate with the SN 106A.
The C-SN configuration may include a number of configuration parameters that cause the UE 102 to apply when communicating with the SN 106A via the C-PSCell 126A. The plurality of configuration parameters may configure the C-PScell 126A of the SN 106A and zero, one, or more candidate secondary cells (C-SCells) to the UE 102. The plurality of configuration parameters may configure radio resources to enable the UE 102 to communicate with the SN 106A via the C-PSCell 126A of the SN 106A and zero, one, or multiple C-scells. The plurality of configuration parameters may configure zero, one or multiple radio bearers. The one or more radio bearers may include an SRB and/or one or more DRBs.
In some implementations, the C-SN configuration can include a C-PSCell 126A configuring SN 106A and a group configuration (CellGroupConfig) IE of zero, one, or more C-SCells. In one embodiment, the C-SN configuration includes a radio bearer configuration. In another embodiment, the C-SN configuration does not include a radio bearer configuration. For example, the radio bearer configuration may be RadioBearerConfig IE, DRB-ToAddModList IE, or SRB-ToAddModList IE, DRB-ToAddMod IE, or SRB-ToAddMod IE. In various embodiments, the C-SN configuration may be RRCReconfiguration message, RRCReconfiguration-IE, or CellGroupConfig IE compliant with 3GPP specification 38.331v16.5.0 or earlier. The full configuration indication may be a field or IE conforming to 3GPP specification 38.331v16.5.0 or earlier. In other embodiments, the C-SN configuration can include a C-PSCell 126A configuring SN 106A and SCG-ConfigPartSCG-r12 IEs of zero, one, or more C-SCcells. In some embodiments, the C-SN configuration is a RRCConnectionReconfiguration message, RRCConnectionReconfiguration-IE, or ConfigPartSCG-r12 IE compliant with 3GPP Specification 36.331v16.5.0 or earlier. The full configuration indication may be a field or IE conforming to 3GPP specification 36.331 or earlier.
Still referring to fig. 3A, in some cases, base station 106A may include CU 172 and one or more DUs 174, as shown in fig. 1C. For each of the C-SN configurations, one or more DUs 174 may generate the C-SN configuration. Alternatively, for each of the C-SN configurations, one or more DUs 174 may generate a portion of the C-SN configuration, and CU 172 may generate the remaining portion of the C-SN configuration. For example, the UE 102 performs (320) a random access procedure with a first DU of the one or more DUs 174 of the operating (C-) PSCell 126A, and the first DU may identify the UE 102 in the random access procedure. In this case, the UE 102 communicates with the SN 106A via the first DU (336).
The first DU of the C-SN 106A operating the C-PSCell126A may generate a C-SN configuration or a portion of a C-SN configuration configuring the C-PSCell126A and send the C-SN configuration or the portion of the C-SN configuration to the CU 172. In the case of generating a portion of the C-SN configuration, CU 172 generates the remaining portion of the C-SN configuration. In some scenarios or implementations, the first DU generates each of the other C-SN configurations. Alternatively, for each of the other C-SN configurations, the first DU generates a portion of the C-SN configuration, and the CU 172 generates the remaining portion of the C-SN configuration. In other scenarios or embodiments, the first DU generates at least one first C-SN configuration of the C-SN configurations. Alternatively, for each of the at least one first C-SN configuration, the first DU generates a portion of the C-SN configuration and the CU 172 generates the remaining portion of the C-SN configuration. The second DU of the C-SN 106A (the second DU included in the one or more DUs 174) generates at least one second one of the C-SN configurations. Alternatively, for each of the at least one second C-SN configuration, the second DU generates a portion of the C-SN configuration and CU 172 generates the remainder of the C-SN configuration.
Referring next to fig. 3B, scene 300B is similar to scene 300A. However, in scenario 300B, after the UE has connected to a particular cell of the SN, MN 104A receives coordination information from the C-SN. More specifically, in response to the C-SN 106A receiving (304) the SN addition request message, the C-SN 106A sends (305) an SN addition request acknowledgement message to the MN 104A including the ID of the C-PScell and the C-SN configuration, and omits coordination information. The SN addition request acknowledgement message may include an SN to MN container. In some embodiments, the SN-to-MN container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined since the 3gpp 38.423 release 15 specification. In other embodiments, the SN-to-MN container is SgNB-to-MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification. In some implementations, for each of the C-SN configurations, the C-SN 106A generates a CG-Config IE including the C-SN configuration and includes the CG-Config in the SN addition request acknowledgement message. Later, when the C-SN 106A sends 327 an interface message to the MN 104A after the UE 102 connects to the C-SN 106A, the C-SN 106A includes coordination information in the interface message.
In some embodiments, interface message 327 is an existing X2AP message defined in 3GPP specification 36.423v16.6.0 or earlier or an existing XnAP message defined in 3GPP specification 38.423v 16.6.0 or earlier. In other embodiments, interface message 327 is a new X2AP message defined in 3GPP release 17 specification 36.423 or a new XnAP message defined in 3GPP release 17 specification 38.423. In some embodiments, the interface message 327 is another type of message, such as an SN modification required message, an NG-RAN node configuration update message, or an E-UTRA-NR cell resource coordination request message. The interface message 327 may include SgNB coordination assistance information IE or NR resource coordination information IE for Physical Resource Block (PRB) coordination.
After receiving (327) the coordination information, the MN 104A applies (328) the coordination information and/or MN restriction information. After applying 328 the coordination information and/or the MN restriction information, the MN 104A can send 333 an SN modification confirm message to the C-SN 106A (now SN 106A).
Events 304, 306, 307, 305, 312, and 314 together define a conditional SN addition preparation process 381. Events 322, 324, 327, 328, 330, 332, and 333 collectively define a conditional SN addition execution process 391.
Turning to fig. 3C, during a scenario 300C, the C-SN 106A provides the same coordination information for all candidate cells to the MN 104 during the SN addition request procedure, and the MN immediately applies the coordination information. Specifically, when the C-SN 106A generates (307) coordination information, the C-SN 106A generates the same coordination information for all C-PScells (or generates a set of coordination information that applies to all C-PScells). Thus, the coordination parameters included in the coordination information are the same for all C-pscells.
The C-SN 106A transmits (308) a SN addition request acknowledgement message including the C-PSCellID, CG-Config, and coordination information. MN 104A determines (313) whether the coordination information is the same for the C-PSCell. For example, MN 104A may decode the coordination information for each of the C-pscells and determine (317) that the coordination information is the same for each of the C-pscells. As another example, if the coordination information includes a set of coordination information for all C-pscells, MN 104A may determine (317) that the coordination information is the same for all C-pscells. After determining (313) that the coordination information is the same for all C-pscells or in response thereto, MN 104A applies (311) the coordination information and/or MN restriction information. Events 304, 306, 307, 308, 313, 311, 312, and 314 together define a conditional SN addition preparation process 382.
Scenario 300C then proceeds similarly to scenario 300A, except that MN 104A has applied 311 coordination information and/or MN restriction information before UE 102 connects 320 to C-PSCell 126A. Events 322, 324, and 326 together define a conditional SN add execution process 392.
Turning to fig. 3D-3E, scenes 300D and 300E may each be similar to any of scenes 300A-300C. However, scenarios 300D and 300E include MN-initiated conditional SN change procedures and SN-initiated conditional SN change procedures, respectively. Referring first to fig. 3D, in a scenario 300D, the UE 102 operates in Dual Connectivity (DC) with the MN 104A and the base station 106B (301), acting as an S-SN. The UE 102 communicates with the S-SN 106B via the PScell according to the S-SN configuration.
Later, the MN 104A determines a C-SN to configure the base station 106A for Conditional PSCell Change (CPC). The MN 104A may make this determination in a similar manner as described above for the CPA in fig. 3A. To configure the C-SN 106A as a C-SN, the MN 104A may perform any of the conditional SN addition preparation procedures 380, 381, or 382 with the C-SN 106A and the UE 102. After configuring the C-SN 106A, the MN 104A can send 340 an interface message to the S-SN 106B. S-SN 106B may send 342 an early state transfer message to MN 104A. The S-SN 106B may transmit (342) an early state transition message in response to receiving (340) the interface message. The MN 104A also sends 316 an early state transition message to the C-SN 106A, as shown in fig. 3A.
In some embodiments, the interface message 340 is an existing X2AP message defined in 3GPP specification 36.423v16.6.0 or earlier. For example, interface message 340 may be an X2-U address indication or a data forwarding address indication. In one embodiment, the MN 104 can include an existing field or a new field in an existing X2AP message to indicate to the S-SN 106B to send 342 an early state transition message. In another implementation, the MN 104 can include a new field in the existing X2AP message to indicate to the SN 106B that the UE 102 has been configured with a conditional configuration for CPC. In other embodiments, interface message 340 is a new XnAP message defined in the 3GPP release 17 specification. For example, the interface message 340 may be an early state transition trigger message or CPC trigger message or conditional PSCell change notification.
In some embodiments, the interface message 340 is an existing XnAP message defined in 3GPP specification 38.423v16.6.0 or earlier. For example, interface message 340 may be an Xn-U address indication. In one embodiment, the MN 104 can include an existing field or a new field in an existing XnAP message to indicate to the S-SN 106B to send 342 an early state transition message. In another embodiment, the MN 104 may include a new field in the existing XnAP message to indicate to the SN 106B that the UE 102 has been configured with a conditional configuration for CPC. In other embodiments, interface message 340 is a new XnAP message defined in the 3GPP release 17 specification. For example, the interface message 340 may be an early state transition trigger message or CPC trigger message or conditional PSCell change notification.
After the UE 102 detects 318 a condition for connecting to the C-PSCell 126A and connects 320 to the C-SN 106A during a via random access procedure, the MN 104A, UE 102 and the C-SN 106A may perform one of the SN addition execution procedures 390, 391, or 392 based on which conditional SN addition preparation procedure was previously performed during the scene 300D (e.g., if the MN 104A and the C-SN 106A perform the conditional SN addition preparation procedure 380, the MN 104A and the C-SN 106A may perform the conditional SN addition execution procedure 390).
After conditional SN addition execution 390, 391 or 392, MN 104A sends 344 an SN release request message to S-SN 106B to release S-SN 106B from DC. The SN release request message may trigger the S-SN 106B to release the PSCell of the UE 102. In response to the SN release request message, S-SN 106B sends (346) an SN release request acknowledgement message to MN 104A. The S-SN 106B may also send (348) an SN state transfer message to the MN 104A, and the MN 104A may send (334) an SN state transfer message to the C-SN 106A. In addition, the MN 104A can send (350) a UE context release message to the S-SN 106B to instruct the S-SN 106B to release the UE context of the UE 102.
Turning to fig. 3E, scene 300E is similar to scene 300D, except that the CPC is SN-initiated. The S-SN 106B determines the C-SN that configures the base station 106A for CPC. The S-SN 104B may make this determination based on measurements from the UE 102, e.g., similar to the manner in which the MN 104A may determine to initiate CPA discussed above with respect to fig. 3A. In response to the determination, the S-SN 106B sends (303) an SN change requirement message to the MN 104A. To configure the C-SN 106A as a C-SN, the MN 104A may perform any of the conditional SN addition preparation procedures 380, 381, or 382 with the C-SN 106A and the UE 102. After configuring the C-SN 106A, the MN 104A can send 309 an SN change acknowledgement message to the S-SN 106B. The S-SN 106B may send 342 an early state transfer message to the MN 104A in response to the SN change acknowledgement message.
After the UE 102 detects 318 a condition for connecting to the C-PSCell 126A and connects 320 to the C-SN 106A during a via random access procedure, the MN 104A, UE 102 and the C-SN 106A may perform one of the SN addition execution procedures 390, 391, or 392 based on which conditional SN addition preparation procedure was previously performed during the scene 300E. In contrast to FIG. 3D, because the S-SN 106B initiates the CPC, the MN 104A may or may not send 344 an SN release request to the S-SN 106B. In some embodiments, instead of the SN release request message, the MN 104A can send an interface message to the S-SN 106B to indicate the CPC performed in response to receiving the RRC reconfiguration complete message during conditional SN addition execution. For example, the interface message may be a conditional SN change success message or an Xn-U address indication or SN change acknowledgement message.
Fig. 4A-4B, 5, 6A-6B, and 7-13 are flowcharts depicting exemplary methods that a base station (e.g., base station 104A, 104B, 106A, or 106B) may implement to support a conditional SN-related procedure. As indicated at various points throughout the present disclosure, the exemplary methods depicted in fig. 4A-4B, 5, 6A-6B, and 7-13 may be implemented during the above-described scenarios 300A-300E.
Referring to fig. 4A-4B, a base station, such as MN 104A of fig. 3A-3E, may manage the configuration of SN-related procedures for a UE by implementing methods 400A-400B. For example, to apply coordination information, MN 104A may perform method 400A during context 300A and MN 104A may perform method 400B during context 300B. In general, similar blocks in fig. 4A-4B are labeled with the same reference numerals (e.g., block 402 in fig. 4A corresponds to block 402 in fig. 4B).
Referring first to fig. 4A, during method 400A, at block 402, a base station transmits an SN addition request message including candidate cell information to a C-SN to configure a conditional configuration for a UE (e.g., event 304 of fig. 3A-3C). At block 404, the base station receives an SN addition request acknowledgement message from the C-SN that includes the cell ID of the C-PSCell, the C-SN configuration, and/or coordination information (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B). In block 406, the base station avoids applying coordination information until the UE connects to the C-SN. At block 408, the base station transmits a DL message to the UE including a list of conditional configurations, wherein each conditional configuration includes a configuration ID, a conditional configuration, and a C-SN configuration (e.g., event 312 of fig. 3A-3C). At block 410, the base station receives a first UL message (e.g., event 314 of fig. 3A-3C) from the UE in response to the DL message. At block 412, the base station receives a second UL message (e.g., event 322 of fig. 3A-3C) from the UE in response to one of the conditional configurations. At block 414, the base station transmits a first interface message (e.g., event 324 of fig. 3A-3C) to the C-SN in response to receiving the second UL message. At block 416, the base station may receive a second interface message (e.g., event 326 of fig. 3A-3C) from the C-SN containing PSCell information. At block 418, the base station may apply the coordination information to communicate with the UE (e.g., event 328 of fig. 3A-3B).
Referring next to fig. 4B, the example method 400B begins at block 402, where a base station sends an SN addition request message including candidate cell information to a C-SN to configure a conditional configuration for a UE (e.g., event 304 of fig. 3A-3C). At block 404, the base station receives an SN addition request acknowledgement message from the C-SN that includes the cell ID of the C-PSCell, the C-SN configuration, and/or coordination information (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B). At block 408, the base station transmits a first DL message to the UE comprising a list of conditional configurations, wherein each conditional configuration comprises a configuration ID, a conditional configuration, and a C-SN configuration (e.g., event 312 of fig. 3A-3C). At block 410, the base station receives a first UL message (e.g., event 314 of fig. 3A-3C) from the UE in response to the DL message. At block 412, the base station receives a second UL message (e.g., event 322 of fig. 3A-3C) from the UE in response to one of the conditional configurations. At block 414, the base station may send a first interface message (e.g., event 324 of fig. 3A-3C) to the C-SN in response to receiving the second UL message. At block 417, the base station may receive a second interface message (e.g., event 326 of fig. 3A-3C) from the C-SN containing PSCell information and/or coordination information. At block 418, the base station may apply the coordination information to communicate with the UE (e.g., event 328 of fig. 3A-3B). At block 420, the base station may send a second DL message (e.g., event 330 of fig. 3A-3C) to the UE in response to the application coordination information. At block 422, the base station may receive a third UL message (e.g., event 332 of fig. 3A-3C) from the UE in response to the second DL message.
Fig. 5-13 are flowcharts of methods performed by a base station acting as a MN (e.g., MN 104A of fig. 3A-3E), SN, or acting as a C-SN (e.g., C-SN 106A of fig. 3A-3E) to manage configuration during an SN-related procedure. More specifically, fig. 5 through 13 illustrate how an MN may process receiving (or not receiving) an SN to an MN container during an SN correlation procedure according to whether the SN correlation procedure is a conditional SN correlation procedure, and how an SN (or C-SN) may determine whether and how to utilize the SN to the MN container during the SN correlation procedure according to whether the SN correlation procedure is a conditional SN correlation procedure.
Referring next to fig. 5, a base station acting as a MN (e.g., MN 104A of fig. 3A-3E) performs a method 500 to manage configuration of SN-related procedures for a UE, such as UE 102. In method 500, the MN determines how to process the received SN-to-MN container during the SN-related procedure based on whether the SN-related procedure is conditional.
The method 500 begins at block 502, where the MN sends an SN request message to the SN to perform an SN-related procedure for the UE (e.g., event 304 of fig. 3A-3C). At block 504, the MN receives an SN request acknowledgement message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) from the SN including an SN to MN container in response to the SN request message. At block 506, the MN checks whether the SN-related procedure is a conditional SN-related procedure. If the SN correlation process is a conditional SN correlation process, the MN proceeds to block 512, where the MN ignores the SN to MN container and does not use the contents of the SN to MN container to configure the UE to communicate with the SCG. In some implementations, ignoring the SN-to-MN container means ignoring the entire CG-Config message included in the SN-to-MN container. In other embodiments, ignoring the SN-to-MN container means ignoring a portion of the CG-Config message, such as scg-CellGroupConfig IE and/or scg-RB-Config IE. If the SN-related procedure is not a conditional SN-related procedure at block 506, the MN proceeds to block 508 where the MN retrieves the RRC message from the SN-to-MN container. At block 510, the MN sends an RRC message to the UE. The RRC message may include SCG configuration that the UE may use to connect to the SN.
In some embodiments, the SN-to-MN container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined since the 3gpp 38.423 release 15 specification. In other embodiments, the SN-to-MN container is SgNB-to-MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification. The SN-related procedure may be an SN addition preparation procedure for SN addition or MN-initiated SN modification, or may be performed in response to SN-initiated SN modification. The SN request message may be an SN addition request (e.g., S node addition request or SgNB addition request) message or an SN modification request (e.g., S node modification request or SgNB modification request) message, and the SN request acknowledgement message may be an SN addition request acknowledgement (e.g., S node addition request acknowledgement or SgNB addition request acknowledgement) message or an SN modification request acknowledgement (e.g., S node modification request acknowledgement or SgNB modification request acknowledgement) message.
Referring next to fig. 6A, a method 600A according to an example embodiment is performed by a base station acting as a Sn or C-Sn (e.g., 106A in fig. 3A-3E) to manage configuration of Sn-related procedures for a UE, such as UE 102. The method may be implemented in a base station that acts as an SN or a C-SN (such as C-SN 106A of fig. 3A-3E). For example, a base station acting as an SN can utilize method 600A to determine whether to transmit a configuration utilizing an SN-to-MN container.
Method 600A begins at block 602 where a base station (which may be an SN or a C-SN) receives an SN request message from a MN to perform an SN-related procedure (e.g., event 304 of fig. 3A-3C). At block 604, in response to the SN request message, the base station generates an RRC message that causes the UE to connect to the SN (e.g., an RRC message that includes a configuration that causes the UE to connect to the SN). At block 606, the base station checks whether the SN-related procedure is a conditional SN-related procedure. If the SN-related procedure is not a conditional SN-related procedure, the base station proceeds to block 608 where the base station includes the RRC message in the first container in the SN request acknowledgment message. The base station then proceeds to block 614 where the base station sends an SN request acknowledgment message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) to the MN in response to the SN request message. If the SN correlation process is a conditional SN correlation process at block 606, the base station proceeds to block 610 where the base station includes an RRC message in a second container in the SN request acknowledgement message. At block 612, the base station refrains from including the RRC message in the first container and includes the first container in the SN request acknowledgment message. The base station then proceeds to block 614 as described above.
In some embodiments, the first container is an S-NG-RAN node-to-M-NG-RAN node container IE, e.g., a container IE defined in the 3gpp 38.423 release 15 specification. In other embodiments, the first container is SgNB to MeNB container IE, defined in the 3gpp 36.423 release 15 specification. In some embodiments, the second container is a specific container for containing one or more C-SN configurations, which may be an RRC container included in the conditional PSCell addition information acknowledgement IE or the conditional PSCell modification information acknowledgement IE. In other embodiments, the second container is a cell-specific CG-Config message, which has been defined since the 3gpp 38.331 release 15 specification.
Referring next to fig. 6B, method 600B is an exemplary embodiment similar to method 600A. Specifically, the blocks labeled with the same reference numerals in fig. 6A to 6B are the same. However, during method 600B, in a scenario in which the SN-related process is a conditional process, the base station may determine to exclude the first container from the SN request acknowledgment message. This is in contrast to method 600A, where the base station includes a first container excluding RRC messages in the SN request acknowledgment message in method 600A. More specifically, after block 610, the base station refrains from including the first container in the SN request acknowledgment message at block 613. The base station then proceeds to block 614 where the base station sends an SN request acknowledgment message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) to the MN in response to the SN request message.
Referring next to fig. 7, a base station acting as an MN (e.g., MN 104A of fig. 3A-3E) can implement a method 700 for processing SN request acknowledgment messages that do not include a SN-to-MN container.
The method 700 begins at block 702, where the MN sends an SN request message to the SN to perform a conditional SN-related procedure for the UE (e.g., event 304 of fig. 3A-3C). At block 704, the MN receives an SN request acknowledgement message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) from the SN that excludes the mandatory (i.e., specified by release 15 and subsequent release 3GPP specifications) SN to MN container in response to the SN request message. At block 706, because the conditional SN-related procedure is a conditional procedure, the MN infers that the SN request acknowledgment message is valid. Determining that the received SN request acknowledgment message is valid may include considering that the absence of SN to MN container is not an abstract syntax error and thus does not initiate subsequent error indication, SN release, or UE context release procedures (procedures that would be performed periodically in the absence of forced SN to MN container). At block 708, the MN retrieves one or more C-SN configurations from the SN request acknowledgement message. At block 710, the MN sends one or more C-SN configurations (e.g., event 312 of fig. 3A-3C) to the UE.
In some embodiments, the SN-to-MN container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined since the 3gpp 38.423 release 15 specification. In other embodiments, the SN-to-MN container is SgNB-to-MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification.
Referring next to fig. 8, a method 800 is another method for processing an SN request acknowledgment message that does not include an SN to MN container. Similar to method 700, the method can be implemented by a base station acting as a MN (e.g., MN 104A of fig. 3A-3E).
The method 800 begins at block 802, where the MN sends an SN request message to the SN to perform a conditional SN-related procedure for the UE (e.g., event 304 of fig. 3A-3C). At block 804, the MN receives an SN request acknowledgement message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) from the SN in response to the SN request message excluding the mandatory SN to MN container. At block 806, the MN determines whether the SN-related procedure is a conditional SN-related procedure. If the SN correlation process is a conditional SN correlation process, the MN proceeds to block 808, where the MN concludes that the SN request acknowledgment message is valid. Similar to block 706 described above, inferring that the received SN request acknowledgment message is valid may include not treating the absence of an SN to MN container as an abstract syntax error, and not initiating a subsequent error indication, SN release, or UE context release procedure that the absence forces the SN to MN container correlation. At block 810, the MN retrieves one or more C-SN configurations from the SN request acknowledgment message. At block 812, the MN sends one or more C-SN configurations (e.g., event 312 of fig. 3A-3C) to the UE. If the SN correlation process is a conditional SN correlation process at block 806, the MN proceeds to block 814 where the MN infers that the SN request acknowledgment message is invalid. At block 816, the MN sends at least one message (e.g., an error indication message, an SN release request message, and/or a UE context release message) to the SN in response to the determination to indicate the error.
In some embodiments, the SN-to-MN container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined since the 3gpp 38.423 release 15 specification. In other embodiments, the SN-to-MN container is SgNB-to-MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification.
Referring next to fig. 9, a base station (e.g., SN or C-SN, such as C-SN 106A of fig. 3A-3E) can implement a method 900 for transmitting one or more configurations of SN-related procedures for a UE to a MN (e.g., MN 104A).
The method begins at block 902, where the base station receives an SN request message from the MN to perform a conditional SN-related procedure for the UE (e.g., event 304 of fig. 3A-3C). At block 904, the base station generates one or more C-SN configurations for conditional SN correlation procedures. At block 906, the base station includes one of the one or more C-SN configurations in a first container. At block 908, the base station includes the first container in an SN request acknowledgment message. At block 910, the base station may include the remaining C-SN configurations of the one or more C-SN configurations in a second container. At block 912, the base station may include the second container in the SN request acknowledgement message. At block 914, the base station sends an SN request acknowledgement message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) to the MN in response to the SN request message.
In some embodiments, the first container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined since the 3gpp 38.423 release 15 specification. In other embodiments, the first container is SgNB to MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification. In some embodiments, the second container is a specific for containing one or more C-SN configurations, which may be an RRC container included in the conditional PSCell addition information acknowledgement IE. In other embodiments, the second container is a cell-specific CG-Config message, which has been defined since the 3gpp 38.331 release 15 specification.
Referring next to fig. 10, a base station acting as a MN (e.g., MN 104A of fig. 3A-3E) can implement a method 1000 for receiving one or more configurations of SN-related procedures for a UE from an SN (e.g., C-SN 106A). Method 1000 is similar to method 900 but includes operations implemented by the MN instead of the SN.
The method begins at block 1002, where the base station sends an SN request message to the SN to perform a conditional SN-related procedure for the UE (e.g., event 304 of fig. 3A-3C). At block 1004, the base station receives an SN request acknowledgement message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) from the SN in response to the SN request message. At block 1006, the base station retrieves the C-SN configuration from a first container of the SN request acknowledgement message. At block 1008, the base station generates a conditional configuration comprising a C-SN configuration. At block 1010, the base station includes the conditional configuration in an RRC message. At block 1012, the base station may retrieve the additional C-SN configuration from the second container of the SN request acknowledgment message. If the base station retrieves additional C-SN configurations, the base station generates additional conditional configurations at block 1014, each of which includes a particular one of the additional C-SN configurations. At block 1016, the base station includes the additional condition configuration in an RRC message. At block 1018, the base station sends an RRC message (e.g., event 312 of fig. 3A-3C) to the UE.
In some embodiments, the first container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined since the 3gpp 38.423 release 15 specification. In other embodiments, the first container is SgNB to MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification. In some embodiments, the second container is a specific container for containing one or more C-SN configurations, which may be an RRC container included in the conditional PSCell addition information acknowledgement IE. In other embodiments, the second container is a cell-specific CG-Config message, which has been defined since the 3gpp 38.331 release 15 specification.
Referring next to fig. 11, a base station acting as a MN (e.g., MN 104A of fig. 3A-3E) can implement a method 1000 for transmitting a configuration of a SN-related procedure of a UE to a UE (e.g., UE 102).
The method begins at block 1102, where the base station sends an SN request message to the SN to perform an SN-related procedure for the UE (e.g., event 304 of fig. 3A-3C). At block 1104, the base station receives an SN request acknowledgement message (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B) from the SN including an SN to MN container in response to the SN request message. At block 1106, the base station retrieves the RRC message from the SN-to-MN container of the SN request acknowledgement message. At block 1108, the base station checks whether the SN-related procedure is a conditional SN-related procedure. If the SN-related procedure is not a conditional SN-related procedure, the base station proceeds to block 1110 where the base station generates an RRC container message including an RRC message. The base station then sends an RRC container message (e.g., event 312 of fig. 3A-3C) to the UE at block 1116. If the SN correlation process is a conditional SN correlation process at block 1108, the base station proceeds to block 1112 where the base station generates a conditional configuration including an RRC message. At block 1114, the base station generates an RRC container message including the conditional configuration. The base station then sends an RRC container message (e.g., event 312 of fig. 3A-3C) to the UE at block 1116.
In some embodiments, the SN-to-MN container is an S-NG-RAN node-to-M-NG-RAN node container IE, which has been defined since the 3gpp 38.423 release 15 specification. In other embodiments, the SN-to-MN container is SgNB-to-MeNB container IE, which has been defined since the 3gpp 36.423 release 15 specification.
Turning to fig. 12, a base station acting as a MN (e.g., MN 104A) can implement a method 1200 for managing procedures involving a UE (e.g., UE 102), an SN (e.g., C-SN 106A), and a MN. At block 1202, the MN sends a request to the SN to perform an SN-related procedure (e.g., event 304 of fig. 3A-3C, block 502 of fig. 5, block 702 of fig. 7, block 802 of fig. 8, block 1002 of fig. 10, block 1102 of fig. 11) to the UE. At block 1204, the MN receives a response to the request from the SN (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B, block 504 of fig. 5, block 704 of fig. 7, block 804 of fig. 8, block 1004 of fig. 10, block 1104 of fig. 11). At block 1206, the MN processes the response according to: (i) Whether the response includes an SN-to-MN container for communicating configuration information for communicating with the SN, and (ii) whether the SN-related procedure is a conditional SN-related procedure (e.g., blocks 506, 508, 512 of fig. 5, block 706 of fig. 7, blocks 806, 808, 814 of fig. 8, block 1006 of fig. 10, and blocks 1108, 1110, 1112 of fig. 11).
Referring to fig. 13, a base station acting as a C-SN (e.g., C-SN 106A) can implement a method 1300 for managing procedures involving a UE (e.g., UE 102), MN (e.g., MN 104A), and SN. At block 1302, the C-SN receives a request from the MN to perform a conditional SN-related procedure for the UE (e.g., event 304 of fig. 3A-3C, block 602 of fig. 6A-6B, block 902 of fig. 9). At block 1304, the SN generates a response to the request. Depending on the implementation, generating the response may include: excluding from the response the SN to MN container for communicating configuration information for communicating with the SN (e.g., block 613 of fig. 6A); an SN-to-MN container including only one conditional configuration of C-SNs in the response (e.g., block 906 of fig. 9); or include in the response any conditional configured SN-to-MN container that ignores the C-SN (e.g., block 612 of fig. 6A). At block 1306, the SN sends a response to the MN (e.g., event 308 of fig. 3A and 3C, event 305 of fig. 3B, block 614 of fig. 6A-6B, block 914 of fig. 9).
The following discussion includes observations of RRC container content in conditional PSCell addition information IE and proposed changes to 3gpp TS 36.423 and TS 38.423. In this discussion, a timer problem at the target SN node is found for CPA or inter-SN CPC, and a text proposal to solve the problem is proposed. RAN2#114e has agreed to: (1) In order to exchange per PSCell parameters by re-using existing inter-node RRC messages for CPAC, a CG-Config list associated with each candidate PSCell should be sent from the candidate SN to the MN. (2) FFS, CG-ConfigInfo list from MN to candidate SN if needed. FFS, CG-Config list from source SN to MN if needed. (3) In stage 3 it is discussed whether the new message is useful (based on signalling details). For CPAC initiation, RAN3#112 agrees to: (1) "CPAC initiate indication" is introduced in the SN addition request and SN change request. (2) The SN addition request ACK is introduced with a "prepared PSCell ID list". (2) Whether FFS introduces a "prepared PSCell ID list" in SN change acknowledgement. RAN3#112 also captured the contents of the RRC containers in TS 36.423 and TS 38.423, respectively, as shown in tables 2 and 3 below.
TABLE 2-existing RRC container contents defined in 36.423
TABLE 3-existing RRC container contents defined in 38.423
The contents of the RRC containers differ and it is necessary to determine whether the RAN3 complies with the protocols established by the RAN 2. Furthermore, the original RRC container in table 2 should at least be corrected to "RRCReconfiguration message defined in TS 38.331" because the RRC message comes from SgNB.
For the protocol of RAN2, it allows some flexibility in each CG-Config to include different parameters, such as selectedBandCombination, fr-InfoListSCG, scellFrequenciesSN-NR, selectedToffset-r16 or ph-InfoSCG for the corresponding PSCell, for configuration coordination with the MN.
If RAN3 decides that RAN2 protocol is being followed (i.e., CG-Config list associated with each candidate PSCell should be sent from candidate SN to MN), it should also be noted that "SgNB to MeNB container IE" is mandatory in SGNB ADDITION REQUEST ACKNOWLEDGE (SGNB add request acknowledgement) message in TS 36.423 (and "S-NG-RAN node to M-NG-RAN node container IE" is mandatory in S-NODE ADDITION REQUEST ACKNOWLEDGE (S node add request acknowledgement) message in TS 38.423). In the case of CPAC preparation, the MN should ignore it because there is no corresponding PSCellID and only the conditional PSCell added information acknowledgment in IE CG-Config is considered.
Therefore, the following modifications to TS 36.423 are proposed: (1) Adding "MeNB should ignore SgNB in SGNB ADDITION REQUEST ACKNOWLEDGE (SGNB add request acknowledgement) message to MeNB container IE" in paragraph CPAC in SgNB addition procedure (8.7.4.2). (2) The contents of the RRC container are modified to conform to the RAN2 protocol, which includes a CG-Config message defined in TS 38.331.
The following modifications to TS 38.423 were proposed: (1) Adding "M-NG-RAN node in paragraph CPAC in the S-NG-RAN node addition procedure should ignore the S-NG-RAN node-to-M-NG-RAN node container IE in the S-NODE ADDITION REQUEST ACKNOWLEDGE (S-node addition request acknowledgement) message. (2) The contents of the RRC container are modified to conform to the RAN2 protocol, which includes the CG-Config message defined in sub-clause 11.2.2 of TS 38.331.
The following example list reflects the various embodiments explicitly contemplated:
example 1 is a method implemented in a primary node (MN) for managing procedures involving a User Equipment (UE), a secondary node (C-SN), and the MN. The method comprises the following steps: (1) Transmitting, by processing hardware of the MN, a request to the SN to perform an SN procedure for the UE; receiving, by the processing hardware, a response to the request from the SN; and (2) processing, by the processing hardware, the response based on: (i) Whether the response includes an SN-to-MN container for communicating configuration information for communicating with the SN, and (ii) whether the SN procedure is a conditional SN procedure.
Example 2 is the method of example 1, wherein the SN is a candidate secondary node (C-SN), and wherein the processing comprises: in response to determining that (i) the response includes the SN to MN container, and (ii) the SN procedure is the conditional SN procedure, ignoring at least a portion of the SN to MN container.
Example 3 is the method of example 2, wherein the ignoring comprises: the entire SN-to-MN container is ignored.
Example 4 is the method of example 2, wherein the ignoring comprises: ignoring a configuration included in the SN to MN container, the configuration for connecting the UE to the C-SN.
Example 5 is the method of example 1, wherein the SN is a candidate secondary node (C-SN), and wherein the processing comprises: in response to determining that (i) the response includes the SN to MN container, and (ii) the SN procedure is the conditional SN procedure, retrieving from the SN to MN container only one conditional configuration having conditions that need to be met by candidate cells to which the UE is connected to the C-SN.
Example 6 is the method of example 1, wherein the SN is a candidate secondary node (C-SN), and wherein the processing comprises: in response to determining that (i) the response does not include the SN to MN container, and (ii) the SN procedure is the conditional SN procedure, processing the response but not sending an error message in response to excluding the SN to MN container.
Example 7 is the method of example 5 or 6, wherein the processing comprises: one or more condition configurations of a respective one or more candidate cells of the C-SN are retrieved by the processing hardware from a second container included in the response, each condition configuration having a condition that the UE needs to satisfy to connect to the candidate cell.
Example 8 is the method of example 7, wherein the retrieving comprises: the one or more conditional configurations are retrieved from the second container, the second container being included in a conditional PSCell addition information confirm Information Element (IE).
Example 9 is the method of example 7 or 8, wherein the retrieving comprises: the one or more conditional configurations are retrieved from the second container, which is formatted according to a protocol for controlling radio resources.
Example 10 is the method of example 1, wherein processing the response comprises: in response to determining that (i) the response includes the SN to MN container, and (ii) the SN procedure is not the conditional SN procedure: retrieving from the SN to MN container a message formatted according to a protocol for controlling radio resources; and sending the message to the UE.
Example 11 is the method of example 1, wherein processing the response comprises: in response to determining that (i) the response does not include the SN to MN container, and (ii) the SN procedure is not the conditional SN procedure, an error message is sent to the SN in response to excluding the SN to MN container.
Example 12 is a method implemented in a candidate secondary node (C-SN) for managing a conditional procedure involving a User Equipment (UE), a primary node (MN), and the C-SN, the method comprising: receiving, by processing hardware of the C-SN, a request from the MN to perform a conditional Secondary Node (SN) procedure for the UE; generating, by the processing hardware, a response to the request, the generating comprising: excluding from the response an SN-to-MN container for transmitting configuration information for communicating with the SN; including in the response an SN-to-MN container including only one conditional configuration for the C-SN; or including in the response an SN-to-MN container omitting any conditional configuration for the C-SN; and sending, by the processing hardware, the response to the MN.
Example 13 is the method of example 12, wherein generating the response comprises: generating one or more condition configurations for respective one or more candidate cells of the C-SN, each condition configuration having a condition that the UE needs to satisfy to connect to the candidate cell; including a single one of the one or more conditional configurations in the SN-to-MN container; including the SN to MN container including the single condition configuration in the response; and including the remaining ones of the one or more conditional configurations other than the single conditional configuration in a second container in the response, the second container being different from the SN-to-MN container.
Example 14 is the method of example 12, wherein generating the response comprises: generating one or more condition configurations for respective one or more candidate cells of the C-SN, each condition configuration having a condition that the UE needs to satisfy to connect to the candidate cell; the one or more conditional configurations are included in a second container in the response, the second container being different from the SN-to-MN container.
Example 15 is the method of example 14, wherein the generating comprises: an SN-to-MN container for communicating configuration information for communicating with the SN is excluded from the response.
Example 16 is the method of example 14, wherein the generating comprises: SN-to-MN containers that omit any conditional configuration for the C-SN are included in the response.
Example 17 is the method of any one of examples 13 to 16, wherein the transmitting comprises: the response of the second container included in a conditional PSCell addition Information Element (IE) is sent.
Example 18 is the method of any one of examples 13 to 17, wherein the transmitting comprises: the response is sent comprising the second container formatted according to a protocol for controlling radio resources.
Example 19 is a method implemented in a Master Node (MN) for managing a conditional procedure involving a User Equipment (UE), a candidate secondary node (C-SN), and the MN. The method comprises the following steps: (1) Transmitting, by processing hardware of the MN, a request to the C-SN to perform a candidate Secondary Node (SN) procedure for the UE; (2) Receiving, by the processing hardware, a response to the request from the C-SN; and (3) retrieving, by the processing hardware, the conditional configuration of the C-SN from an SN-to-MN container included in the response, the SN-to-MN container defined for communicating unconditional configuration information for communicating with the SN.
Example 20 is the method of example 19, wherein retrieving the condition configuration comprises: the conditional configuration is retrieved from a CG-Config Information Element (IE) included in the SN to MN container.
Example 21 is the method of example 19, wherein retrieving the condition configuration comprises: one or more condition configurations of the C-SN are retrieved from the response, the one or more condition configurations including the condition configuration.
Example 22 is the method of example 21, wherein retrieving the one or more condition configurations comprises: the one or more condition configurations are retrieved from respective one or more CG-Config Information Elements (IEs) included in the response.
Example 23 is the method of any of examples 19 to 22, wherein receiving the response comprises: an SN addition request acknowledgement message is received.
Example 24 is the method of any one of examples 19 to 23, wherein retrieving the condition configuration comprises: the condition configuration is retrieved from the S-NG-RAN node to M-NG-RAN node container.
Example 25 is the method of any one of examples 19 to 23, wherein retrieving the condition configuration comprises: the condition configuration is retrieved from SgNB to MeNB container.
Example 26 is the method of any one of examples 19 to 25, wherein the conditional SN procedure is a conditional primary secondary cell (PSCell) addition or modification (CPAC) procedure.
Example 27 is the method of any one of examples 19 to 25, wherein the conditional SN process is a conditional SN addition or modification (CSAC) process.
Example 28 is the method of any one of examples 19 to 27, further comprising: the conditional configuration is sent by the processing hardware to the UE.
Example 29 is a method implemented in a candidate secondary node (C-SN) for managing a conditional procedure involving a User Equipment (UE), a primary node (MN), and the C-SN. The method comprises the following steps: (1) Receiving, by processing hardware of the C-SN, a request from the MN to perform a conditional Secondary Node (SN) procedure for the UE; (2) Generating, by the processing hardware, a response to the request, the response including an SN-to-MN container including a conditional configuration of the C-SN, the SN-to-MN container being defined for communicating unconditional configuration information for communicating with an SN; and (3) sending, by the processing hardware, the response to the MN.
Example 30 is the method of example 29, wherein generating the response comprises: the conditional configuration is included in a CG-Config Information Element (IE) in the SN-to-MN container.
Example 31 is the method of example 29, wherein generating the response comprises: one or more conditional configurations of the C-SN are included in the response.
Example 32 is the method of example 31, wherein including the one or more condition configurations in the response comprises: the one or more conditional configurations are included in respective one or more CG-Config Information Elements (IEs) in the response.
Example 33 is the method of any one of examples 29 to 32, wherein sending the response comprises: and sending an SN addition request confirmation message.
Example 34 is the method of any one of examples 29 to 33, wherein generating the response comprises: the conditional configuration is included in an S-NG-RAN node-to-M-NG-RAN node container in the response.
Example 35 is the method of any one of examples 29 to 33, wherein generating the response comprises: the conditional configuration is included in SgNB to MeNB containers in the response.
Example 36 is the method of any one of examples 29 to 35, wherein the conditional SN procedure is a conditional primary secondary cell (PSCell) addition or modification (CPAC) procedure.
Example 37 is the method of any one of examples 29 to 35, wherein the conditional SN procedure is a conditional SN addition or modification (CSAC) procedure.
Example 38 is a network node comprising processing hardware and configured to implement a method according to any of the preceding examples.
The following description may be applied to the above description.
The user device (e.g., UE 102) in which the above-described methods may be implemented may be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile gaming machine, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media stream dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, in some cases, the user device may be embedded in an electronic system such as a host or Advanced Driver Assistance System (ADAS) of the vehicle. Still further, the user device may act as an internet of things (IoT) device or a Mobile Internet Device (MID). Depending on the type, the user device may include one or more general purpose processors, computer readable memory, user interfaces, one or more network interfaces, one or more sensors, and the like.
Certain embodiments in this disclosure are described as comprising logic or multiple components or modules. The modules may be software modules (e.g., code or machine readable instructions stored on a non-transitory machine readable medium) or hardware modules. A hardware module is a tangible unit that is capable of performing certain operations and that may be configured or arranged in some way. A hardware module may include special purpose circuits or logic that are permanently configured to perform certain operations (e.g., as special purpose processors such as Field Programmable Gate Arrays (FPGAs) or Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), etc.). A hardware module may also include programmable logic or circuitry (e.g., contained within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. Decisions to implement hardware modules in dedicated and permanently configured circuits or in temporarily configured circuits (e.g., circuits configured by software) may be driven by cost and time considerations.
When implemented in software, the methods may be provided as part of an operating system, a library used by a plurality of applications, a particular software application, or the like. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.
Those skilled in the art will appreciate upon reading this disclosure additional and alternative structural and functional designs for handling mobility between base stations by the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims (18)

1. A method implemented in a Master Node (MN) for managing a conditional procedure involving a User Equipment (UE), a candidate secondary node (C-SN), and the MN, the method comprising:
Transmitting, by the MN, a request to the C-SN to perform a conditional procedure related to the C-SN and the UE, the conditional procedure being associated with a condition and a conditional configuration according to which the UE is connected to the C-SN when the condition is satisfied;
receiving, by the MN, a response to the request from the C-SN, the response including an SN-to-MN container; and
The conditional configuration is retrieved by the MN from the SN-to-MN container.
2. The method of claim 1, wherein retrieving the condition configuration comprises:
the conditional configuration is retrieved from a CG-Config Information Element (IE) included in the SN to MN container.
3. The method of claim 1, wherein retrieving the condition configuration comprises:
One or more condition configurations are retrieved from the response, the condition configurations included in the one or more condition configurations, wherein the UE connects to the C-SN according to a particular one of the one or more condition configurations when a respective one of the one or more conditions is satisfied.
4. The method of claim 3, wherein retrieving the one or more condition configurations comprises:
the one or more condition configurations are retrieved from respective one or more CG-Config Information Elements (IEs) included in the response.
5. The method of any of the preceding claims, wherein receiving the response comprises:
an SN addition request acknowledgement message is received.
6. The method of any of the preceding claims, wherein retrieving the condition configuration comprises:
the condition configuration is retrieved from the S-NG-RAN node to M-NG-RAN node container or SgNB to MeNB container.
7. The method according to any of the preceding claims, wherein the conditional procedure is a conditional primary secondary cell (PSCell) addition or modification (CPAC) procedure or a conditional SN addition or modification (CSAC) procedure.
8. A method implemented in a candidate secondary node (C-SN) for managing a conditional procedure involving a User Equipment (UE), a primary node (MN), and the C-SN, the method comprising:
Receiving, by the C-SN from the MN, a request to perform a conditional procedure related to the C-SN and the UE, the conditional procedure being associated with a condition and a conditional configuration according to which the UE is connected to the C-SN when the condition is satisfied;
generating, by the C-SN, a response to the request, the response including an SN-to-MN container, the SN-to-MN container including the conditional configuration; and
The response is sent by the C-SN to the MN.
9. The method of claim 8, wherein generating the response comprises:
The conditional configuration is included in a CG-Config Information Element (IE) in the SN-to-MN container.
10. The method of claim 8, wherein generating the response comprises:
One or more condition configurations are included in the response, wherein the UE connects to the C-SN according to a particular one of the one or more condition configurations when a respective one of the one or more conditions is satisfied.
11. The method of claim 10, wherein configuring the one or more conditions includes, in the response:
The one or more conditional configurations are included in respective one or more CG-Config Information Elements (IEs) in the response.
12. The method of any of claims 8 to 11, wherein transmitting the response comprises:
And sending an SN addition request confirmation message.
13. The method of any of claims 8 to 12, wherein generating the response comprises:
the condition configuration is included in the S-NG-RAN node-to-M-NG-RAN node container or SgNB-to-MeNB container in the response.
14. The method according to any one of claims 8 to 13, wherein the conditional procedure is a conditional primary secondary cell (PSCell) addition or modification (CPAC) procedure or a conditional SN addition or modification (CSAC) procedure.
15. A method implemented in a primary node (MN) for managing conditional process configurations related to a User Equipment (UE) capable of communicating with the MN and a Secondary Node (SN) in a Dual Connection (DC), the method comprising:
Sending, by the MN, a request to the SN to perform a procedure related to communication between the UE and the SN;
Receiving, by the MN, a response to the request from the SN, the response including an SN-to-MN container; and
Determining, by the MN, whether the procedure is a conditional procedure based on the contents of the SN-to-MN container.
16. The method of claim 15, wherein if the SN-to-MN container is empty, the result of the determination is that the procedure is conditional and the MN retrieves the conditional procedure configuration from another container or another message.
17. The method of claim 15, wherein if the SN-to-MN container includes more than one SN-UE communication configuration, a result of the determination is that the procedure is conditional and the conditional procedure is configured in the more than one SN-UE communication configuration.
18. A network node comprising processing hardware and a transceiver configured to implement the method of any preceding claim.
CN202280066145.4A 2021-08-05 2022-08-04 Configuration management for conditional secondary node addition and modification Pending CN118056435A (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US63/203,992 2021-08-05
US202263314215P 2022-02-25 2022-02-25
US63/314,215 2022-02-25
PCT/US2022/039405 WO2023014872A1 (en) 2021-08-05 2022-08-04 Managing configurations for conditional secondary node addition and change

Publications (1)

Publication Number Publication Date
CN118056435A true CN118056435A (en) 2024-05-17

Family

ID=91052216

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280066145.4A Pending CN118056435A (en) 2021-08-05 2022-08-04 Configuration management for conditional secondary node addition and modification

Country Status (1)

Country Link
CN (1) CN118056435A (en)

Similar Documents

Publication Publication Date Title
US20210105690A1 (en) Conditional handover management
US20230083266A1 (en) Dual active protocol stack operation for handover and pscell change
US20220386191A1 (en) Conditional full configuration and conditional delta configuration
US20230164650A1 (en) Conditional procedure operations
US20230047744A1 (en) Configuration handling at a user device
CN115486124A (en) Managing unconditional processes in a conditional process
US20230403623A1 (en) Managing sidelink information, configuration, and communication
US20230171648A1 (en) Method Network Optimization in Handover Failure Scenarios
US20230199579A1 (en) Managing configurations
CN114762442A (en) Conditional auxiliary node operation
WO2023133265A1 (en) Managing master node communication in dual connectivity and non-dual connectivity
US20240073771A1 (en) Managing ue configurations when a conditional procedure fails
US20230049140A1 (en) Managing a conditional configuration upon addition or release of a bearer
EP4082251A1 (en) Identification and handling of conditional procedure
CN118056435A (en) Configuration management for conditional secondary node addition and modification
EP4374607A1 (en) Managing configurations for conditional secondary node addition and change
CN118056436A (en) Managing multi-connection coordination information for conditional secondary node processes
WO2024091704A1 (en) Managing master node communication in conditional dual connectivity
WO2023212131A1 (en) Handling of multiple target secondary nodes in an sn-initiated conditional secondary node change
CN117296376A (en) Managing radio resources and downlink transmissions during handover
WO2023133241A1 (en) Managing candidate cell configurations for conditional preparation procedures
WO2023133272A1 (en) Managing cell group configurations for conditional secondary node procedures
AU2023205209A1 (en) Managing cell group configurations for conditional secondary node procedures
WO2024073748A1 (en) Managing communication failures in a user equipment
WO2024064392A1 (en) Managing a fast serving cell change in a disaggregated base station

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication