Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 22.261  Word version:  19.0.0

Top   Top   Up   Prev   Next
0…   4…   6…   6.4…   6.8…   6.12…   6.22…   6.26…   6.30…   7…   7.4…   8…   D…   D.3…   F…

 

6.22  Unified access control |R16|p. 39

6.22.1  Descriptionp. 39

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).
Up

6.22.2  Requirementsp. 39

6.22.2.1  Generalp. 39

Based on operator 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).
The 5G system shall support means by which the operator can define operator-defined Access Categories to be mutually exclusive.
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 identitiesp. 40

Access Identity number UE configuration
0UE 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).
3UE for which Disaster Condition applies (Note 4)
4-10Reserved 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 categoriesp. 40

Access Category number Conditions related to UE Type of access attempt
0AllMO 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
2AllEmergency
3All except for the conditions in Access Category 1.MO signalling on NAS level resulting from other than paging
4All except for the conditions in Access Category 1.MMTEL voice (Note 3)
5All except for the conditions in Access Category 1.MMTEL video
6All except for the conditions in Access Category 1.SMS
7All except for the conditions in Access Category 1.MO data that do not belong to any other Access Categories (NOTE 4)
8All except for the conditions in Access Category 1MO signalling on RRC level resulting from other than paging
9All except for the conditions in Access Category 1MO IMS registration related signalling (Note 5)
10 (Note 6)AllMO exception data
11-31Reserved standardized Access Categories
32-63 (Note 2)AllBased 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 access of a NB-IoT-capable UEto a NB-IOT cell connected to 5GC when the UE is authorized to send exception data.
 
Access Category 0 in Table 6.22.2.3-1 shall not be barred, irrespective of Access Identities.
Up

6.23  QoS monitoring |R16|p. 41

6.23.1  Descriptionp. 41

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 cannot 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.
This clause provides requirements for both functionality and service exposure. In addition, the service exposure requirements on QoS monitoring in TS 22.101, clause 29.2 apply.
Up

6.23.2  Requirementsp. 42

The 5G system shall provide a mechanism for supporting real-time E2E QoS monitoring within a system.
The 5G system shall support combined QoS monitoring for a group of UEs.
The 5G network shall provide an interface to an 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.
The 5G system shall be able to log the history of the communication 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 an 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.
The 5G system shall support event-based QoS monitoring.
The 5G system shall be able to respond to a request from an authorized entity to provide real-time QoS monitoring information within a specified time after receiving the request (e.g., within 5 s).
The 5G system shall support an update/ refresh rate for real time QoS monitoring with a specified value (e.g., at least one update 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.
The 5G system shall provide a means by which an MNO informs a third party of network events (failure of network infrastructure affecting UEs in a particular area, etc.).
Based on MNO policy, the 5G system shall provide a mechanism to automatically report service degradations, communications loss, and sustained connection loss in a specific geographic area (e.g., a cell sector, a cell or a group of cells) to a third party.
The 5G system shall provide a mechanism for an authorised third party to report to an MNO service degradations, communication loss, and sustained connection loss.
Up

6.24  Ethernet transport services |R16|p. 43

6.24.1  Descriptionp. 43

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 TS 22.104.

6.24.2  Requirementsp. 43

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).
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|p. 44

6.25.1  Descriptionp. 44

Non-public networks are intended for the sole use of a private entity such as an enterprise, and can be deployed in a variety of configurations, utilising both virtual and physical elements. Specifically, they can be deployed as completely standalone networks, they can be hosted by a PLMN, or they can 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 can 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 can access both a non-public network and a PLMN where specifically allowed.
In addition to the requirements in this clause, all requirements and KPIs in other clauses of TS 22.261, that are not exclusively for PLMNs (i.e. explicitly using the term PLMN) also apply to (i.e. are in scope of) non-public networks, except the requirements in clauses 5.1, 6.2.4 and 6.3.2.2. However, hereby it is important to realize that requirements and features are optional to be supported by a non-public network, since non-public network deployments can include different subsets of 5G system requirements and services described in the clauses of TS 22.261. The deployment choices are dependent on verticals needs and regulation.
Up

6.25.2  Requirementsp. 44

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 an agreement between the operators and service providers, operator policies and the regional or national regulatory requirements, the 5G system shall enable a UE, with multiple subscriptions, to simultaneously access multiple non-public networks and corresponding services, via those NPNs or via a different network (PLMN or NPN).
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.
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 may broadcast a human readable network name that a UE may display for manual selection of a non-public network.
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.
The 5G system shall enable an NPN to support multiple third-party service providers.
In the event of a loss of communication between RAN and core network, the 5G system shall be able to provide capability to securely re-connect an NPN network function within a short period of time (< 1s).
Up

Up   Top   ToC