Content for  TS 22.261  Word version:  19.6.0

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

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 clause 29.2 of TS 22.101 apply.

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 real time QoS monitoring with a specified update/refresh rate. 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. Based on operator request, for direct network connection scenarios in non-public networks, the 5G system shall be able to activate/deactivate efficient QoS monitoring with a finer granularity (e.g. per data packet) in a specific QoS flow (e.g. supporting URLLC services) to report on data packets not meeting the required QoS level.

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.

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 IEEE 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, MSTP [54]).

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.

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

A group of interconnected SNPNs consists of one of more pairs of interconnected SNPNs. The determination of whether a given SNPN can or should be able to participate within a given group of interconnected SNPNs if based on prior arrangement and out of band configuration. How these arrangements and configuration are made is outside the scope of 3GPP and the 5G network. The following requirements apply for enabling groups of interconnected SNPNs Based on SNPN configuration and subject to SNPN operator's policy, the 5G network shall be able to support mechanisms to enable interconnect between two or more SNPNs. Based on SNPN configuration and subject to SNPN operator's policy, the 5G network shall be able to support prioritization of resources for a service offered by a SNPN that is consumed by users attached to other interconnected SNPNs. Based on SNPN configuration and subject to SNPN operator's policy, the 5G network shall be able to support service continuity for UEs that are moving between interconnected SNPNs.

The following requirements apply to support of Stand-alone Non-Public Network (SNPN) cellular hotspots: Based on the SNPN configuration, the 5G network shall support a mechanism for an SNPN to be able to interconnect with a large number of SNPN Credential Providers with which the SNPN might not have preconfigured information detailing the IP addresses used by these SNPN Credential Providers to interconnect with the SNPN. Based on the SNPN configuration, the 5G network shall support a mechanism for an SNPN Credential Provider to be able to interconnect with a large number of SNPNs with which the SNPN Credential Provider might not have preconfigured information detailing the IP addresses used by these SNPNs to interconnect with the SNPN Credential Provider. Based on the SNPN configuration, the 5G network shall support a mechanism for an SNPN to be able to determine how to connect to an SNPN Credential Provider capable of verifying the identity presented by a user attempting to connect to that SNPN. Based on the SNPN configuration, the 5G network shall support a mechanism for an SNPN to be able to securely interconnect with an SNPN Credential Provider in deployments where the required security information is not preconfigured. Based on the SNPN configuration, the 5G network shall support a mechanism for an SNPN to enable an SNPN Credential Provider to securely notify events (e.g., a user's subscription ending) to the SNPN.