Patent Application
20250113185
This disclosure is directed generally to wireless communications, and particularly to a method, device, and system for ensuring security related to Secondary Carrier Group (SCG) and/or Secondary Node (SN) in a wireless network.
With the rapid evolution of wireless communication technology, and to satisfy the demand for higher speed, higher throughput and capacity, higher efficiency, and lower latency, dual connectivity is introduced in which two base stations are employed to support a Master Carrier Group (MCG) and an SCG. Switching between SCGs and addition of a new SCG, as well as switching between cells within a same SCG are supported in order to achieve robust secondary connection. It is critical to minimize the execution time and improve performance for these procedures.
This disclosure is directed to a method, device, and system for ensuring security related to SCG and/or SN in a wireless network.
In some embodiments, a method performed by a wireless device is disclosed. The method may include: in response to an execution condition being satisfied, selecting a target Primary Secondary cell (PScell) in a Radio Access Network (RAN), the target PScell being associated with a target secondary node (SN), wherein the target SN is a member of a list of SNs, each SN in the list of SNs is associated with a SN counter, and the SN counter associated with the each SN in the list of SNs is used for calculating a security key for the each SN in the list of SNs; determining whether a SN counter associated with the target SN needs to be updated; in determination that the SN counter associated with the target SN needs to be updated, selecting a refreshed SN counter value and updating at least the SN counter associated with the target SN with the refreshed SN counter value, wherein the refreshed SN counter value is different from any prior SN counter values shared between the wireless device and a master node; and transmitting, to the master node, a first message requesting switching from a current PScell to the target PScell, the first message comprising the refreshed SN counter value.
In some embodiments, a method performed by a master network node in a Radio Access Network (RAN) is disclosed. The method may include: receiving, from a wireless device, a first message requesting switching the wireless device from a current PScell to a target PScell, the first message comprising a refreshed SN counter value for updating an SN counter, wherein the refreshed SN counter value indicates that a target SN associated with the target PScell is different from an SN associated with the current PScell.
In some embodiments, there is a wireless device, a network element, or a network node comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement any methods recited in any of the embodiments.
In some embodiments, a computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement any method recited in any of the embodiments.
The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.
The gNB 124 may include a central unit (CU) and at least one distributed unit (DU). The CU and the DU may be co-located in a same location, or they may be split in different locations. The CU and the DU may be connected via an F1 interface. Alternatively, for an eNB which is capable of connecting to the 5G network, it may also be similarly divided into a CU and at least one DU, referred to as ng-eNB-CU and ng-eNB-DU, respectively. The ng-eNB-CU and the ng-eNB-DU may be connected via a W1 interface.
The wireless communication network 100 may include one or more tracking areas. A tracking area may include a set of cells managed by at least one base station. For example, tracking area 1 labeled as 140 includes cell 1, cell 2, and cell 3, and may further include more cells that may be managed by other base stations and not shown in
The wireless communication network 100 may be implemented as, for example, a 2G, 3G, 4G/LTE, or 5G cellular communication network. Correspondingly, the base stations 122 and 124 may be implemented as a 2G base station, a 3G NodeB, an LTE eNB, or a 5G NR gNB. The UE 160 may be implemented as mobile or fixed communication devices which are capable of accessing the wireless communication network 100. The UE 160 may include but is not limited to mobile phones, laptop computers, tablets, personal digital assistants, wearable devices, Internet of Things (IoT) devices, MTC/eMTC devices, distributed remote sensor devices, roadside assistant equipment, XR devices, and desktop computers. The UE 160 may also be generally referred to as a wireless communication device, or a wireless terminal. The UE 160 may support sidelink communication to another UE via a PC5 interface.
While the description below focuses on cellular wireless communication systems as shown in
The electronic device 200 may also include system circuitry 204. System circuitry 204 may include processor(s) 221 and/or memory 222. Memory 222 may include an operating system 224, instructions 226, and parameters 228. Instructions 226 may be configured for the one or more of the processors 221 to perform the functions of the network node. The parameters 228 may include parameters to support execution of the instructions 226. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and/or other parameters.
Referring to
Referring to
Network Deployment with Dual Connectivity
With the rapid evolution of wireless communication technology, and to satisfy the demand for higher speed, higher throughput and capacity, higher efficiency, and lower latency, a Dual Connectivity (DC) feature is introduced. In general, in a DC deployment, a UE is allowed to be connected to two base stations (or two nodes) and send/receive data via both base stations. The two base stations may be of same type. For example, both base stations may be eNBs, gNBs, ng-eNBs, and the like. The two base stations may also be of different types. The core network to support the DC deployment may include, for example, an LTE Evolved Packet Core (EPC), or a 5G core.
In a DC deployment, one of the nodes acts as the Master Node (MN) and the other acts as the Secondary Node (SN). In some example implementations, MN is the node to which the UE first connects. Subsequently, UE may connect to the SN.
In some example implementations, only MN is used to provide the control plane connection between the UE and the Core Network. Whereas SN provides additional resources to carry user plane traffic.
In some example implementations, SN may also carry signaling messages.
Example DC configurations include EN-DC (E-UTRA-NR Dual Connectivity), NE-DC (NR-E-UTRA Dual Connectivity), NR-DC (New Radio Dual Connectivity), NGEN-DC (NG-RAN-E-UTRA Dual Connectivity), etc. Exemplarily, an MN may be an eNB (in EN-DC), an ng-eNB (in NGEN-DC), or a gNB (in NR-DC and NE-DC). An SN may be an en-gNB (in EN-DC), an ng-eNB (in NE-DC), or a gNB (in NR-DC and NGEN-DC).
Under certain deployments, DC may be configured in combination with Carrier Aggregation (CA), in which both MN and SN may be associated with multiple cells or carriers. These aggregated carriers are collectively called Master Cell Group (MCG) and Secondary Cell Group (SCG). Note that the MCG is associated with the MN, and the SCG is associated with the SN. Further note that an MCG may implicit imply the MN it associates with, and a SCG may implicit imply the SN it associates with.
Referring to
The MCG may include a group of serving cells associated with the MN, including a Primary cell (PCell) and optionally one or more Secondary cells (Scells). The SCG may include a group of serving cells associated with the SN, including a Primary SCG Cell (PScell) and optionally one or more Scells. In
In some implementations, a UE may connect to one MN, but may switch from one SCG to another SCG; or the UE may switch PScell within a same SCG.
In some example implementations, an SN may be added or changed (modified) by an MN. For example, the UE may switch from one SCG to another SCG (i.e., switch from on SN to another SN) and a PScell change will occur.
step 1
UE establishes a Radio Resource Control (RRC) connection with MN.
step 2
MN sends an SN Addition/Modification Request to the SN over the Xn-C to negotiate available resources, configuration, and algorithms (e.g., security algorithm) at the SN. If a new security key for the SN (KSN) is needed, the MN may compute and deliver it to the SN. The UE security capabilities and the User Plane (UP) security policy may also be sent to SN.
The UE security capabilities may include capabilities for Next Generation Radio Access Network (NG-RAN), 5G Non-Access Stratum (NAS), 5G Access Stratum (AS), and may further include capabilities for Evolved Packet System (EPS), Universal Terrestrial Radio Access Network (UTRAN), and GSM EDGE Radio Access Network (GERAN), if these access types are supported by the UE. The UP security policy may be used to activate UP confidentiality and/or UP integrity for one or more DRBs belonging to a PDU session associated with the UE.
In case of PDU split, UP integrity protection and ciphering activation decision from MN may be also included in the request.
step 3
The SN allocates the necessary resources, such as radio resources, transport network resources. SN may also choose the ciphering algorithm and integrity algorithm which has the highest priority from its configured list and is also present in the UE security capability. If a new KSN was delivered to the SN in step 2, then the SN may compute an RRC key as well as UP keys. The SN may then activate the UP security policy based on the UP keys.
step 4
The SN sends SN Addition/Modification Acknowledge to the MN indicating availability of requested resources and the identifiers for the selected algorithm(s) for the requested Data Radio Bearers (DRBs) and/or Signaling Radio Bearers (SRBs) for the UE. The UP integrity protection and encryption indications may also be sent to the MN.
step 5
The MN sends the RRC Connection Reconfiguration Request to the UE instructing it to configure the new DRBs and/or SRBs for the SN. The MN may include the SN Counter parameter to indicate that a new KSN is needed and UE needs to compute the KSN for the SN. The MN forwards the UE configuration parameters (which contains the algorithm identifier(s) received from the SN in step 4), as well as UP integrity protection and encryption indications (received from the SN in step 4) to the UE.
Note that this message is sent over the RRC connection between the MN and the UE, and it is integrity protected using the KRRCint (an RRC security key) of the MN. Therefore, the SN Counter is tamper-proof.
step 6
The UE accepts the RRC Connection Reconfiguration Request after validating its integrity. The UE computes the KSN for the SN if an SN Counter parameter was included. The UE may also compute the needed RRC key and UP key, and activate the RRC and UP protection as per the indications received for the associated SRBs and/or DRBs. The UE sends an RRC Reconfiguration Complete message to the MN. The UE may choose to activate the selected encryption/decryption and integrity protection keys with the SN at this point.
step 7
The MN sends an SN Reconfiguration Complete message to the SN, for example, via the Xn-C interface, to inform the SN of the configuration result. On receipt of this message, SN may choose to activate the selected encryption/decryption and integrity protection with UE. Or, if SN does not activate encryption/decryption and integrity protection with the UE at this stage, SN may activate encryption/decryption and integrity protection upon receiving a random access request from the UE.
In this SN addition/modification procedure, the KSN is used for securing connection between the UE and the SN. The UE may calculate the KSN by its own, whereas the SN relies on the MN for the delivery of the KSN.
In some example implementations, the KSN may be derived by a Key Derivation Function (KDF). The KDF may be based on Hash-based Message Authentication Code Secure Hash Algorithm 256 (HMAC-SHA-256). Equation 1 below shows an example for deriving KSN using the KDF:
In equation 1, the KDF has two input: an input key, and a string S. The string S may be a concatenation of multiple strings, for example, by using equation 2 below:
In equation 2, FC is the function code. In the concatenation, there are multiple parameters (from P0 to Pn, n being a non-negative integer), as well as a length (i.e., L0, L1, . . . . Ln) for each parameter.
As an example, for deriving KSN , following input may be used:
The input key may be the key for the MN, which may include the KeNB when the MN is an ng-eNB, and KgNB when the MN is a gNB.
In the SN addition/modification procedure described in the previous section, a decision for SN addition/modification is made by the MN. Once the MN triggers the procedure, preparation effort, including resource allocation, capability negotiation, algorithm selection, need to be taken by the SN and the UE. A service delay may be introduced by the preparation effort. Therefore, to expedite the procedure and reduce the duration of service interruption, it is desirable to reduce or even get rid of the preparation effort, such that once after the SN addition/modification decision is made, the link between the UE and the SN may be established with minimized effort.
One solution is to move the preparation effort or the preparation phase to an earlier stage, before the SN addition/modification decision is made.
A UE may be preconfigured with a candidate SN pool which includes multiple candidate SNs. For each candidate SN, the UE may be configured with configurations related to, for example, resource allocation, capability negotiation, algorithm selection, etc. The UE may also be configured with execution conditions used for evaluating and triggering SN addition or modification. For a same candidate SN, there may be different execution conditions serving different purposes, such as execution condition for SN addition, and execution condition for SN modification. Further, in some example implementations, a candidate SN may support multiple configurations, for example, configurations serving different Quality of Service (QOS), different security levels, or different throughput. Correspondingly, the UE may evaluate multiple execution conditions for a candidate SN, and may choose an SN configuration that matches a satisfied execution condition.
The SN configurations may be used for Conditional PScell Addition (CPA), and/or Conditional PScell Change (CPC), in the sense that the PScell Addition and PScell Change are triggered when the condition defined by the execution condition is met.
Referring to
Similarly, for each candidate SN, pre-configuration may also be performed to support the CPA/CPC procedure. For example, the candidate SN may be configured with UE capability and UE security preference, to minimize negotiation effort once after the candidate SN is selected for SN addition or modification.
In this embodiment, the UE is preconfigured with candidate SN/SCG configurations to expedite CPC/CPA procedure. The KSN is synchronized between the UE and a target SN when the UE triggers the CPC/CPA procedure. Note that the KSN may be derived based on equation 1 as described earlier.
Under a CPA/CPC procedure, a UE may stick to a Pcell in an MCG, and either add a new PScell, or switch to a another PScell in a different or a same SCG (or SN). The UE may keep the preconfigured SN/SCG configurations, and may switch back and forth to a same PScell multiple times. Depending on the different PScell addition/switching scenarios, the KSN for the SN that is used for securing the link between the UE and the SN may be re-used, or may need to be refreshed to enforce security. In this embodiment, a KSN refresh mechanism is described in great details.
When UE is configured with multiple candidate SNs, for securing the link between the UE and a candidate SN, a security key for the candidate SN, namely KS, is used. The KSN may be derived based on equations 1 and 2 as described above. In particular, the input key may be the security key for the MN, for example, KgNB if the MN is a gNB, or Kng-eNB if the MN is an ng-eNB. P0 may be the SN Counter corresponding to the candidate SN.
In example implementations, all the candidate SNs may be associated with a same MN, and therefore the input key for deriving their respective KSN may be the same.
There are several security requirements for KSN. First, each candidate SN has its own unique KSN. Second, for a same candidate SN, there is a refresh requirement, such that under certain condition, the KSN will need to be refreshed, or updated. More details will be described in later paragraphs.
step 0
A UE may be preconfigured with a candidate SN pool (or SCG pool) which includes multiple candidate SNs (or multiple candidate SCGs). Referring back to
In some example implementations, the MN may assign a unique initial value to each of the SN counters. For example, the initial values for the 3 SN counters 616, 618, and 620 as shown in
In the SN side, each candidate SN can be prepared for the subsequent CPC/CPA execution in advance.
step 1
The UE evaluates the execution conditions. If the CPA/CPC execution condition is met for a particular PScell under a candidate SN, the UE will select the PScell (and its associated candidate SN, also referred to as the target SN) and proceed with the CPA/CPC procedure. The execution condition for CPA and CPC may be different.
As an example, referring to
step 2
The UE triggers the CPC/CPA procedure towards the selected PSCell, by sending a CPC/CPA Request message to MN. The message may include at least one of: the SN counter for the target SN (i.e., candidate SN associated with the selected PSCell); or an identifier, such as an the PSCell id of the selected PSCell, for identifying the target SN associated with the selected PScell. One of the goals for the UE to forward the SN counter to the MN is to keep the SN counter in synchronization between the UE and the MN. Therefore, instead of the SN counter itself, it is also possible to include an SN counter update indication in the CPC/CPA Request message, so the UE and the MN may update the SN counter in a synchronized manner.
The SN counter for the target SN associated with the selected PSCell may or may not need to be refreshed (updated) from a current value. In the event that the selected PSCell is associated with a SN that is different from the SN associated with the current PScell in a dual connectivity, the SN counter needs to be refreshed. The KSN for the candidate SN also needs to be updated, and the UE will need to re-compute the KSN based on the refreshed SN counter (i.e., a refresh on the SN counter triggers the KSN update).
As an example, referring to
As another example, referring to
In some example implementations, the UE maintains an SN counter for each SN. When refreshing the SN counter of the selected (target) SN, the UE may determine the maximum value of all SN counters maintained by it, and increase the maximum value by an offset (e.g., predefined positive integer, such as 1), to obtain a refreshed value for the SN counter of the selected SN, note that the refreshed value has not been used for computing the KSN for any candidate SN. The offset may be configured by the MN.
As an example, assuming that before the SN counter refresh, the UE maintains 3 SN counters with following values:
Assuming UE needs to refresh the SN counter for SN 2 based on the determination logic described above, the UE first determines that the maximum value of all SN counters is 2 (i.e., SN 3 counter value), increment it by 1, to obtain a refreshed value for SN 2 counter, and update SN 2 counter. After the refresh, the 3 SN counters have following values (with SN 2 counter value updated):
SN 1 counter: 0; SN 2 counter: 3; SN 3 counter: 2.
As an SN counter has an upper limit, in the event the SN counter reaches its upper limit, a reset on the counter would need to occur. Each reset marks a new cycle of the SN counter. In such a reset event, all SN counters may be reset to, for example, their initial preconfigured value (e.g., set by the MN). Meanwhile, the input key to the KDF for deriving the KSN will also be updated to a new key not previously used. Therefore, when considering the SN counter reset, the requirement will be that within each cycle of the SN counter, the refreshed counter value should not have been used for computing the KSN for any candidate SN.
In some example implementations, the UE maintains an SN counter for each SN. The UE may refresh the SN counter with a random number, that has not been used for computing the KSN for any candidate SN. The SN counter reset rule may also apply.
Upon receiving the updated SN counter, the MN stores it, and calculates an updated KSN based on it.
step 3
The MN sends an SN Addition/Modification Request to the SN (i.e., the target SN), for example, via the Xn-C interface. The MN also delivers the KSN to the SN if a new KSN is computed in step 2.
step 4
The SN sends an SN Addition/Modification Request Acknowledge message to the MN, for example, via the Xn-C interface. SN may activate the chosen encryption/decryption and integrity protection with UE, based on pre-configured configurations. If SN does not activate encryption/decryption and integrity protection with the UE at this stage, SN may choose to activate encryption/decryption and integrity protection upon receiving the Random Access request from the UE. Note that if in step 3, an updated KSN is sent to the SN, then the encryption/decryption and integrity protection are based on the updated KSN, otherwise the current KSN may be used for the security protection.
step 5
The MN sends the CPC/CPA Request Acknowledge message to UE. On receipt of this message, the UE may activate the chosen encryption/decryption and integrity protection keys with the SN at this point.
In this embodiment, a UE maintains an SN counter for each candidate SN in a candidate SN pool (e.g.,
This embodiment is similar to embodiment 1, except that the UE maintains the SN counters in a different manner.
In some example implementations, the UE maintains an SN counter for each candidate SN in a candidate SN pool. Each of these SN counters is preconfigured with a same initial value (e.g., 0). When the UE determines that an SN counter associated with a target SN needs to be refreshed (by following similar logic as described in step 2 of embodiment 1), the UE may uniformly increase all SN counters by a predefined offset (e.g., predefined positive integer, such as 1), so all the SN counters keep a same value. Alternatively, the UE may uniformly set all SN counters to a same random integer that has not been used for computing the KSN for any candidate SN. Note that the SN counter cycle concept as described in embodiment 1 may still apply.
In some example implementations, instead of maintain an SN counter for each candidate SN, a single SN counter is employed by the UE, which covers all the candidate SNs. When the UE determines that an SN counter associated with a target SN needs to be refreshed (by following similar logic as described in step 2 of embodiment 1), the UE may increase the SN counters by a predefined offset (e.g., predefined positive integer, such as 1). Alternatively, the UE may set the SN counter to a random integer that has not been used for computing the KSN for any candidate SN. Note that the SN counter cycle concept as described in embodiment 1 may still apply.
The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.
Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.
In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and,” “or”, or “and/or,” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures, or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for the existence of additional factors not necessarily expressly described, again, depending at least in part on context.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2023/070848 | Jan 2023 | WO |
| Child | 18978893 | US |
