Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 22.261  Word version:   17.2.0

Top   Up   Prev   Next
0…   4…   6…   6.4…   6.8…   6.12…   6.22…   6.26…   7…   8…   A   B   C   D…   F…

 

6.22  Unified access control [R16]
6.22.1  Description
Depending on operator's policies, deployment scenarios, subscriber profiles, and available services, different criterion will be used in determining which access attempt should be allowed or blocked when congestion occurs in the 5G System. These different criteria for access control are associated with Access Identities and Access Categories. The 5G system will provide a single unified access control where operators control accesses based on these two.
In unified access control, each access attempt is categorized into one or more of the Access Identities and one of the Access Categories. Based on the access control information applicable for the corresponding Access Identity and Access Category of the access attempt, the UE performs a test whether the actual access attempt can be made or not.
The unified access control supports extensibility to allow inclusion of additional standardized Access Identities and Access Categories and supports flexibility to allow operators to define operator-defined Access Categories using their own criterion (e.g. network slicing, application, and application server).
NOTE:
Clauses 4.1 through 4.4a of TS 22.011 are obsolete and replaced by clause 6.22.2 of this specification. However, when a UE is configured for EAB according to TS 22.011, the UE is also configured for delay tolerant service for 5G system.
Up
6.22.2  Requirements
6.22.2.1  General
Based on operator's policy, the 5G system shall be able to prevent UEs from accessing the network using relevant barring parameters that vary depending on Access Identity and Access Category. Access Identities are configured at the UE as listed in Table 6.22.2.2-1. Access Categories are defined by the combination of conditions related to UE and the type of access attempt as listed in Table 6.22.2.3-1. One or more Access Identities and only one Access Category are selected and tested for an access attempt.
The 5G network shall be able to broadcast barring control information (i.e. a list of barring parameters associated with an Access Identity and an Access Category) in one or more areas of the RAN.
The UE shall be able to determine whether or not a particular new access attempt is allowed based on barring parameters that the UE receives from the broadcast barring control information and the configuration in the UE.
In the case of multiple core networks sharing the same RAN, the RAN shall be able to apply access control for the different core networks individually.
The unified access control framework shall be applicable both to UEs accessing the 5G CN using E-UTRA and to UEs accessing the 5G CN using NR.
The unified access control framework shall be applicable to UEs in RRC Idle, RRC Inactive, and RRC Connected at the time of initiating a new access attempt (e.g. new session request).
NOTE 1:
"new session request" in RRC Connected refers to events, e.g. new MMTEL voice or video session, sending of SMS (SMS over IP, or SMS over NAS), sending of IMS registration related signalling, new PDU session establishment, existing PDU session modification, and service request to re-establish the user plane for an existing PDU session.
The 5G system shall support means by which the operator can define operator-defined Access Categories to be mutually exclusive.
NOTE 2:
Examples of criterion of operator-defined Access Categories are network slicing, application, and application server.
The unified access control framework shall be applicable to inbound roamers to a PLMN.
The serving PLMN should be able to provide the definition of operator-defined Access Categories to the UE.
Up
6.22.2.2  Access identitiesWord-p. 35
Access Identity number
UE configuration

0
UE is not configured with any parameters from this table
1 (NOTE 1)
UE is configured for Multimedia Priority Service (MPS).
2 (NOTE 2)
UE is configured for Mission Critical Service (MCS).
3
UE for which Disaster Condition applies (note 4)
3-10
Reserved for future use
11 (NOTE 3)
Access Class 11 is configured in the UE.
12 (NOTE 3)
Access Class 12 is configured in the UE.
13 (NOTE 3)
Access Class 13 is configured in the UE.
14 (NOTE 3)
Access Class 14 is configured in the UE.
15 (NOTE 3)
Access Class 15 is configured in the UE.

NOTE 1:
Access Identity 1 is used by UEs configured for MPS, in the PLMNs where the configuration is valid. The PLMNs where the configuration is valid are HPLMN, PLMNs equivalent to HPLMN, and visited PLMNs of the home country.
Access Identity 1 is also valid when the UE is explicitly authorized by the network based on specific configured PLMNs inside and outside the home country.
NOTE 2:
Access Identity 2 is used by UEs configured for MCS, in the PLMNs where the configuration is valid. The PLMNs where the configuration is valid are HPLMN or PLMNs equivalent to HPLMN and visited PLMNs of the home country. Access Identity 2 is also valid when the UE is explicitly authorized by the network based on specific configured PLMNs inside and outside the home country.
NOTE 3:
Access Identities 11 and 15 are valid in Home PLMN only if the EHPLMN list is not present or in any EHPLMN. Access Identities 12, 13 and 14 are valid in Home PLMN and visited PLMNs of home country only. For this purpose, the home country is defined as the country of the MCC part of the IMSI.
NOTE 4:
The configuration is valid for PLMNs that indicate to potential Disaster Inbound Roamers that the UEs can access the PLMN. See clause 6.31.

Any number of these Access Identities may be barred at any one time.
Up
6.22.2.3  Access categories
Access Category number
Conditions related to UE
Type of access attempt

0
All
MO signalling resulting from paging
1 (NOTE 1)
UE is configured for delay tolerant service and subject to access control for Access Category 1, which is judged based on relation of UE's HPLMN and the selected PLMN.
All except for Emergency, or MO exception data
2
All
Emergency
3
All except for the conditions in Access Category 1.
MO signalling on NAS level resulting from other than paging
4
All except for the conditions in Access Category 1.
MMTEL voice (NOTE 3)
5
All except for the conditions in Access Category 1.
MMTEL video
6
All except for the conditions in Access Category 1.
SMS
7
All except for the conditions in Access Category 1.
MO data that do not belong to any other Access Categories (NOTE 4)
8
All except for the conditions in Access Category 1
MO signalling on RRC level resulting from other than paging
9
All except for the conditions in Access Category 1
MO IMS registration related signalling (NOTE 5)
10 (NOTE 6)
All
MO exception data
11-31
Reserved standardized Access Categories
32-63 (NOTE 2)
All
Based on operator classification

NOTE 1:
The barring parameter for Access Category 1 is accompanied with information that define whether Access Category applies to UEs within one of the following categories:
  1. UEs that are configured for delay tolerant service;
  2. UEs that are configured for delay tolerant service and are neither in their HPLMN nor in a PLMN that is equivalent to it;
  3. UEs that are configured for delay tolerant service and are neither in the PLMN listed as most preferred PLMN of the country where the UE is roaming in the operator-defined PLMN selector list on the SIM/USIM, nor in their HPLMN nor in a PLMN that is equivalent to their HPLMN.
When a UE is configured for EAB, the UE is also configured for delay tolerant service. In case a UE is configured both for EAB and for EAB override, when upper layer indicates to override Access Category 1, then Access Category 1 is not applicable.
NOTE 2:
When there are an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is neither 0 nor 2, the UE applies the Access Category based on operator classification. When there are an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is 0 or 2, the UE applies the standardized Access Category.
NOTE 3:
Includes Real-Time Text (RTT).
NOTE 4:
Includes IMS Messaging.
NOTE 5:
Includes IMS registration related signalling, e.g. IMS initial registration, re-registration, and subscription refresh.
NOTE 6:
Applies to an NB-IoT UE, using NB-IOT connectivity to 5GC.

Access Category 0 shall not be barred, irrespective of Access Identities.
NOTE:
The network can control the amount of access attempts relating to Access Category 0 by controlling whether to send paging or not.
Up
6.23  QoS Monitoring [R16]Word-p. 36
6.23.1  Description
The QoS requirements specified for particular services such as URLLC services, vertical automation communication services, and V2X, mandate QoS guarantees from the network. However, the network may not be able to always guarantee the required QoS of the service. An example reason for this shortcoming is that the latency and/or packet error rate increase due to interference in a radio cell. In such cases, it is critical that the application and/or application server is notified in a timely manner. Hence, the 5G system should be able to support QoS monitoring/assurance for URLLC services, V2X and vertical automation.
For more information on QoS assurance see Annex F.
Vertical automation systems are locally distributed and are typically served by wired and wireless communication networks of different types and with different characteristics. If the operation of the system or one of its sub-processes does not work properly, there is a need for quickly finding and eliminating the related error or fault in order to avoid significant operation and thus financial losses. To that end, automation devices and applications implement diagnosis and error-analysis algorithms, as well as predictive maintenance features.
Due to their inherent challenges, wireless communication systems are usually under suspicion in case an error occurs in a distributed automation application. Therefore, diagnosis and fault analysis features for 5G systems are required. The 5G system needs to provide sufficient monitoring information as input for such diagnosis features.
QoS monitoring can be used for the following activities:
  • assessing and assuring the dependability of network operation;
  • assessing and assuring the dependability of the communication services;
  • excluding particular communication errors;
  • identifying communication errors;
  • analysing the location of an error including the geographic location of the involved network component (UE; front-haul component; core node);
  • activation of application-related countermeasures.
Up
6.23.2  RequirementsWord-p. 37
The 5G system shall provide a mechanism for supporting real time E2E QoS monitoring within a system.
The 5G network shall provide an interface to application for QoS monitoring (e.g. to initiate QoS monitoring, request QoS parameters, events, logging information).
The 5G system shall be able to provide real time QoS parameters and events information to an authorized application / network entity.
NOTE:
The QoS parameters to be monitored and reported can include latency (e.g. UL/DL or round trip), jitter, packet loss rate.
The 5G system shall be able to log the history of the communication events. This includes for examples parts of the SLA that are not met, time-stamp of the events, and event position (e.g. UEs and radio access points associated with the events).
The 5G system shall support different levels of granularity for QoS monitoring (e.g. per flow or set of flows).
The 5G system shall be able to provide event notification upon detecting error that the negotiated QoS level cannot be met/guaranteed.
The 5G system shall be able to provide information that identifies the type and the location of a communication error. (e.g. cell id).
The 5G system shall be able to provide notification of communication events to authorized entities per pre-defined patterns (e.g. every time the bandwidth drops below a pre-defined threshold for QoS parameters the authorized entity is notified and event is logged).
The 5G system shall be able to respond to a request from an authorized entityto provide real-time QoS monitoring information within a specified time after receiving the request (e.g. within 5s).
The 5G system shall support an update/ refresh rate for real time QoS monitoring within a specified time (e.g. at least 1 per second).
The 5G system shall be able to provide statistical information of service parameters and error types while a communication service is in operation.
The 5G system shall provide information on the current availability of a specific communication service in a particular area (e.g. cell id) upon request of an authorized entity.
Up
6.24  Ethernet transport services [R16]Word-p. 38
6.24.1  Description
This clause includes common, fundamental Ethernet transport requirements, and any requirements necessary to support a 5G LAN-type service. The requirements applicable to the 5G system for supporting cyber-physical applications using Ethernet are described in 3GPP TS 22.104.
6.24.2  Requirements
The 3GPP system shall be able to support an Ethernet transport service.
The 5G network shall support the routing of non-IP packet (e.g. Ethernet frame) efficiently for private communication between UEs within a 5G LAN-type service.
The 5G network shall be able to provide the required QoS (e.g. reliability, latency, and bandwidth) for non-IP packet (e.g. Ethernet frame) for private communication between UEs within a 5G LAN-type service.
The Ethernet transport service shall support routing based on information extracted from Virtual LAN (VLAN) ID by the 3GPP system.
The Ethernet transport service shall support the transport of Ethernet frames between UEs that Ethernet devices are connected to.
The Ethernet transport service shall support the transport of Ethernet frames between a UE that an Ethernet device is connected to and an Ethernet network in DN (Data Network).
NOTE:
If more than one Ethernet devices need to be connected to a UE, they can be connected using an Ethernet switch between the devices and the UE.
The Ethernet transport service shall support the transport of Ethernet broadcast frames.
The Ethernet transport service shall support traffic filtering and prioritization based on source and destination MAC addresses.
The Ethernet transport service shall support traffic filtering and prioritization based on Ethertype (including multiple Ethertypes in double tagging)
The Ethernet transport service shall support traffic filtering and prioritization based on 802.1Q VLAN tags (including double tagging).
The Ethernet transport service shall support routing based on information extracted by the 3GPP system from the Bridge Protocol Data Units created in the Ethernet network based on a Spanning Tree Protocol (e.g. RSTP).
Up
6.25  Non-public networks [R16]
6.25.1  Description
Non-public networks are intended for the sole use of a private entity such as an enterprise, and may be deployed in a variety of configurations, utilising both virtual and physical elements. Specifically, they may be deployed as completely standalone networks, they may be hosted by a PLMN, or they may be offered as a slice of a PLMN.
In any of these deployment options, it is expected that unauthorized UEs, those that are not associated with the enterprise, will not attempt to access the non-public network, which could result in resources being used to reject that UE and thereby not be available for the UEs of the enterprise. It is also expected that UEs of the enterprise will not attempt to access a network they are not authorized to access. For example, some enterprise UEs may be restricted to only access the non-public network of the enterprise, even if PLMN coverage is available in the same geographic area. Other enterprise UEs may be able to access both a non-public network and a PLMN where specifically allowed.
Up
6.25.2  RequirementsWord-p. 39
The 5G system shall support non-public networks.
The 5G system shall support non-public networks that provide coverage within a specific geographic area.
The 5G system shall support both physical and virtual non-public networks.
The 5G system shall support standalone operation of a non-public network, i.e. a non-public network may be able to operate without dependency on a PLMN.
Subject to an agreement between the operators and service providers, operator policies and the regional or national regulatory requirements, the 5G system shall support for non-public network subscribers:
  • access to subscribed PLMN services via the non-public network;
  • seamless service continuity for subscribed PLMN services between a non-public network and a PLMN;
  • access to selected non-public network services via a PLMN;
  • seamless service continuity for non-public network services between a non-public network and a PLMN.
Subject to regional or national regulatory requirements for emergency services, 5G system shall be able to support IMS emergency services for non-public networks.
A non-public network subscriber to access a PLMN service shall have a service subscription using 3GPP identifiers and credentials provided or accepted by a PLMN.
The 5G system shall support a mechanism for a UE to identify and select a non-public network.
NOTE:
Different network selection mechanisms may be used for physical vs virtual non-public networks.
The 5G system shall support identifiers for a large number of non-public networks to minimize collision likelihood between assigned identifiers.
The 5G system shall support a mechanism to prevent a UE with a subscription to a non-public network from automatically selecting and attaching to a PLMN or non-public network it is not authorized to select.
The 5G system shall support a mechanism to prevent a UE with a subscription to a PLMN from automatically selecting and attaching to a non-public network it is not authorized to select.
The 5G system shall support a mechanism for a PLMN to control whether a user of a UE can manually select a non-public network hosted by this PLMN that the UE is not authorized to select automatically.
The 5G system shall support a change of host of a non-public network from one PLMN to another PLMN without changing the network selection information stored in the UEs of the non-public network.
Up

Up   Top   ToC