5.30 Support for non-public networks

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.30.1 General

A Non-Public Network (NPN) is a 5GS deployed for non-public use, see TS 22.261 [2]. An NPN is either:

– a Stand-alone Non-Public Network (SNPN), i.e. operated by an NPN operator and not relying on network functions provided by a PLMN, or

– a Public Network Integrated NPN (PNI-NPN), i.e. a non-public network deployed with the support of a PLMN.

NOTE: An NPN and a PLMN can share NG-RAN as described in clause 5.18.

Stand-alone NPN are described in clause 5.30.2 and Public Network Integrated NPNs are described in clause 5.30.3.

5.30.2 Stand-alone non-public networks

5.30.2.0 General

SNPN 5GS deployments are based on:

– the architecture depicted in clause 4.2.3;

– the architecture for 5GC with Untrusted non-3GPP access (Figure 4.2.8.2.1-1) for either access to SNPN services via a PLMN (and vice versa) or for direct access to SNPN via non-3GPP access;

– – the architecture for 5GC with Trusted non-3GPP access (Figure 4.2.8.2.1-2); and

– the additional functionality covered in clause 5.30.2.

Alternatively, a Credentials Holder (CH) may authenticate and authorize access to an SNPN separate from the Credentials Holder based on the architecture specified in clause 5.30.2.9. Idle and connected mode mobility is supported as defined in clause 5.30.2.11.

Clauses 5.30.2.1 to 5.30.2.11 specify the common SNPN aspects applicable to both 3GPP and non-3GPP access, except where stated differently.

Aspects specific to Untrusted non-3GPP access for SNPN are specified in clause 5.30.2.12.

Aspects specific to Trusted non-3GPP access for SNPN are specified in clause 5.30.2.13.

The following 5GS features and functionalities are not supported for SNPNs:

– Interworking with EPS.

– Also, emergency services when the UE accesses the SNPN over NWu via a PLMN.

– Roaming, e.g. roaming between SNPNs. However, it is possible for a UE to access an SNPN with credentials from a CH as described in clause 5.30.2.9 and to move between equivalent SNPNs.

– Handover between SNPN and PLMN or PNI NPN.

– CIoT 5GS optimizations.

– CAG.

– Proximity based Services (ProSe) as defined in TS 23.304 [128].

– 5G NSWO.

A UE with two or more network subscriptions, where one or more network subscriptions may be for a subscribed SNPN, can apply procedures specified for Multi-USIM UEs as described in clause 5.38. The UE shall use a separate PEI for each network subscription when it registers to the network.

NOTE: The number of preconfigured PEIs for a UE is limited. If the number of network subscriptions for a UE is greater than the preconfigured number of PEIs, the number of network subscriptions that can be registered with the network simultaneously is restricted by the number of pre-configured number of PEIs.

5.30.2.1 Identifiers

The combination of a PLMN ID and Network identifier (NID) identifies an SNPN.

NOTE 1: The PLMN ID used for SNPNs is not required to be unique. PLMN IDs reserved for use by private networks can be used for non-public networks, e.g. based on mobile country code (MCC) 999 as assigned by ITU [78]). Alternatively, a PLMN operator can use its own PLMN IDs for SNPN(s) along with NID(s), but registration in a PLMN and mobility between a PLMN and an SNPN are not supported using an SNPN subscription given that the SNPNs are not relying on network functions provided by the PLMN.

The NID shall support two assignment models:

– Self-assignment: NIDs are chosen individually by SNPNs at deployment time (and may therefore not be unique) but use a different numbering space than the coordinated assignment NIDs as defined in TS 23.003 [19].

– Coordinated assignment: NIDs are assigned using one of the following two options:

1. The NID is assigned such that it is globally unique independent of the PLMN ID used; or

2. The NID is assigned such that the combination of the NID and the PLMN ID is globally unique.

NOTE 2: Which legal entities manage the number space is beyond the scope of this specification.

NOTE 3: The use of SNPN with self-assignment model NID such that the combination of PLMN ID and NID is not globally unique is not assumed for the architecture described in Figure 5.30.2.9.3-1, Figure 5.30.2.9.2-1 and for SNPN – SNPN Mobility as described in clause 5.30.2.11.

The GIN shall support two assignment models:

– Self-assignment: GINs are chosen individually and may therefore not be unique. It is defined as in TS 23.003 [19]

– Coordinated assignment: GIN uses a combination of PLMN ID and NID and is assigned using one of the following two options as defined in TS 23.003 [19].

1. The GIN is assigned such that the NID is globally unique (e.g. using IANA Private Enterprise Numbers) independent of the PLMN ID used; or

2. The GIN is assigned such that the combination of the NID and the PLMN ID is globally unique.

NOTE 4: Which legal entities manage the number space for GIN is beyond the scope of this specification.

An optional human-readable network name helps to identify an SNPN during manual SNPN selection. The human-readable network name and how it is used for SNPN manual selection is specified in TS 22.261 [2] and TS 23.122 [17].

5.30.2.2 Broadcast system information

NG-RAN nodes or Trusted non-3GPP access networks which provide access to SNPNs broadcast the following information:

– One or multiple PLMN IDs

– List of NIDs per PLMN ID identifying the non-public networks NG-RAN provides access to

NOTE 1: It is assumed that an NG-RAN node supports broadcasting a total of twelve NIDs. Further details are defined in TS 38.331 [28].

NOTE°2: The presence of a list of NIDs for a PLMN ID indicates that the related PLMN ID and NIDs identify SNPNs.

– Optionally:

– A human-readable network name per SNPN;

NOTE 3: The human-readable network name per SNPN is only used for manual SNPN selection. The mechanism how human-readable network name is provided (i.e. whether it is broadcasted or unicasted) to the UE is specified in TS 38.331 [28].

– Information, as described in TS 38.300 [27], TS 38.331 [28] and in TS 38.304 [50], to prevent UEs not supporting SNPNs from accessing the cell, e.g. if the cell only provides access to non-public networks;

– An indication per SNPN of whether access using credentials from a Credentials Holder is supported;

– List of supported Group IDs for Network Selection (GINs) per SNPN;

– An indication per SNPN of whether the SNPN allows registration attempts from UEs that are not explicitly configured to select the SNPN, i.e. UEs that do not have any PLMN ID and NID nor GIN broadcast by the SNPN in the Credentials Holder controlled prioritized lists of preferred SNPNs/GINs.

NOTE 4: Further details (including number of supported GINs per SNPN) are defined in TS 38.331 [28].

5.30.2.3 UE configuration and subscription aspects

An SNPN-enabled UE is configured with the following information for each subscribed SNPN:

– PLMN ID and NID of the subscribed SNPN;

– Subscription identifier (SUPI) and credentials for the subscribed SNPN;

– Optionally, an N3IWF FQDN and an identifier of the country where the configured N3IWF is located;

– Optionally, if the UE supports access to an SNPN using credentials from a Credentials Holder:

– User controlled prioritized list of preferred SNPNs;

– Credentials Holder controlled prioritized list of preferred SNPNs;

– Credentials Holder controlled prioritized list of GINs.

– Protection scheme for concealing the SUPI as defined in TS 33.501 [29];

NOTE: Additionally the UE can be configured with indication to use anonymous SUCI as defined in TS 24.501 [47].

For an SNPN-enabled UE with SNPN subscription, the Credentials Holder controlled prioritized lists of preferred SNPNs and GINs may be updated by the Credentials Holder using the Steering of Roaming (SoR) procedure as defined in Annex C of TS 23.122 [17]. Updating Credentials Holder controlled prioritized lists of preferred SNPNs and GINs via the Steering of Roaming (SoR) procedure is not applicable for Credentials Holder with AAA Server.

A subscription of an SNPN is either:

– identified by a SUPI containing a network-specific identifier that takes the form of a Network Access Identifier (NAI) using the NAI RFC 7542 [20] based user identification as defined in clause 28.7.2 of TS 23.003 [19]. The realm part of the NAI may include the NID of the SNPN; or

– identified by a SUPI containing an IMSI.

NOTE 1: As to route network signalling to AUSF and UDM instances serving the SNPN-enabled UE, the UE can be configured with Routing Indicator locally or updated with Routing Indicator using the UE Parameters Update via UDM Control Plane procedure defined in clause 4.20 of TS 23.502 [3]. When the SNPN credential is stored in the USIM, the Routing Indicator is provisioned in the USIM, when the SNPN credential is stored in the ME, the Routing Indicator is provisioned in the ME.

In the case of access to an SNPN using credentials owned by a Credentials Holder as specified in clause 5.30.2.9.2 and clause 5.30.2.9.3, the SUPI shall also contain identification for the Credentials Holder (i.e. the realm in the case of Network Specific Identifier based SUPI or the MCC and MNC in the case of an IMSI based SUPI). In the case of access to an SNPN using credentials owned by a Credentials Holder using AAA-S as specified in clause 5.30.2.9.2, only Network Specific Identifier based SUPI is supported.

NOTE 2: When Credentials Holder is an SNPN, and the MCC and MNC of the SNPN is not unique (e.g. MCC =999 is used and MNC is not coordinated amongst the SNPNs), then IMSI based SUPI is not supported as the MCC and MNC need not be globally unique always; instead USIM credentials are supported using Network Specific Identifier based SUPI.

NOTE 3: Network Specific Identifier are not supported for the case the Credentials Holder is provided by a PLMN.

NOTE 4: It is assumed that normally the SNPN and the Credentials Holder use different PLMN ID. If the SNPN and CHs (where CH can be another SNPN or a PLMN) share PLMN ID, and IMSI based SUPI is used, then the Routing Indicator can be used for AUSF/UDM discovery and selection as long as the Routing Indicator values are coordinated among the involved SNPN and CHs. When the PLMN ID is not shared between SNPNs and CHs (where CH can be another SNPN or a PLMN) and IMSI based SUPI is used, then PLMN ID is sufficient to be used for AUSF/UDM discovery & selection unless the CHs deploys multiple AUSF/UDM in which case also the Routing Indicator can be used as long as the Routing Indicator values are coordinated within the CH.

An SNPN-enabled UE that supports access to an SNPN using credentials from a Credentials Holder and that is equipped with a PLMN subscription may additionally be configured with the following information for SNPN selection and registration using the PLMN subscription in SNPN access mode:

– User controlled prioritized list of preferred SNPNs;

– Credentials Holder controlled prioritized list of preferred SNPNs;

– Credentials Holder controlled prioritized list of preferred GINs.

For an SNPN-enabled UE with PLMN subscription, the Credentials Holder controlled prioritized lists of preferred SNPNs and GINs may be updated by the Credentials Holder using the Steering of Roaming (SoR) procedure as defined in Annex C of TS 23.122 [17].

When the Credentials Holder updates a UE with the Credentials Holder controlled prioritized lists of preferred SNPNs and GINs the UE may perform SNPN selection again, e.g. to potentially select a higher prioritized SNPN.

5.30.2.4 Network selection in SNPN access mode

5.30.2.4.1 General

An SNPN-enabled UE supports the SNPN access mode. When the UE is set to operate in SNPN access mode the UE selects and registers with SNPNs over Uu as described in clause 5.30.2.4. Network selection in SNPN access mode for access to SNPN services via Untrusted non-3GPP access, Trusted non-3GPP access and Wireline access is specified in clause 5.30.2.12, clause 5.30.2.13 and clause 5.30.2.14 respectively. Access network selection in SNPN access mode for 5G NSWO is specified in clause 6.3.12b.

Emergency services are supported in SNPN access mode over Uu as defined in clause 5.16.4.1. Support for Emergency in SNPN access mode via Untrusted non-3GPP access is specified in clause 5.30.2.12.

If a UE is not set to operate in SNPN access mode, even if it is SNPN-enabled, the UE does not select and register with SNPNs. A UE not set to operate in SNPN access mode performs PLMN selection procedures as defined in clause 4.4 of TS 23.122 [17]. For a UE capable of simultaneously connecting to an SNPN and a PLMN, the setting for operation in SNPN access mode is applied only to the Uu interface for connection to the SNPN. Clause D.4 provides more details.

An SNPN-enabled UE that supports access to an SNPN using credentials from a Credentials Holder and that is equipped with a PLMN subscription needs to first enter SNPN access mode to be able to select SNPNs. Once the UE has entered SNPN access mode, SNPN selection is performed as described in clause 5.30.2.4. Once an SNPN has been selected the UE attempts registration in the SNPN using the PLMN credentials.

NOTE: Details of activation and deactivation of SNPN access mode are up to UE implementation.

When a UE is set to operate in SNPN access mode the UE does not perform normal PLMN selection procedures as defined in clause 4.4 of TS 23.122 [17].

UEs operating in SNPN access mode read the information described in clause 5.30.2.2 from the broadcast system information and take them into account during network selection.

5.30.2.4.2 Automatic network selection

NOTE 1: If the UE has multiple SNPN subscriptions it is assumed that the subscription to use for automatic selection is determined by implementation specific means prior to network selection.

For automatic network selection the UE selects and attempts registration on available and allowable SNPNs in the following order:

– the SNPN the UE was last registered with (if available) or the equivalent SNPN (if available);

– the subscribed SNPN, which is identified by the PLMN ID and NID for which the UE has SUPI and credentials.;

– If the UEs supports access to an SNPN using credentials from a Credentials Holder then the UE continues by selecting and attempting registration on available and allowable SNPNs which broadcast the indication that access using credentials from a Credentials Holder is supported in the following order:

– SNPNs in the user controlled prioritized list of preferred SNPNs (in priority order);

– SNPNs in the Credentials Holder controlled prioritized list of preferred SNPNs (in priority order);

– SNPNs, which additionally broadcast a GIN contained in the Credentials Holder controlled prioritized list of preferred GINs (in priority order);

NOTE 2: If multiple SNPNs are available that broadcast the same GIN, the order in which the UE selects and attempts a registration with those SNPNs is implementation specific.

– SNPNs, which additionally broadcast an indication that the SNPN allows registration attempts from UEs that are not explicitly configured to select the SNPN, i.e. the broadcasted NID or GIN is not present in the Credentials Holder controlled prioritized lists of preferred SNPNs/GINs in the UE.

NOTE 3: If multiple SNPNs are available that broadcast the indication that the SNPN allows registration attempts from UEs that are not explicitly configured to select the SNPN, the order in which the UE selects and attempts a registration with those SNPNs is implementation specific.

When a UE performs Registration or Service Request to an SNPN, the UE shall indicate the PLMN ID and NID as broadcast by the selected SNPN to NG-RAN. NG-RAN shall inform the AMF of the selected PLMN ID and NID.

5.30.2.4.3 Manual network selection

For manual network selection UEs operating in SNPN access mode provide to the user the list of SNPNs (each is identified by a PLMN ID and NID) and related human-readable names (if available) of the available SNPNs the UE has respective SUPI and credentials for. If the UEs supports access to an SNPN using credentials from a Credentials Holder, the UE also presents available SNPNs which broadcast the "access using credentials from a Credentials Holder is supported" indication and the human-readable names related to the SNPNs (if available).

NOTE: The details of manual SNPN selection are defined in TS 23.122 [17].

When a UE performs Initial Registration to an SNPN, the UE shall indicate the selected PLMN ID and NID as broadcast by the selected SNPN to NG-RAN. NG-RAN shall inform the AMF of the selected PLMN ID and NID.

5.30.2.5 Network access control

If a UE performs the registration or service request procedure in an SNPN identified by a PLMN ID and a self-assigned NID and there is no subscription for the UE, then the AMF shall reject the UE with an appropriate cause code to temporarily prevent the UE from automatically selecting and registering with the same SNPN.

If a UE performs the registration or service request procedure in an SNPN identified by a PLMN ID and a coordinated assigned NID and there is no subscription for the UE, then the AMF shall reject the UE with an appropriate cause code to permanently prevent the UE from automatically selecting and registering with the same SNPN.

NOTE: The details of rejection and cause codes is defined in TS 24.501 [47].

If a UE performs the registration in an SNPN using credentials from a Credentials Holder and UE is not authorized to access that specific SNPN, then the UDM can reject the UE which results in AMF rejecting the registration request from the UE with an appropriate cause code to prevent the UE from selecting and registering with the same SNPN using credentials from the Credentials Holder as described in TS 24.501 [47].

In order to prevent access to SNPNs for authorized UE(s) in the case of network congestion/overload, Unified Access Control information is configured per SNPN (i.e. as part of the subscription information that the UE has for a given SNPN) and provided to the UE as described in TS 24.501 [47].

5.30.2.6 Cell (re-)selection in SNPN access mode

UEs operating in SNPN access mode only select cells and networks broadcasting both PLMN ID and NID of the selected SNPN or its equivalent SNPN.

NOTE: Further details on the NR idle and inactive mode procedures for SNPN cell selection is defined in TS 38.331 [28] and in TS 38.304 [50].

5.30.2.7 Access to PLMN services via stand-alone non-public networks

To access PLMN services, a UE in SNPN access mode that has successfully registered with an SNPN may perform another registration via the SNPN User Plane with a PLMN (using the credentials of that PLMN) following the same architectural principles as specified in clause 4.2.8 (including the optional support for PDU Session continuity between PLMN and SNPN using the Handover of a PDU Session procedures in clauses 4.9.2.1 and 4.9.2.2 of TS 23.502 [3]) and the SNPN taking the role of "Untrusted non-3GPP access". Annex D, clause D.3 provides additional details.

NOTE: QoS differentiation in the SNPN can be provided on per-IPsec Child Security Association basis by using the UE or network requested PDU Session Modification procedure described in clause 4.3.3.2 of TS 23.502 [3]. In the PLMN, N3IWF determines the IPsec child SAs as defined in clause 4.12 of TS 23.502 [3]. The N3IWF is preconfigured by PLMN to allocate different IPsec child SAs for QoS Flows with different QoS profiles.

To support QoS differentiation in the SNPN with network-initiated QoS, the mapping rules between the SNPN and the PLMN are assumed to be governed by an SLA including: 1) mapping between the DSCP markings for the IPsec child SAs on NWu and the corresponding QoS, which is the QoS requirement of the PLMN and is expected to be provided by the SNPN, and 2) N3IWF IP address(es) in the PLMN. The non-alteration of the DSCP field on NWu is also assumed to be governed by an SLA and by transport-level arrangements that are outside of 3GPP scope. The packet detection filters in the SNPN can be based on the N3IWF IP address and the DSCP markings on NWu.

To support QoS differentiation in the SNPN with UE-requested QoS, the UE can request for an IPsec SA the same 5QI from the SNPN as the 5QI provided by the PLMN. It is assumed that UE-requested QoS is used only when the 5QIs used by the PLMN are from the range of standardized 5QIs. The packet filters in the requested QoS rule can be based on the N3IWF IP address and the SPI associated with the IPsec SA.

Refer to clause D.7 for details on how to support QoS differentiation.

When the UE accesses the PLMN over NWu via a SNPN, the AMF in the serving PLMN shall send an indication toward the UE during the Registration procedure to indicate whether an IMS voice over PS session is supported or not.

5.30.2.8 Access to stand-alone non-public network services via PLMN

To access SNPN services, a UE that has successfully registered with a PLMN over 3GPP access may perform another registration via the PLMN User Plane with an SNPN (using the credentials of that SNPN) following the same architectural principles as specified in clause 4.2.8 (including the optional support for PDU Session continuity between PLMN and SNPN using the Handover of a PDU Session procedures in clauses 4.9.2.1 and 4.9.2.2 of TS 23.502 [3]) and the PLMN taking the role of "Untrusted non-3GPP access" of the SNPN, i.e. using the procedures for Untrusted non-3GPP access in clause 4.12.2 of TS 23.502 [3]. Annex D, clause D.3 provides additional details. The case where UE that has successfully registered with a PLMN over non-3GPP access to access SNPN services is not specified in this Release.

NOTE: QoS differentiation in the PLMN can be provided on per-IPsec Child Security Association basis by using the UE or network requested PDU Session Modification procedure described in clause 4.3.3.2 of TS 23.502 [3]. In the SNPN, N3IWF determines the IPsec child SAs as defined in clause 4.12 of TS 23.502 [3]. The N3IWF is preconfigured by SNPN to allocate different IPsec child SAs for QoS Flows with different QoS profiles.

To support QoS differentiation in the PLMN with network-initiated QoS, the mapping rules between the PLMN and the SNPN are assumed to be governed by an SLA including: 1) mapping between the DSCP markings for the IPsec child SAs on NWu and the corresponding QoS, which is the QoS requirement of the SNPN and is expected to be provided by the PLMN, and 2) N3IWF IP address(es) in the SNPN. The non-alteration of the DSCP field on NWu is also assumed to be governed by an SLA and by transport-level arrangements that are outside of 3GPP scope. The packet detection filters in the PLMN can be based on the N3IWF IP address and the DSCP markings on NWu.

To support QoS differentiation in the PLMN with UE-requested QoS, the UE can request for an IPsec SA the same 5QI from the PLMN as the 5QI provided by the SNPN. It is assumed that UE-requested QoS is used only when the 5QIs used by the SNPN are from the range of standardized 5QIs. The packet filters in the requested QoS rule can be based on the N3IWF IP address and the SPI associated with the IPsec SA.

Refer to clause D.7 for details on how to support QoS differentiation.

When the UE accesses the SNPN over NWu via a PLMN, the AMF in the SNPN shall send an indication toward the UE during the Registration procedure to indicate whether an IMS voice over PS session is supported or not.

5.30.2.9 SNPN connectivity for UEs with credentials owned by Credentials Holder

5.30.2.9.1 General

SNPNs may support UE access using credentials owned by a Credentials Holder separate from the SNPN. In this case the Session Management procedures (i.e. PDU Sessions) terminate in an SMF in the SNPN.

When an SNPN supports UE access using credentials assigned by a Credentials Holder separate from the SNPN, it is assumed that is supported homogeneously within the whole SNPN.

Credentials Holder using AAA Server for primary authentication and authorization is described in clause 5.30.2.9.2 and Credentials Holder using AUSF and UDM for primary authentication and authorization is described in clause 5.30.2.9.3.

5.30.2.9.2 Credentials Holder using AAA Server for primary authentication and authorization

The AUSF and the UDM in SNPN may support primary authentication and authorization of UEs using credentials from a AAA Server in a Credentials Holder (CH).

– Only NSI based SUPI is supported and the SUPI is used to identify the UE during primary authentication and authorization towards the AAA Server. SUPI privacy is achieved according to methods in clause I.5 of TS 33.501 [29].

– The AMF discovers and selects the AUSF as described in clause 6.3.4 using the Home Network Identifier (realm part) and Routing Indicator present in the SUCI provided by a UE configured as described in clause 5.30.2.3.

– The AMF selects the UDM in the same SNPN, based on local configuration (e.g. using the realm part of the SUCI), or using the NRF procedure defined in clause 4.17.4a of TS 23.502 [3].

– If the UDM decides that the primary authentication is performed by AAA Server in CH based on the UE’s SUPI and subscription data. The Home Network Identifier, is derived by UDM from the SUCI received from AUSF. If the SUCI was generated using a privacy protection scheme that requires de-concealment, UDM de-conceal the SUCI as defined in TS 33.501 [29]. The UDM then instructs the AUSF that primary authentication by a AAA Server in a CH is required, the AUSF shall discover and select the NSSAAF, and then forward EAP messages to the NSSAAF. The NSSAAF selects AAA Server based on the domain name corresponds to the realm part of the SUPI, relays EAP messages between AUSF and AAA Server (or AAA proxy) and performs related protocol conversion. The AAA Server acts as the EAP Server for the purpose of primary authentication.

NOTE 1: The UDM in SNPN, based on SLA between Credentials Holder and SNPN, is pre-configured with information indicating whether the UE needs primary authentication from AAA Server.

NOTE 2: It is assumed that the SNPN is configured on per Home Network Identifier basis to determine whether to perform primary authentication with AUSF/UDM or AAA server.

– The AMF and SMF shall retrieve the UE subscription data from UDM using SUPI.

Figure 5.30.2.9.2-1 depicts the 5G System architecture for SNPN with Credentials Holder using AAA Server for primary authentication and authorization.

NOTE 3: The SNPN in Figure 5.30.2.9.2-1 can be the subscribed SNPN for the UE (i.e. NG-RAN broadcasts SNPN ID of the subscribed SNPN). As a deployment option, the SNPN in Figure 5.30.2.9.2-1 can also be another SNPN than the subscribed SNPN for the UE (i.e. none of the SNPN IDs broadcast by NG-RAN matches the SNPN ID corresponding to the subscribed SNPN). In both cases, the AUSF, UDM and NSSAAF are configured to support the HNI of the UE’s SUPI/SUCI, SUPI privacy settings (when using privacy protection scheme other than the ‘null-scheme’ to generate the SUCI as defined in TS 33.501 [29]), subscription data of the UE and authentication settings to allow UE authentication with AAA-S in CH.

Figure 5.30.2.9.2-1: 5G System architecture with access to SNPN using credentials from Credentials Holder using AAA Server

NOTE 4: The NSSAAF deployed in the SNPN can support primary authentication in the SNPN using credentials from Credentials Holder using a AAA Server (as depicted) and/or the NSSAAF can support Network Slice-Specific Authentication and Authorization with a Network Slice-Specific AAA Server (not depicted).

5.30.2.9.3 Credentials Holder using AUSF and UDM for primary authentication and authorization

An SNPN may support primary authentication and authorization of UEs that use credentials from a Credentials Holder using AUSF and UDM. The Credentials Holder may be an SNPN or a PLMN. The Credentials Holder UDM provides to SNPN the subscription data.

NOTE 1: A list of functionalities not supported in SNPN is provided in clause 5.30.2.0.

Optionally, an SNPN may support network slicing (including Network Slice-Specific Authentication and Authorization, Network Slice Access Control and subscription-based restrictions to simultaneous registration of network slices) for UEs that use credentials from a Credentials Holder using AUSF and UDM. The SNPN retrieves NSSAA and NSSRG information from the UDM of the Credentials Holder.

Figure 5.30.2.9.3-1 depicts the 5G System architecture for SNPN with Credentials Holder using AUSF and UDM for primary authentication and authorization and network slicing.

NOTE 2: The architecture for SNPN and Credentials Holder using AUSF and UDM is depicted as a non-roaming reference architecture as the UE is not considered to be roaming, even though some of the roaming architecture reference points are also used, e.g. for AMF and SMF in SNPN to register with and retrieve subscription data from UDM of the Credentials Holder.

Figure 5.30.2.9.3-1: 5G System architecture with access to SNPN using credentials from Credentials Holder using AUSF and UDM

5.30.2.10 Onboarding of UEs for SNPNs

5.30.2.10.1 General

Onboarding of UEs for SNPNs allows the UE to access an Onboarding Network (ONN) for the purpose of provisioning the UE with SNPN credentials for primary authentication and other information to enable access to a desired SNPN, i.e. (re-)select and (re-)register with SNPN.

To provision SNPN credentials in a UE that is configured with Default UE credentials (see clause 5.30.2.10.2.4), the UE selects an SNPN as ONN and establishes a secure connection with that SNPN referred to as Onboarding SNPN (ON-SNPN), see more details in clause 5.30.2.10.2.

NOTE: If the UE is already provisioned with a set of SNPN credentials or credentials owned by a Credentials Holder and needs to be provisioned with an additional set of SNPN credentials, the UE can access an SNPN using the network selection in SNPN access mode as described in clause 5.30.2.4, normal registration (i.e. not registration for onboarding) and normal PDU Session (i.e. not a restricted PDU Session used for onboarding) and then leverage the SNPN’s User Plane connection to get access to a PVS. The PVS address can be provided in the same way as when the Onboarding Network is a PLMN.

To provision SNPN credentials in a UE that is equipped with a USIM configured with PLMN credentials, the UE selects a PLMN as ONN and establishes a secure connection with that PLMN, see more details in clause 5.30.2.10.3.

After the secure connection is established, the UE is provisioned with SNPN credentials and possibly other data to enable discovery, (re-)selection and (re-)registration for a desired SNPN, see more details in clause 5.30.2.10.4.

ON-SNPN and SO-SNPN can be roles taken by either an SNPN or different SNPNs. It is possible for the same network to be in both roles with respect to a specific UE.

5.30.2.10.2 Onboarding Network is an SNPN

5.30.2.10.2.1 General

A UE configured with Default UE credentials may register with an ON-SNPN for the provisioning of SO-SNPN credentials.

5.30.2.10.2.2 Architecture

Figures 5.30.2.10.2.2-1, 5.30.2.10.2.2-2 and 5.30.2.10.2.2-3 depict the architecture for Onboarding of UEs in an ON-SNPN.

Figure 5.30.2.10.2.2-1: Architecture for UE Onboarding in ON-SNPN when the DCS includes an AUSF and a UDM

Figure 5.30.2.10.2.2-2: Architecture for UE Onboarding in ON-SNPN when the DCS includes a AAA Server used for primary authentication

Figure 5.30.2.10.2.2-3: Architecture for UE Onboarding in ON-SNPN when the DCS is not involved during primary authentication

NOTE 1: AUSF in the ON-SNPN interfaces with the DCS via NSSAAF as shown in Figure 5.30.2.10.2.2-2 owned by an entity that is internal or external to the ON-SNPN.

NOTE 2: The functionality with respect to exchange information between PVS and SO-SNPN to provision SNPN credentials and other data from the SO-SNPN in the UE is out of 3GPP scope.

NOTE 3: The dotted lines in Figure 5.30.2.10.2.2-1, Figure 5.30.2.10.2.2-2 and Figure 5.30.2.10.2.2-3 indicate that whether domains (e.g. DCS domain, PVS domain, and SO-SNPN) are separated depends on the deployment scenario.

NOTE 4: See TS 33.501 [29] for the functionality beyond AUSF, and other interfaces required for security.

NOTE 5: When secondary authentication is used in the context of the UE onboarding architecture in Figure 5.30.2.10.2.2-3, the same S-NSSAI/DNN or different S-NSSAI/DNNs can be used for the onboarding PDU Sessions of different UEs even though the DN-AAA servers that authenticate the UEs can reside in different administrative domains.

When the DCS is involved during mutual primary authentication during the Onboarding procedure (as in Figure 5.30.10.2.2-1 and Figure 5.30.10.2.2-2), the following applies:

– When the DCS includes an AUSF and a UDM functionality, then the AMF selects AUSF in the DCS domain. The ON-SNPN and DCS domain are connected via N32 and SEPP which are not shown in the Figure 5.30.2.10.2.2-1.

– When the DCS includes a AAA Server functionality, only NSI based SUPI is supported and the AMF selects AUSF in the ON-SNPN. Based on local configuration (e.g. using the realm part of the Onboarding SUCI), the AUSF skips the UDM selection and directly performs primary authentication towards DCS with AAA Server functionality using Default UE credentials for primary authentication. The AUSF uses an NSSAAF (and the NSSAAF may use a AAA-P which is not shown in the figure 5.30.2.10.2.2-2) to relay EAP messages towards the DCS including a AAA Server. The NSSAAF selects AAA Server based on the domain name corresponding to the realm part of the SUPI.

NOTE 5: The AMF in ON-SNPN uses the Home Network Identifier of the Onboarding SUCI to select the DCS. It is assumed that the ON-SNPN is configured on per Home Network Identifier basis to determine whether to perform primary authentication with AUSF/UDM or AAA server.

When the DCS is not involved during primary authentication (as in Figure 5.30.10.2.2-3), the following applies:

– The AMF selects a local AUSF as described in clause 5.30.2.10.2.6 and performs primary authentication towards the local AUSF using Default UE credentials for primary authentication as described in TS 33.501 [29].

– Upon establishment of the PDU Session used for User Plane Remote Provisioning the ON-SNPN may trigger secondary authentication procedure, as described in clause 4.3.2.3 of TS 23.502 [3], with the DCS or with a DN-AAA server using Default UE credentials for secondary authentication, as described in clause I.9.2.4 of TS 33.501 [29]. When secondary authentication is used, the SMF identifies the DCS or the DN-AAA server as defined in clause 4.3.2.3 of TS 23.502 [3].

NOTE 6: If the secondary authentication fails, the SMF rejects the PDU Session used for User Plane Remote Provisioning. Based on local policy the AMF can deregister the UE as described in clause 5.30.2.10.2.7.

NOTE 7: The DCS and PVS can be owned by an administrative entity that can be different from either the ON-SNPN or SO-SNPN. The ownership of DCS and PVS is outside the scope of 3GPP.

5.30.2.10.2.3 Broadcast system information

When the SNPN supports Onboarding of UEs for SNPNs (i.e. the SNPN can be used as ON-SNPN), the NG-RAN node or the Trusted non-3GPP access network providing access to SNPN additionally broadcasts the following information:

– An onboarding enabled indication that indicates whether onboarding is currently enabled for the SNPN. For access to SNPN via NG-RAN the onboarding enabled indication is broadcasted per cell e.g. to allow start of the onboarding procedure only in parts of the SNPN.

NOTE: Onboarding enabled indication per cell does not affect mobility management functions, i.e. once the UE selects the ON-SNPN as described in clause 5.30.2.10.2.5 and successfully registers within ON-SNPN as described in clause 5.30.2.10.2.6, the UE can move to a cell of the ON-SNPN not indicating onboarding support and continue with the remote provisioning as described in clause 5.30.2.10.4.

5.30.2.10.2.4 UE Configuration Aspects

A UE enabled to support UE Onboarding, shall be pre-configured with Default UE credentials, and the UE may be pre-configured with ON-SNPN selection information. The Default UE credentials consist of credentials for primary authentication and optionally credentials for secondary authentication, as described in clause I.9 of TS 33.501 [29].

NOTE 1: The content of the ON-SNPN network selection information depends on UE implementation and can include SNPN network identifiers and/or GIN(s).

The UE uses the ON-SNPN selection information for selection of ON-SNPN (see clause 5.30.2.10.2.5).

The UE Configuration Data for UP Remote Provisioning is described in the clause 5.30.2.10.4.2.

NOTE 2: It is assumed that the UE is not pre-configured with a S-NSSAI and DNN for the purpose of UE onboarding in the ON-SNPN.

NOTE 3: The Default UE credentials for primary authentication are used to derive a SUPI. When the UE derives the SUPI from the Default UE credentials for primary authentication, the UE performs specific onboarding procedure as described in clauses 5.30.2.10.2.5, 5.30.2.10.2.6 and 5.30.2.10.2.7.

5.30.2.10.2.5 Network selection

This clause applies only when the UE is in SNPN access mode.

When the UE wants to perform UE onboarding via an SNPN, the UE shall perform ON-SNPN selection as described below. An ON-SNPN is an SNPN providing onboarding access and enabling remote provisioning for a UE registered for onboarding as specified in clause 4.2.2.2.4 of TS 23.502 [3].

NOTE: The trigger for the UE to initiate the UE Onboarding procedure is UE implementation dependent (e.g. the trigger can be a power-on event in the UE, or an input by the user).

For automatic or manual selection, the UE may select and attempt to register to an ON-SNPN which broadcast the Onboarding enabled indication described in clause 5.30.2.10.2.3 and matches the pre-configured ON-SNPN selection information such as SNPN network identifier and/or GIN(s) (if available) described in clause 5.30.2.10.2.4 according to the UE implementation-specific logic. If the registration fails, the UE may select and attempt to register to a different ON-SNPN as defined in clause 4.9.3.1.3 or clause 4.9.3.1.4 of TS 23.122 [17].

5.30.2.10.2.6 Registration for UE onboarding

When the user or UE has selected an ON-SNPN according to clause 5.30.2.10.2.5, the UE establishes an RRC connection towards the NG-RAN node of the ON-SNPN. The UE provides an indication in RRC Connection Establishment that the RRC connection is for onboarding as defined in TS 38.331 [28]. This indication allows the NG-RAN node to select an appropriate AMF that supports the UE onboarding procedures. The UE indicates the ON-SNPN as the selected network, and the NG-RAN node shall indicate the selected PLMN ID and NID of the ON-SNPN to the AMF.

NOTE 1: As the configuration information in the UE does not include any S-NSSAI and DNN used for onboarding, the UE does not include S-NSSAI and DNN in RRC when it registers for UE onboarding purposes to the ONN.

The UE shall initiate the NAS registration procedure by sending a NAS Registration Request message with the following characteristics:

– The UE shall set the 5GS Registration Type to the value "SNPN Onboarding" indicating that the registration request is for onboarding.

– The UE shall provide a SUCI derived from a SUPI as specified in TS 23.003 [19] and TS 33.501 [29]. The SUPI shall uniquely identify the UE and shall be derived from the Default UE credentials for primary authentication. The SUPI used for onboarding may contain an IMSI or a network-specific identifier. The ON-SNPN may determine the corresponding DCS identity or address/domain, based on the SUCI (i.e. based on the Home Network Identifier of the SUCI).

The UE does not include a Requested NSSAI in NAS signalling when it registers for UE onboarding purposes to the ON-SNPN.

The AMF supporting UE onboarding is configured with AMF Onboarding Configuration Data that includes e.g.:

– S-NSSAI and DNN to be used for onboarding or a configured SMF for the S-NSSAI and DNN used for onboarding.

– Information to use a local AUSF(s) within the ON-SNPN for onboarding of UEs with a SUCI for a DCS with AAA Server or for onboarding of UEs in the case where the DCS is not involved during primary authentication.

NOTE 2: The S-NSSAI used for onboarding is assumed to be configured in both the AMF (i.e. in the AMF Onboarding Configuration Data) and the NG-RAN nodes for the corresponding Tracking Areas where onboarding is enabled.

When the AMF receives a NAS Registration Request with a 5GS Registration Type set to "SNPN Onboarding", the AMF:

– starts an authentication procedure towards the AUSF, the authentication procedure is specified in TS 33.501 [29]. The AMF may be provided with PVS IP address(es) or PVS FQDN(s) from the DCS during authentication procedure. The AMF selects an appropriate AUSF as described in clause 6.3.4 based on the Home Network Identifier of the SUCI used during onboarding or based on local configuration in the AMF.

– applies the AMF Onboarding Configuration Data e.g. used to restrict UE network usage to only onboarding for User Plane Remote Provisioning of UE as described in clause 5.30.2.10.4.3.

– stores in the UE context in AMF an indication that the UE is registered for SNPN onboarding.

Upon successful authentication from AUSF, the AMF informs the UE about the result of the registration. If the UE is not successfully authenticated, the AMF shall reject the registration procedure for onboarding, and the UE may select a different ON-SNPN to attempt to register.

NOTE 3: The AMF does not interact with the UDM of the ON-SNPN or DCS (i.e. for registration or subscription management purposes) when it receives a NAS Registration Request with a 5GS Registration Type set to "SNPN Onboarding" (see clause 4.2.2.2.4 of TS 23.502 [3]).

5.30.2.10.2.7 Deregistration from the ON-SNPN for onboarding registered UE

Once remote provisioning of SO-SNPN credentials is completed, the UE should initiate deregistration from the ON-SNPN.

Based on ON-SNPN policies, the AMF may start an implementation specific timer once the UE has registered to the ON-SNPN for the purpose of onboarding. Expiry of this timer triggers the AMF to deregister the onboarding registered UE from the ON-SNPN.

The AMF may also deregister the UE when it determines that the PDU Session used for User Plane Remote Provisioning has been released by the SMF.

When AMF re-allocation occurs for a UE registered for SNPN onboarding during mobility registration update procedure as described in TS 23.502 [3] in clause 4.2.2.2.4 or during N2 based handover as described in TS 23.502 [3] clause 4.9.1.3, the new AMF supporting SNPN Onboarding should be selected as described in clause 6.3.5. If the new AMF receives in UE context the indication that the UE is registered for SNPN onboarding, the new AMF may start an implementation specific timer for when to deregister the UE when the new AMF completes the Registration procedure (i.e. sends Registration Accept to the UE) or completes the N2 based handover procedure.

NOTE: This specific timer is used to prevent onboarding registered UEs from staying at the ON-SNPN indefinitely.

5.30.2.10.3 Onboarding Network is a PLMN

5.30.2.10.3.1 General

A UE configured with PLMN credentials in USIM for primary authentication may register with a PLMN for the provisioning of SO-SNPN credentials.

5.30.2.10.3.2 Network selection and Registration

This clause applies only when the UE is not in SNPN access mode.

When the UE is using PLMN credentials for accessing a PLMN as the Onboarding Network (ONN), then regular network selection, as per TS 23.122 [17] and regular initial registration procedures apply, as per TS 23.502 [3]. After successfully registering to the ON-PLMN, the UE is provisioned with the SO-SNPN credentials via User Plane as in clause 5.30.2.10.4.4.

NOTE: When Onboarding network is a PLMN and the UE’s subscription only allows for Remote Provisioning, then based on PLMN policies, the AMF can start an implementation specific timer once the UE has registered to the PLMN. Expiry of this timer triggers the AMF to deregister the UE from the PLMN. This specific timer is used to prevent registered UEs that are only allowed for Remote Provisioning from staying at the PLMN indefinitely.

5.30.2.10.4 Remote Provisioning of UEs in Onboarding Network

5.30.2.10.4.1 General

Remote Provisioning of UEs that registered with an Onboarding Network enables provisioning the UE with SNPN credentials for primary authentication and other information to enable access to the desired SNPN.

Onboarding Services are provided using a PDU Session for DNN and S-NSSAI used for onboarding allowing remote provisioning of UEs via User Plane. The PDU Session may be restricted only to be used for Remote Provisioning of the UE.

5.30.2.10.4.2 Onboarding configuration for the UE

In order to enable UP Remote Provisioning of SNPN credentials for a UE, UE Configuration Data for User Plane Remote Provisioning are either pre-configured on the UE or provided by the ONN. UE Configuration Data for User Plane Remote Provisioning provided by the ONN take precedence over corresponding configuration data stored in the UE.

UE Configuration Data for User Plane Remote Provisioning consist of PVS IP address(es) and/or PVS FQDN(s).

If the UE does not have any PVS IP address or PVS FQDN after the establishment of the PDU Session used for User Plane Remote Provisioning, the UE may construct an FQDN for PVS discovery as defined in TS 23.003 [19].

The UE Configuration Data for User Plane Remote Provisioning may be stored in the ME.

The UE Configuration Data for User Plane Remote Provisioning (i.e. PVS IP address(es) or PVS FQDN(s), or both) may be either:

– locally configured in the SMF of ONN; or

– provided by the DCS to the AMF of ON-SNPN as part of the authentication procedure as specified in TS 33.501 [29] and sent by the AMF in the Nsmf_PDUSession_CreateSMContext Request message to the SMF

The PVS IP address(es) and/or PVS FQDN(s) provided by the DCS take precedence over the locally configured PVS IP address(es) and/or PVS FQDN(s) in the ON-SNPN.

If the PCF is used for User Plane Remote Provisioning, the SMF provides the UE Configuration Data to the PCF as described in clause 5.30.2.10.4.3.

The UE Configuration Data for User Plane Remote Provisioning may be provided to the UE during the establishment of the PDU Session used for User Plane Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response.

NOTE 1: If there are multiple PVS IP addresses and/or PVS FQDNs in the UE, how the UE uses this information is up to UE implementation.

NOTE 2: The maximum number of PVS IP address(es) and/or PVS FQDN(s) allowed to be provided to the UE via Protocol Configuration Options (PCO) is specified in TS 24.501 [47].

5.30.2.10.4.3 User Plane Remote Provisioning of UEs when Onboarding Network is an ON-SNPN

The AMF selects an SMF used for User Plane Remote Provisioning using the SMF discovery and selection functionality as described in clause 6.3.2. The S-NSSAI and DNN of the AMF Onboarding Configuration Data may be used to discover and select an SMF for User Plane Remote Provisioning. Alternatively, for SMF selection, the AMF Onboarding Configuration Data may contain a configured SMF for the S-NSSAI and DNN used for onboarding. The AMF provides Onboarding Indication to SMF via Nsmf_PDUSession_CreateSMContext request message when a PDU Session used for User Plane Remote Provisioning is established. During PDU Session establishment for remote provisioning, the AMF may provide the PVS IP address(es) and/or PVS FQDN(s) to the SMF.

When a UPF is selected for User Plane Remote Provisioning, the UPF selection function described in clause 6.3.3 for normal services is applied considering the S-NSSAI and DNN used for onboarding.

The SMF or the PCF may store S-NSSAI and DNN information used for onboarding. Onboarding Configuration Data available to PCF (for details see TS 23.503 [45]) and/or SMF may include PVS FQDN(s) and/or PVS IP address(es). The SMF and the PCF may use Onboarding Indication and DNN and S-NSSAI used for onboarding to access the Onboarding Configuration Data.

NOTE: The SMF is aware about the PVS IP address(es) and/or PVS FQDN(s) in one of the following ways: either received from the AMF or retrieved locally from the Onboarding Configuration Data.

When the UE registered for Onboarding (i.e. 5GS Registration Type is set to the value "SNPN Onboarding") successfully completes the User Plane Remote Provisioning of SNPN credentials via the Onboarding Network, then the UE should deregister from the Onboarding Network.

Initial QoS parameters used for User Plane Remote Provisioning are configured in the SMF when dynamic PCC is not used.

Dynamic PCC may be used for a PDU Session used for User Plane Remote Provisioning as described in TS 23.503 [45]. If a PCF is used and the AMF provided an Onboarding Indication, the SMF provides Onboarding Indication to the PCF when requesting an SM Policy Association. The SMF may provide the UE Configuration Data (i.e. PVS IP address(es) and/or PVS FQDN(s)) to the PCF when requesting an SM Policy Association.

The QoS Flows of a restricted PDU Session, which is associated with the S-NSSAI/DNN used for Onboarding, shall be dedicated to Onboarding Services. The SMF may configure in the UPF PDR(s) and FAR(s) including PVS and DNS server IP addresses to block any traffic that is not from or to PVS and DNS server addresses.

If the UE is registered for Onboarding (i.e. 5GS Registration Type is set to the value "SNPN Onboarding"), the network should apply S-NSSAI and DNN in the Onboarding Configuration Data for the PDU Session Establishment request from the UE.

5.30.2.10.4.4 User Plane Remote Provisioning of UEs when Onboarding Network is a PLMN

Subscription data of such a UE shall contain the DNN and S-NSSAI used for onboarding.

The AMF selects an SMF used for User Plane Remote Provisioning using the SMF discovery and selection functionality as described in clause 6.3.2, considering the DNN and S-NSSAI used for onboarding provided by the UE or the default DNN and S-NSSAI provided by UDM.

The UPF selection function described in clause 6.3.3 is applied, considering the DNN and S-NSSAI used for onboarding.

The SMF may be configured with one or more PVS FQDN(s) and/or PVS IP address(es) per DNN and S-NSSAI used for onboarding. When the UE requests a PDU Session used for User Plane Remote Provisioning by using DNN and S-NSSAI used for onboarding, the SMF sends the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session to the UE as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response if the following conditions are met:

– the UE subscription data contains the DNN and S-NSSAI used for onboarding; and

– the SMF has obtained the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session from local configuration; and

– the UE has requested PVS information via PCO in PDU Session Establishment Request.

NOTE 1: Local PCC or dynamic PCC can be used as described for PLMNs in TS 23.503 [45] and based on operator policy, PDR(s) and FAR(s) can be configured to restrict traffic other than provisioning traffic between PVS/DNS server(s) and UE(s).

NOTE 2: If the UE receives multiple PVS IP addresses and/or PVS FQDNs, how the UE uses this information is up to UE implementation.

NOTE 3: The maximum number of PVS IP address(es) and/or PVS FQDN(s) allowed to be provided to the UE via Protocol Configuration Options (PCO) is specified in TS 24.501 [47].

5.30.2.11 UE Mobility support for SNPN

If the UE moves its 3GPP access between SNPN and PLMN, the network selection is performed as specified in TS 23.122 [17] and UE performs initial registration as specified in clause 4.2.2.2.2 of TS 23.502 [3].

NOTE 1: When the UE moves its 3GPP access between SNPN and PLMN, it is up to UE implementation to activate/deactivate SNPN access mode.

If the UE moves its 3GPP access between SNPNs, the network selection is performed as specified in TS 23.122 [17], then the UE performs initial or mobility registration as specified in clause 4.2.2.2.2 of TS 23.502 [3].

NOTE 2: When the UE moves its 3GPP access between SNPNs, it is up to UE implementation whether and when to establish again PDU Sessions using existing mechanism.

If the UE and network supports equivalent SNPNs, the AMF may provide list of equivalent SNPNs to the UE and NG-RAN. The UE may move its 3GPP access to the SNPN in the list of equivalent SNPNs without performing network selection. A UE supporting equivalent SNPNs gets a new registered SNPN ID during the Registration procedure if serving SNPN is changed.

5.30.2.12 Access to SNPN services via Untrusted non-3GPP access

Access to SNPN services via Untrusted non-3GPP access network follows the specification in the previous 5.30.2 clauses with the differences as specified in this clause.

N3IWF selection is supported as follows:

– When UE registers to SNPN with credentials owned by the SNPN, UE uses the same N3IWF selection procedure as specified for access to stand-alone non-public network services via PLMN in clause 6.3.6.2a.

Emergency services are supported as follows:

– UE initiates N3IWF selection for emergency services when the UE detects a user request for emergency session and determines that Untrusted non-3GPP access is to be used for the emergency access. The UE with SNPN subscription performs the following:

– If the UE determines that it is located in the same country as the subscribed SNPN, the UE uses the configured N3IWF FQDN for N3IWF selection.

– Otherwise, the UE follows the N3IWF selection procedure for Emergency services for UE not equipped with valid SNPN credentials, in the same way as defined in clause 6.3.6.4.2 for a UE not equipped with a UICC.

UE onboarding is supported as follows:

– When UE registers to SNPN over Untrusted non-3GPP access for UE Onboarding, UE may select an N3IWF in the SNPN which supports UE Onboarding by using a pre-configured N3IWF FQDN used for Onboarding.

– If the PVS is reachable from the local Untrusted non-3GPP access network (e.g. via the Internet) using the local IP connectivity, UE may connect directly (i.e. without being connected to an N3WIF) with a PVS to obtain the SNPN credentials.

5.30.2.13 Access to SNPN services via Trusted non-3GPP access

Access to SNPN services via Trusted non-3GPP access network follows the specification in the previous (sub)clauses of clause 5.30.2 with the differences as specified in this clause.

To access SNPN services via a Trusted non-3GPP access network, the UE follows the procedure for accessing a PLMN via a Trusted non-3GPP access network defined in clause 6.3.12.2 with the following clarifications and additions:

– A non-3GPP access network may advertise (e.g. with ANQP), not only the PLMNs with which 5G connectivity is supported (as specified in clause 6.3.12.2), but also the SNPNs with which 5G connectivity is supported and the related parameters and indications defined in clause 5.30.2.2 (i.e. human-readable network name(s), GIN(s), indication whether access using credentials from a Credentials Holder is supported, indication whether SNPN allows registration attempts from UEs that are not explicitly configured to select the SNPN, etc.).- The UE initiates the access network selection procedure specified in clause 6.3.12.2 and constructs a list of available SNPNs. This list contains the SNPNs advertised by all discovered non-3GPP access networks.

– The UE selects an SNPN that is included in the list of available SNPNs following the procedure in clause 5.30.2.4.

– The UE selects a non-3GPP access network that supports 5G connectivity to the selected SNPN and initiates the registration procedure via Trusted non-3GPP access specified in clause 4.12a.2.2 of TS 23.502 [3] in order to register with the selected SNPN via the selected non-3GPP access network. During the EAP authentication procedure the NAI provided by the UE indicates that 5G connectivity to a specific SNPN is required (e.g. NAI = "<username>@nai.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org").

NOTE: In the case of SNPN ID with self-assigned NID, if the UE, when trying to register with an SNPN ID via TNAN X, is rejected by the AMF with a cause code that temporarily prevents the UE from registering with this SNPN ID, the UE does temporarily not attempt to register with the same SNPN ID, even if the same SNPN ID is advertised via another TNAN.

– If there are multiple non-3GPP access networks that support 5G connectivity to the selected SNPN, then the UE places these non-3GPP access networks in a prioritized list and selects the highest priority non-3GPP access network from this list. To determine the priority of a non-3GPP access network, the UE shall apply the WLANSP rules (if provided), and the procedure specified in clause 6.6.1.3 of TS 23.503 [45], "UE procedure for selecting a WLAN access based on WLANSP rules". If the UE is not provided with WLANSP rules, the UE determines the priority of a non-3GPP access network by using implementation means.

UE onboarding via Trusted non-3GPP access is supported as follows:

– The non-3GPP access network advertises (e.g. via ANQP) an Onboarding enabled indication, as specified in clause 5.30.2.10.2.3.

– The UE selects an SNPN advertising the Onboarding enabled indication following the network selection procedure specified in clause 5.30.2.10.2.5.

– As part of UE registration via Trusted non-3GPP access, in Figure 4.12a.2.2-1, step 5 of TS 23.502 [3] the UE provides an onboarding indication inside the AN-Parameters.

5.30.2.14 Access to SNPN services via wireline access network

Access to SNPN services via a wireline access network follows the same procedures used for accessing a PLMN via a wireline access network as defined in clause 4.2.1 of TS 23.316 [84]. The SNPN is implicitly selected by wired physical connectivity between 5G-RG or FN-RG and W-AGF. The Global Cable Identifier (GCI) used by W-AGF for providing access to SNPN services is specified in TS 23.003 [19].

5.30.3 Public Network Integrated NPN

5.30.3.1 General

Public Network Integrated NPNs are NPNs made available via PLMNs e.g. by means of dedicated DNNs, or by one (or more) Network Slice instances allocated for the NPN. The existing network slicing functionalities apply as described in clause 5.15. When a PNI-NPN is made available via a PLMN, then the UE shall have a subscription for the PLMN in order to access PNI-NPN.

NOTE 1: Annex D provides additional consideration to consider when supporting Non-Public Network as a Network Slice of a PLMN.

As network slicing does not enable the possibility to prevent UEs from trying to access the network in areas where the UE is not allowed to use the Network Slice allocated for the NPN, Closed Access Groups may optionally be used to apply access control.

A Closed Access Group identifies a group of subscribers who are permitted to access one or more CAG cells associated to the CAG.

CAG is used for the PNI-NPNs to prevent UE(s), which are not allowed to access the NPN via the associated cell(s), from automatically selecting and accessing the associated CAG cell(s).

NOTE 2: CAG is used for access control e.g. authorization at cell selection and configured in the subscription as part of the Mobility Restrictions i.e. independent from any S-NSSAI. CAG is not used as input to AMF selection nor Network Slice selection. If NPN isolation is desired, operator can better support NPN isolation by deploying network slicing for PNI-NPN, configuring dedicated S-NSSAI(s) for the given NPN as specified in Annex D, clause D.2 and restricting NPN’s UE subscriptions to these dedicated S-NSSAI(s).

The UE and PNI-NPN may support remote provisioning of credentials for NSSAA or credentials for secondary authentication/authorization to the UE, as specified in clause 5.39.

NOTE 3: After successful provisioning of the credentials to the UE, specific service subscription data (e.g. to enable the use of PNI-NPN) can be activated in the UE Subscription data in the UDR/UDM. This can result in a change of the UE Subscription Data to include new S-NSSAI, DNN or CAG information, which can trigger update of the UE configurations, e.g. described in clause 5.15.5.2.2.

NOTE 4: The UE always has subscription to the HPLMN providing the PNI-NPN and has a USIM that contains primary authentication credentials.

Support for Proximity based Services (ProSe) as defined in TS 23.304 [128] in conjunction with CAG is not specified in this Release of the specification.

5.30.3.2 Identifiers

The following is required for identification:

– A CAG is identified by a CAG Identifier which is unique within the scope of a PLMN ID;

– A CAG cell broadcasts one or multiple CAG Identifiers per PLMN;

NOTE 1: It is assumed that a cell supports broadcasting a total of twelve CAG Identifiers. Further details are defined in TS 38.331 [28].

– A CAG cell may in addition broadcast a human-readable network name per CAG Identifier:

NOTE 2: The human-readable network name per CAG Identifier is only used for presentation to user when user requests a manual CAG selection.

5.30.3.3 UE configuration, subscription aspects and storage

To use CAG, the UE, that supports CAG as indicated as part of the UE 5GMM Core Network Capability, may be pre-configured or (re)configured with the following CAG information, included in the subscription as part of the Mobility Restrictions:

– an Allowed CAG list i.e. a list of CAG Identifiers the UE is allowed to access; and

– optionally, a CAG-only indication whether the UE is only allowed to access 5GS via CAG cells (see TS 38.304 [50] for how the UE identifies whether a cell is a CAG cell);

The HPLMN may configure or re-configure a UE with the above CAG information using the UE Configuration Update procedure for access and mobility management related parameters described in clause 4.2.4.2 of TS 23.502 [3].

The above CAG information is provided by the HPLMN on a per PLMN basis. In a PLMN the UE shall only consider the CAG information provided for this PLMN.

When the subscribed CAG information changes, UDM sets a CAG information Subscription Change Indication and sends it to the AMF. The AMF shall provide the UE with the CAG information when the UDM indicates that the CAG information within the Access and Mobility Subscription data has been changed. When AMF receives the indication from the UDM that the CAG information within the Access and Mobility Subscription has changed, the AMF uses the CAG information received from the UDM to update the UE. Once the AMF updates the UE and obtains an acknowledgment from the UE, the AMF informs the UDM that the update was successful and the UDM clears the CAG information Subscription Change Indication flag.

The AMF may update the UE using either the UE Configuration Update procedure after registration procedure is completed, or by including the new CAG information in the Registration Accept or in the Registration Reject or in the Deregistration Request or in the Service Reject.

When the UE is roaming and the Serving PLMN provides CAG information, the UE shall update only the CAG information provided for the Serving PLMN while the stored CAG information for other PLMNs are not updated. When the UE is not roaming and the HPLMN provides CAG information, the UE shall update the CAG information stored in the UE with the received CAG information for all the PLMNs.

The UE shall store the latest available CAG information for every PLMN for which it is provided and keep it stored when the UE is de-registered or switched off, as described in TS 24.501 [47].

The CAG information is only applicable with 5GS.

NOTE: CAG information has no implication on whether and how the UE accesses 5GS over non-3GPP access.

5.30.3.4 Network and cell (re-)selection, and access control

The following is assumed for network and cell selection, and access control:

– The CAG cell shall broadcast information such that only UEs supporting CAG are accessing the cell (see TS 38.300 [27], TS 38.304 [50]);

NOTE 1: The above also implies that cells are either CAG cells or normal PLMN cells. For network sharing scenario between SNPN, PNI-NPN and PLMNs, please see clause 5.18.

– In order to prevent access to NPNs for authorized UE(s) in the case of network congestion/overload, existing mechanisms defined for Control Plane load control, congestion and overload control in clause 5.19 can be used, as well as the access control and barring functionality described in clause 5.2.5, or Unified Access Control using the access categories as defined in TS 24.501 [47] can be used.

– For aspects of automatic and manual network selection in relation to CAG, see TS 23.122 [17];

– For aspects related to cell (re-)selection, see TS 38.304 [50];

– The Mobility Restrictions shall be able to restrict the UE’s mobility according to the Allowed CAG list (if configured in the subscription) and include an indication whether the UE is only allowed to access 5GS via CAG cells (if configured in the subscription) as described in clause 5.30.3.3;

– During transition from CM-IDLE to CM-CONNECTED and during Registration after connected mode mobility from E-UTRAN to NG-RAN as described in clause 4.11.1.2.2 of TS 23.502 [3]:

– The AMF shall verify whether UE access is allowed by Mobility Restrictions:

NOTE 2: It is assumed that the AMF is made aware of the supported CAG Identifier(s) of the CAG cell by the NG-RAN.

– If the UE is accessing the 5GS via a CAG cell and if at least one of the CAG Identifier(s) received from the NG-RAN is part of the UE’s Allowed CAG list, then the AMF accepts the NAS request;

– If the UE is accessing the 5GS via a CAG cell and if none of the CAG Identifier(s) received from the NG-RAN are part of the UE’s Allowed CAG list, then the AMF rejects the NAS request and the AMF should include CAG information in the NAS reject message. The AMF shall then release the NAS signalling connection for the UE by triggering the AN release procedure; and

– If the UE is accessing the 5GS via a non-CAG cell and the UE’s subscription contains an indication that the UE is only allowed to access CAG cells, then the AMF rejects the NAS request and the AMF should include CAG information in the NAS reject message. The AMF shall then release the NAS signalling connection for the UE by triggering the AN release procedure.

– During transition from RRC Inactive to RRC Connected state:

– When the UE initiates the RRC Resume procedure for RRC Inactive to RRC Connected state transition in a CAG cell, NG-RAN shall reject the RRC Resume request from the UE if none of the CAG Identifiers supported by the CAG cell are part of the UE’s Allowed CAG list according to the Mobility Restrictions received from the AMF or if no Allowed CAG list has been received from the AMF.

– When the UE initiates the RRC Resume procedure for RRC Inactive to RRC Connected state transition in a non-CAG cell, NG-RAN shall reject the UE’s Resume request if the UE is only allowed to access CAG cells according to the Mobility Restrictions received from the AMF.

– During connected mode mobility procedures within NG-RAN, i.e., handover procedures as described in clause 4.9.1 of TS 23.502 [3]:

– Source NG-RAN shall not handover the UE to a target NG-RAN node if the target is a CAG cell and none of the CAG Identifiers supported by the CAG cell are part of the UE’s Allowed CAG list in the Mobility Restriction List or if no Allowed CAG list has been received from the AMF;

– Source NG-RAN shall not handover the UE to a non-CAG cell if the UE is only allowed to access CAG cells based on the Mobility Restriction List;

– If the target cell is a CAG cell, target NG-RAN shall reject the N2 based handover procedure if none of the CAG Identifiers supported by the CAG cell are part of the UE’s Allowed CAG list in the Mobility Restriction List or if no Allowed CAG list has been received from the AMF;

– If the target cell is a non-CAG cell, target NG-RAN shall reject the N2 based handover procedure if the UE is only allowed to access CAG cells based on the Mobility Restriction List.

– Update of Mobility Restrictions:

– When the AMF receives the Nudm_SDM_Notification from the UDM and the AMF determines that the Allowed CAG list or the indication whether the UE is only allowed to access CAG cells have changed;

– The AMF shall update the Mobility Restrictions in the UE and NG-RAN accordingly under the conditions as described in clause 4.2.4.2 of TS 23.502 [3].

NOTE 3: When the UE is accessing the network for emergency services the conditions for AMF in clause 5.16.4.3 apply.

5.30.3.5 Support of emergency services in CAG cells

Emergency Services are supported in CAG cells, for UEs supporting CAG, whether normally registered or emergency registered as described in clause 5.16.4 and in clause 4.13.4 of TS 23.502 [3].

A UE may camp on an acceptable CAG cell in limited service state as specified in TS 23.122 [17] and TS 38.304 [50], based on operator policy defined in TS 38.300 [27].

NOTE: Support for Emergency services requires each cell with a Cell Identity associated with PLMNs or PNI-NPNs to only be connected to AMFs that supports emergency services.

The UE shall select a PLMN (of a CAG cell or non-CAG cell), as described in TS 23.122 [17] and TS 23.167 [18], when initiating emergency services from limited service state.

During handover to a CAG cell, if the UE is not authorized to access the target CAG cell as described in clause 5.30.3.4 and has emergency services, the target NG-RAN node only accepts the emergency PDU Session and the target AMF releases the non-emergency PDU Sessions that were not accepted by the NG-RAN node. Upon completion of handover the UE behave as emergency registered.