Patent Application
20230276341
Disclosed are embodiments related to access control for mission critical (MC) communication devices and/or services.
Before a user equipment (UE) (i.e., a communication device capable of communicating wirelessly with an access point (e.g., a base station)) can properly communicate within another communication device (e.g., a server), the UE must perform what is known as “cell search” to find, identify, and synchronize with a cell served by an access point. Then, the UE must acquire basic system information, and perform an access barring check to determine whether or not the UE is allowed to use the cell for network connectivity. If the access is allowed, the UE will then perform what is known as a “random access” (RA) procedure to establish a connection (e.g., a Radio Resource Control (RRC) connection) with the access point. Examples of UEs include: smartphones, sensors, appliances, meters, computers, servers, etc.
1. New Radio (NR) Cell Search and System Information Acquisition
In NR, the combination of a synchronization signal (SS) and a physical broadcast channel (PBCH) is referred to as a SS/PBCH block (SSB). Similar to LTE, a pair of synchronization signals (i.e., a primary synchronization signal (PSS) and secondary synchronization signal (SSS)), is periodically transmitted on downlink from each cell to allow a UE to initially access to the network. By detecting a SS, a UE can obtain the physical cell identity, achieve downlink synchronization in both time and frequency, and acquire the timing for the PBCH.
The PBCH carries a master information block (MIB), which contains system information from which the UE can know if the cell is barred and the info on how to acquire system information block 1 (SIB1). This SIB1 carries the additional system information that is needed for a UE to be able to perform access barring control and the subsequent random access procedure if the access request can be sent.
2. NR Unified Access Control
Before sending any connection request to base station (e.g., gNB), a UE shall evaluate the cell reservation and access restriction related information contained in SIB1 to check whether a connection request for the access attempt should be barred or not. This is done by the Unified Access Control (UAC) mechanism specified in 5G.
The UE maps its access attempt to an access category and one or more access identities. The access identities and access categories are defined in Table 1 (copied from Table 4.5.2.1 in 3GPP TS 24.501 v16.3.0) and Table 2 (copied form Table 4.5.2.2 in TS 24.501 v16.3.0), respectively. The information on cell access restrictions associated with access categories and access identities is broadcast in SIB 1. Based on this information received from SIB1, the UE determines whether an access attempt is authorized for the selected Public Land Mobile Network (PLMN), and the associated access category and access identity(ies) for the access attempt.
This UAC mechanism can effectively reduce the amount of traffic accessing the network shortly after SIB1 broadcasting. It also avoids an increase in network processing load because connection requests are barred, meaning that no connection request will be sent from the UE to the gNB.
3. NR Random Access (RA) Procedure
If an access attempt is permitted, the UE performs an RA procedure (e.g., the 4-step RA procedure) to establish an RRC connection to the gNB. During the RA procedure the UE will transmit an RRCSetupRequest message. The information elements (IEs) included in the RRCSetupRequest message are defined in 3GPP TS 38.331 and shown below in Table 3.
The establishmentCause IE contained in this RRCSetupRequest message indicates the reason for the connection establishment request, e.g., “emergency” for emergency calls, “mps-PriorityAccess” for multimedia-priority UEs and “mcs-PriorityAccess” for Mission Critical UEs, etc.
A UE sets the establishmentCause based on the configured access identities/access categories. The mapping between access categories/access identities and RRC establishment causes are shown in Table 4 below (copied from Table 4.5.6.1 of 3GPP TS 24.501 v16.3.0). A gNB identifies the type of connection request from a UE by decoding the establishmentCause, based on which, the gNB decides whether to accept the RRC connection request or to reject the request with RRCConectionReject. For instance, in a mission critical situation where the network is highly loaded, to guarantee the QoS for MC UEs (i.e., UEs configured for MC services) a gNB can prioritize the connection establishment for MC UEs and reject the requests from non-MC UEs.
Certain challenges presently exist. For instance, in some mission critical (MC) situations, not all MC UEs and/or MC services should be treated equally. For example, an access request from a UE that is being used by a commander in charge of coordinating several different groups of first responders may need higher priority than an access request transmitted by a UE being used by one of the first responders. That is, for example, the access requests from different MC UEs need to be treated with different priorities based on their operation roles, the importance of the data or services to be transmitted over the network, etc. According to the NR Rel-16 standard, all MC UEs are configured with access identity 2, which means that during initial access, the establishmentCause for all MC UEs will be set to mcs-PriorityAccess. This implies that a network node can't differentiate between different MC UEs (e.g., can't differentiate between a first MC UE that is attempting to invoke a first MC service and a second MC UE attempting to invoked a second MC service that has a lower priority than the first MC service). Thus, the network node (e.g., gNB) cannot perform differentiated access control during initial access phase.
Accordingly, in one aspect there is provided a method performed by a network node for configuring UEs. The method includes assigning a first access identity number to a first mission critical (MC) UE. The method also includes assigning a second access identity number to a second MC UE. The first access identity number is different than the second access identity number.
In another aspect, there is provided a method performed by a network node for configuring a UE. The method includes configuring the UE with an access identity number reserved for UEs configured for mission critical services (MCSs). The method also includes configuring the UE with a first rule that maps a first tuple comprising the access identity number and a first access category identifier to a first RRC establishment cause value. The method also includes configuring the UE with a second rule that maps a second tuple comprising the access identity number and a second access category identifier to a second RRC establishment cause value. The second access category identifier is different than the first access category identifier, and the second RRC establishment cause value is different than the first RRC establishment cause value.
In another aspect there is provided a method performed by a UE. The method includes the UE storing an access identity number, wherein the access identity number is reserved for UEs configured for an MCS. The method also includes the UE storing a first rule that maps a first tuple comprising the access identity number and a first access category identifier to a first Radio Resource Control, RRC, establishment cause value. The method also includes the UE storing a second rule that maps a second tuple comprising the access identity number and a second access category identifier to a second RRC establishment cause value. The second access category identifier is different than the first access category identifier, and the second RRC establishment cause value is different than the first RRC establishment cause value.
In another aspect there is provided a computer program comprising instructions which when executed by processing circuitry of a network node causes the network node to perform any one of the network node methods disclosed herein. In another aspect there is provided a carrier containing the computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium. In another aspect there is provided a network node, where the network node is configured to perform any one of the network node methods disclosed herein. In some embodiments, the network node includes processing circuitry and a memory containing instructions executable by the processing circuitry, whereby the network node is configured to perform any one of the network methods disclosed herein.
In another aspect there is provided a computer program comprising instructions which when executed by processing circuitry of a UE causes the UE to perform any one of the UE methods disclosed herein. In another aspect there is provided a carrier containing the computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium. In another aspect there is provided a UE, where the UE is configured to perform any one of the UE methods disclosed herein. In some embodiments, the UE includes processing circuitry and a memory containing instructions executable by the processing circuitry, whereby the UE is configured to perform any one of the network methods disclosed herein.
The aspects and embodiments disclosed herein are advantageous in that they enable that different MC UEs can use different establishment causes when attempting to establish an RRC connection. By enabling a differentiation among different MC UEs and/or MC services in establishment causes, this allows the network node to apply a different admission control at an early stage. Therefore, in an extreme network load situation, a network node can, for example, prioritize the more important MC services to access to the network first. In addition, the network node can utilize the information to predict the network load and the demanded additional resources, so that it can make better decisions on the load balancing, traffic management and queuing mechanism after an RRC connection has been established.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.
In many mission critical (MC) situations, the access requests from different MC UEs need to be treated with different priorities based on their operation roles, the importance of the data or services to be transmitted over the network, etc. For example, a central commander who coordinates the mission critical actions of a first responder group needs to be configured with a relatively higher priority, the first responders can be configured with a relatively lower priority. As another example, one MC UE group operating in a life-threatening situation needs to be configured with a higher priority, and the other MC UE groups can be configured with a relatively lower priority, even if they are all using the same service. Yet another example, an MC UE (e.g., a MC drone fleet leader or a MC rely device) that has a centralized decision or coordination role for the other MC devices may need to be configured with a relatively higher priority.
Accordingly, more than one RRC establishment cause is defined for MC UEs and/or MC services so that the network can distinguish between different MC UEs and/or MC services. Different methods of defining a more than one RRC establishment causes for MC UE/services are defined. Note that the examples focus on MC services, but the same methodology can be applied to other services, e.g., multimedia priority services.
1. Using Existing Access Identities
In this embodiment, existing establishment causes and access identities specified in 3GPP standard are utilized. This can be achieved by, for example, configuring one group of MC UEs (e.g., higher priority MC UEs) with Access Identity 2, and the configuring another group of MC UEs (e.g., lower priority MC UEs) with Access Identity 11, 12, 13, 14, or 15. That is, for example, when configuring an MC UE, a network operator can select an access identity for the MC UE from a set of two or more access identities (e.g., a set comprising the following access identities: 2, 11, 12, 13, 14, and 15), whereas today the network operator has no choice but to select the same access identity for all MC UEs (i.e., access identity 2).
Based on Table 4, the access attempts from higher priority MC UEs will be mapped to the establishment cause “mcs-PriorityAccess,” and the access attempts from lower priority MC UEs will be mapped to the establishment cause “highPriorityAccess.” A network node can prioritize between MC UEs mapped to “mcs-PriorityAccess” and MC UEs mapped to “highPrioirtyAccess,” depending on the current network load situation and the resource utilization status. That is, for example, an MC UE that uses “mcs-PriorityAccess” as the establishment cause can be given more resources than an MC UE that uses “highPriorityAccess” as the establishment cause.
In one embodiment, all MC UEs are provisioned with access identities from the value set {11, 12, 13, 14, 15} on their SIM/USIM card, and the core network can assign access identity 2 to UEs configured with higher priority mission critical services before these UEs apply access control.
This alternative utilizes the existing standardized differentiation indicators, and it can support differentiation between MC UEs base on, for example, their operation roles. A drawback of this method is that it is not possible for a network to acquire service type information of MC UEs, so prioritization for a certain type of MC service cannot be supported during initial access phase. Another drawback of this method is that the operator needs to make sure that the access identities from the value set {11, 12, 13, 14, 15} are not configured for non-MC UEs, otherwise the network node will not be able to distinguish between these non-MC UEs and the MC UEs whose access requests are mapped to “highPriorityAccess.” Yet another drawback of this method is that the network can have only up to two levels of priorities used between MC UEs, one mapped to “highPriorityAccess”, and the other one mapped to “mcs-PriorityAccess.”
2. New Establishment Cause(s)
In another embodiment one or more new establishment causes are defined. For example, in one embodiment, at least one new establishment cause is defined to provide more than one RRC establishment causes sent by different MC UEs. The additional establishment cause can be defined by using one of the six spared parameters that have not been defined for the establishmentCause field.
As a UE sets the establishmentCause based on the configured access identities/access categories, new mapping rules need to be added in the mapping table for access identities/access categories and RRC establishment cause to support a newly added establishment cause in the rrcSetupRequest message.
2.1 Define a New Access Identity Value for MC UEs
In one embodiment at least one new access identity value (e.g., 3) is defined for certain MC UEs. MC UEs configured with access identity 2 and MC UEs configured with the new access identity value (e.g., 3) may have different access priorities.
In one embodiment, the new access identity value is any value in the set of values 3-10 that are currently reserved for future use.
Table 6 and Table 7 give an example on the way of adding an additional establishment cause for differentiating MC UEs by defining a new access identity for MC UEs and modifying the mapping table for access identities/access categories and RRC establishment cause accordingly.
As can be seen by comparing Table 6 with Table 1, a new UE configuration and corresponding access identity (i.e., 3) has been added to the table provide an access identity for lower priority MC UEs, and as can be seen by comparing Table 7 with Table 4, a new rule (i.e., Rule 6) has been added to the table for MC UEs having an access identity of 3.
Because a dedicated access identity is standardized for MC UEs, the network can utilize one or more additional access identities (e.g., 3-10) together with the already specified access identity (i.e., 2) to differentiate between MC UEs configured with different priority MC services, without preventing using access identities 11-15 for other users with “highPriorityAccess”.
2.2: Define new standardized access categories for MC Services
In an embodiment, at least a new access category is standardized for differentiating different MC services during the initial access phase, and at least a new rule is defined for mapping the type of access attempt for the new access category.
In an embodiment, a new standardized access category in combination with the legacy access identity (i.e., access identity 2) is mapped to a new RRC establishment cause.
Table 8 and Table 9 give an example of additional establishment causes for differentiating MC Services by defining at least a few new access categories for MC Services and modifying the mapping table for access identities/access categories and RRC establishment cause accordingly. For example, as shown in Table 8, new access categories 10-13 are introduced.
In the example shown in Table 9, access identity 2 is used in combination with a set of new standardized access categories (i.e., 10-13 in this example) to obtain a set of new RRC establishment causes. Note that the legacy Rel-15/16 MC UEs will follow the legacy mapping table (Table 4), as the new release MC UEs and legacy MC UEs will have different RRC establishment cause values, the network node can distinguish the legacy MC UEs and new release MC UEs, therefore, no impact on legacy MC UE operations.
In an embodiment, a new standardized access category in combination with a new access identity (i.e., different from access identity 2) is mapped to a new RRC establishment cause.
In another example as shown in Table 10, a new access identity (access identity 3) is used together with a set of new access categories (e.g., 10-13) to define a set of new RRC establishment causes. Note that the legacy Rel-15/16 MC UEs will follow the legacy mapping table (Table 4), as the new release MC UEs and legacy MC UEs will have different RRC establishment cause values, the network node can distinguish the legacy MC UEs and new release MC UEs, therefore, no impact on legacy MC UE operations.
In an embodiment, a new standardized access category in combination with the legacy access identity is mapped to one new RRC establishment cause, the new standardized access category in combination with a new access identity is mapped to a different new RRC establishment cause.
In an example as shown in Table 11, a new access identity (access identity 3) is used together with a set of new access categories (10, 11, 12, and 13) to define a set of new RRC establishment causes; the legacy access identity (access identity 2) is also used together with the same set of new access categories (10, 11, 12, and 13) to define a different set of new RRC establishment causes. These two different sets of new RRC establishment causes are mapped to different priorities. For instance, the set of new RRC establishment causes associated to the access identity 2 is mapped to higher priority MC UEs/services, and the set of new RRC establishment causes associated to access identity 3 are mapped to lower priority MC UEs/Services.
Note that the legacy Rel-15/16 MC UEs will follow the legacy mapping table (Table 4), as the new release MC UEs and legacy MC UEs will have different RRC establishment cause values, the network node can distinguish the legacy MC UEs and new release MC UEs, therefore, no impact on legacy MC UE operations.
2.3: Define Different Operator-Defined Access Categories for MC Services
In an embodiment, at least an operator-defined access category is defined for differentiating different MC services. In the case where a UE has already attached and received a Non-Access Stratum (NAS) message (e.g., a message originating from an Access and Mobility Function (AMF)) before entering RRC Idle state, an operator-defined access categories can be defined for differentiation between different MC Services.
In some embodiments, the access identity number is an integer greater than 1 and less than 11 (i.e., between and including 2-10). In some embodiments, the access identity number is 2. In some embodiments, the access identity number is greater than 2 and less than 11 (e.g., 3). In some embodiments, the first access category identifier is 8 or an integer greater than 9 and less than 32, and the second access category identifier is 8 or an integer greater than 9 and less than 32.
While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.
Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.
This application is a 35 U.S.C. § 371 National Stage of International Patent Application No. PCT/EP2021/060031, filed Apr. 19, 2021, which claims priority to U.S. provisional patent application No. 63/015,822, filed on Apr. 27, 2020. The above identified applications are incorporated by this reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2021/060031 | 4/19/2021 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63015822 | Apr 2020 | US |
