4 High level features

23.3163GPPRelease 18TSWireless and wireline convergence access support for the 5G System (5GS)

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

This clause specifies high level description equivalent to TS 23.501 [2].

4.1 General

The roaming support for W-5GAN access is not specified in this release.

The usage of Trusted or Untrusted access to 5GC by a 5G-RG or by a FN RG is not applicable.

4.2 Network Access Control

4.2.0 General

This clause specifies the delta related to network access control defined in TS 23.501 [2] clause 5.2.

4.2.1 Network selection

In the case of 5G-RG or FN-RG connected via W-5GAN the PLMN selection specification defined in TS 22.011 [25] and in TS 23.122 [26] is not applicable. The HPLMN is implicitly selected by wired physical connectivity between 5G-RG or FN-RG and W-AGF.

NOTE 1: The 5G-RG or FN-RG can only connect to a single physical wired access W-5GAN to a W-AGF configured at line provisioning by the operator, in addition no PLMN information is advertised by AS protocols in W-5GAN, since the Network selection feature is not supported.

The roaming scenario is not supported in this Release of the specification.

In the case of 5G-RG connected via FWA TS 23.501 [2] clause 5.2.2 applies with the following difference:

– The PLMN selection defined in TS 22.011 [25] and in TS 23.122 [26] applies with the UE replaced by 5G-RG.

4.2.2 Identification and authentication

In the case of 5G-RG connected via W-5GAN or FWA, the specification defined in TS 23.501 [2] clause 5.2.3 applies with the following difference:

– UE is replaced by 5G-RG.

In the case of FN-RG connected via W-5GAN, the specification defined in TS 23.501 [2] clause 5.2.3 applies with the following differences:

– UE is replaced by FN-RG.

– The W-AGF provides the NAS signalling connection to the 5GC on behalf of the FN-RG.

– The W-5GAN may authenticate the FN-BRG per BBF specification BBF TR-456 [9] and WT-457 [10]. The W-5GAN may authenticate the FN-CRG per CableLabs DOCSIS MULPI [8].

4.2.3 Authorisation

In the case of 5G-RG connected via W-5GAN or FWA, the specification defined in TS 23.501 [2] clause 5.2.4 applies with the following differences:

– UE is replaced by 5G-RG.

In the case of FN-RG connected via W-5GAN, the specification defined in TS 23.501 [2] clause 5.2.4 applies with the following differences:

– UE is replaced by FN-RG.

– W-AGF performs the UE Registration procedure on behalf of the FN-RG.

4.2.4 Access control and barring

In the case of 5G-RG or FN-RG connected via W-5GAN the Access Control and Barring defined in TS 23.501 [2] clause 5.2.5 is not applicable.

In the case of 5G-RG connected via FWA the specification defined in TS 23.501 [2] clause 5.2.5 applies with the following difference:

– UE is replaced by 5G-RG.

4.2.5 Policy control

Policy control is specified in clause 9.

4.2.6 Lawful Interception

In the case of 5G-RG connected via FWA the specification defined in TS 23.501 [2] clause 5.2.7 applies with the following difference:

– UE is replaced by 5G-RG.

In the case of 5G-RG connected via W-5GAN, the definition and functionality of Lawful Interception defined in TS 33.126 [32] applies with the following difference:

– UE is replaced by 5G-RG.

In the case of FN-RG connected via W-5GAN, the definition and functionality of Lawful Interception defined in TS 33.126 [32] applies with the following difference:

– UE is replaced by FN-RG, with e.g. the difference that FN-RG may not have a globally unique PEI (as described in clause 4.7.7) and does not hold any 3GPP-based subscriber credentials or subscriber identity information.

4.3 Registration and Connection Management

4.3.1 Registration management

Registration management when 5G-RG or FN-RG is connected to 5GC via wireline access is described in TS 23.501 [2] clause 5.5.1.

Registration management when 5G-RG is connected to 5GC via NG RAN access is described in TS 23.501 [2], clause 5.3.2.

4.3.2 Connection management

Connection management when 5G-RG or FN-RG is connected to 5GC via wireline access is described in clause 5.5.2 of TS 23.501 [2].

Connection management when 5G-RG is connected to 5GC via NG RAN access is described in clause 5.3.3 of TS 23.501 [2].

4.3.3 Mobility Restrictions

4.3.3.1 General

Mobility Restrictions restrict service access of an 5G-RG depending on RG location.

For a 5G-RG connecting over NG-RAN, the Mobility Restriction functionality as described in clause 5.3.4.1 of TS 23.501 [2] applies.

For an 5G-RG connecting over wireline access, the Mobility Restriction functionality is described in this clause.

Mobility restrictions do not apply to scenarios with FN-BRG.

NOTE 1: Since access to 5GC for FN-BRG subscriptions are identified by a SUPI determined from the GLI as described in clause 4.7.3 and clause 4.7.8. Such subscriptions are by definition restricted to a specific location.

NOTE 2: For FN-CRG subscriptions, HFC Node ID is used to identify the location of FN-CRG, thus service area restrictions for the FN-CRG can be identified by an HFC_Node ID, or by a list of HFC_Node ID.

Mobility Restrictions for wireline access consists of Forbidden Area and Service Area Restrictions, as described in the following clauses.

4.3.3.2 Management of Forbidden Area in wireline access

In a Forbidden Area, the 5G-RG, based on subscription, is not permitted by the 5GC to initiate any communication with the 5GC for this PLMN.

The UDM stores the Forbidden Area for wireline access in the same way as for 3GPP access, with the following differences:

– For subscriptions for 5G-BRG, GLI is used to describe the Forbidden Area.

– For subscriptions for 5G-CRG and FN-CRG, HFC Node IDs are used to describe the Forbidden Area (instead of TA).

– The Forbidden Area in UDM can be encoded as a "allow list" indicating the non-forbidden area. In this case all GLI or HFC_Node ID values not included in the list are considered forbidden.

NOTE: The use of "allow list" is to ensure an efficient Forbidden Area definition if only a small set of GLI / HFC Node ID values are not forbidden.

Forbidden Area is enforced by AMF, based on subscription data and the location information received from W-AGF. The AMF rejects a Registration Request from a 5G-RG or the W-AGF acting on behalf of a FN-CRG in a Forbidden Area with a suitable cause code. The 5G-RG behaviour depends on the network response (cause code from AMF) that informs the RG that communication is forbidden.

4.3.3.3 Management of Service Area Restrictions in wireline access

The subscription data in the UDM for a 5G-BRG includes a Service Area Restriction which may contain either Allowed or Non-Allowed Areas specified by using explicit GLI(s) and/or other geographical information (e.g., longitude/latitude, zip code, etc.).

The subscription data in the UDM for a 5G-CRG and FN-CRG includes a Service Area Restriction which may contain either Allowed or Non-Allowed Areas specified by using explicit HFC Node IDs and/or other geographical information (e.g., longitude/latitude, zip code, etc.).

The geographical information used to specify allowed or non-allowed area is only managed in the network, and the network will map it to a list of GLI(s) or HFC Node IDs before sending Service Area Restriction information to the PCF.

The UDM stores the Service Area Restrictions for the 5G-RG or FN-CRG as part of the subscription data. The PCF in the serving network may (e.g. due to varying conditions such as 5G-RG’s location, time and date) further adjust Service Area Restrictions of a 5G-RG, either by expanding an allowed area or by reducing a non-allowed area. The UDM and the PCF may update the Service Area Restrictions of a 5G-RG or a FN-CRG at any time.

During registration, if the Service Area Restrictions of the 5G-RG or FN-CRG is not present in the AMF, the AMF fetches from the UDM the Service Area Restrictions of the 5G-RG or FN-CRG that may be further adjusted by the PCF. The serving AMF shall enforce the Service Area Restrictions of a 5G-RG and a FN-CRG. The AMF receives the location information (GLI, HFC Node IDs) where the RG is connected from the W-AGF via N2.

The network does not send any Allowed Area or Non-Allowed Area to the 5G-RG for wireline access. If the 5G-RG initiates communication in an Allowed Area, the network accepts the communication as allowed by the subscription. If the 5G-RG initiates Service Request or SM signalling in a Non-Allowed Area, the AMF rejects the request with a suitable cause code indicating that the 5G-RG/W-AGF should not retry Service Request and SM signalling while being connected to the same line.

Upon change of serving AMF due to mobility, the old AMF may provide the new AMF with the Service Area Restrictions of the 5G-RG that may be further adjusted by the PCF.

4.4 Session management

4.4.0 General

This clause specifies the delta related to session management defined in TS 23.501 [2] clause 5.6.

The LADN service defined in clause 5.6.5 in TS 23.501 [2] does not apply for RG connected to 5GC via wireline access.

When handling DHCP signalling coming from a wireline BBF access, the SMF (as well as an external DHCP server used by SMF) shall support the DHCP signalling as described in in BBF TR-456 [9].

NOTE: As described in clause 5.6.14 of TS 23.501 [2], to enable Framed Routes for a PDU Session, SMF can take the UPF capabilities for Framed Routes into account when selecting a UPF for a PDU Session.

4.4.1 Session management for 5G-RG

Session management of 5G-RG connected to 5GC via wireline access follows the principle defined in TS 23.501 [2] clause 5.6 with the following difference:

– UE is replaced by 5G-RG.

– 5G-RG is connected to 5GC via wireline RAT type instead of 3GPP access.

4.4.2 Session management for FN-RG

Session management of FN-RG follows the principle defined in TS 23.501 [2] clause 5.6 with the follow difference:

– UE is replaced by W-AGF

– FN-RG is connected to 5GC via wireline access instead of 3GPP access.

– Secondary authentication/authorization by a DN-AAA server during the establishment of a PDU Session is applicable neither to FN-RG nor to N5GC devices.

– For FN-BRG, only SSC modes 1 or 2 can be used, depending on the type of FN-BRG as described in TR‑456 [9] and WT-457 [10].

4.5 QoS model

4.5.0 General overview

The QoS model of TS 23.501 [2] clause 5.7 is applicable to the W-5GAN scenario, with the difference that the W-AGF acts as an Access Network (AN).

The principle for classification and marking of User Plane traffic and mapping of QoS flows to W-UP resources is illustrated in Figure 4.5-1.

Figure 4.5-1: The principle for classification and User Plane marking for QoS Flows and mapping to W-UP resources for a PDU Session

When the W-AGF receives N2 requests related with PDU Session resources, the W-AGF maps the QoS profile(s) received from the 5GC to W-UP level QoS.

When the 5G-RG receives NAS message related with PDU Session QoS, the 5G-RG maps the QoS rule(s) received in NAS to W-UP level QoS.

One W-UP resource can be used as the default W-UP resource. There shall be one and only one Default W-UP resource per PDU session. The 5G-RG shall send all QoS Flows to this W-UP resource for which there is no mapping information to a specific W-UP resource.

Handling of UL traffic by the 5G-RG:

– When the 5G-RG transmits an UL PDU, the 5G-RG shall determine the QFI associated with the UL PDU (by using the QoS rules of the PDU Session), it shall encapsulate the UL PDU inside an access layer dependent W-UP packet and shall forward the W-UP packet to W-AGF via the W-UP resource associated with this QFI.

Handling of DL traffic by W-AGF:

– When the W-AGF receives a DL PDU via N3, it identifies of the PDU Session and optionally the QFI in order to determine the W-UP resource to use for sending the DL PDU to the 5G-RG. The W-AGF may include also in the W-UP header the Reflective QoS Indicator (RQI), which shall be used by the 5G-RG to enable reflective QoS.

The W-AGF will map 5QI received from the 5GC into access-specific QoS parameters relevant to the wireline access network. The mapping of 5QI to W-5GBAN QoS parameters is specified by the BBF for W-5GBAN in [9]. The mapping of 5QI to W-5GCAN QoS parameters is specified for W-5GCAN in CableLabs WR-TR-5WWC-ARCH [27].

QFI or other QoS parameters are carried via W-UP to the 5G-CRG as specified in CableLabs WR-TR-5WWC-ARCH [27].

The QFI and RQI are carried via W-UP to 5G-RG as specified in BBF TR-456 [9].

4.5.1 Wireline access specific 5G QoS parameters

4.5.1.0 Overview

The 5G QoS parameters specified in clause 5.7.2 of TS 23.501 [2] are applicable to wireline access network, with the following differences:

– The parameters defined in clause 4.5.1.2 are applicable for the wireline access network related PDU sessions.

– UE-AMBR is not applicable to wireline access. The AMF should not provide the subscribed UE-AMBR to the W-AGF.

4.5.1.1 Void

4.5.1.2 RG Level Wireline Access Characteristics

The wireline access networks may exhibit QoS control mechanisms and related thresholds, such as QoS class specific maximum bit rates, which the W-AGF needs to be aware of, in order to provide appropriate mapping of the QoS characteristics of the 5G QoS flows to the wireline technology specific QoS parameters.

These wireline access characteristics are considered to be relevant for a specific wireline access subscription, and correspond to RG level QoS information in the 5GC.

While the wireline access characteristics are important for implementing the end to end QoS mechanisms, across the 5G-RG/FN-RG, the W-5GAN and the 5GC, they only need to be acted on in the 5G-RG/FN-RG and the W-5GAN.

In order to support the W-AGF in implementing the mapping between 5G QoS parameters and wireline access specific parameters, the AMF may provide the RG Level Wireline Access Characteristics (RG-LWAC) to the W-AGF at the time of the RG registration. When the UDM notifies the AMF of the updated RG-LWAC via Nudm_SDM_Notification service, the AMF may update the RG-LWAC to the W-AGF via NGAP UE Context Modification procedure.

Given that the 5GC does not act on these parameters, their structure is out of scope in 3GPP specifications and they are handled as a transparent data container. BBF and CableLabs may define the content and structure of this container for their own use.

The UE subscription data parameters RG Level Wireline Access Characteristics are defined in clause 8.1.1.

4.5.2 QoS model applied to FN-RG

The FN-RG does not support 3GPP signalling and therefore, mapping and interworking between 5G QoS and the wireline access network resources is managed by the W-AGF on behalf of the FN-RG.

The mapping of W-5GAN resources and 5GC QoS is configured in the W-AGF for the FN-CRG is specified by CableLabs. Resource management within the W-5GAN for the FN-CRG is specified by CableLabs.

The mapping of W-5GAN resources and 5GC QoS is configured in the W-AGF for the FN-BRG is specified by BBF. Resource management within the W-5GAN for the FN-BRG is specified by BBF.

4.6 User Plane management

4.6.1 General

The management of the user plane follows the description in clause 5.8 of TS 23.501 [2] with additional specification described below in this clause.

4.6.2 IP address allocation

4.6.2.1 General

IP address allocation is performed as described in TS 23.501 [2] clause 5.8.2.2, with the differences and additions described in this clause.

Stateless IPv6 Address Autoconfiguration applies with the differences described in clause 4.6.2.4.

In addition to the IP address management features described in TS 23.501 [2] clause 5.8.2.2 the 5GC network functions and RG support the following mechanisms:

a. IPv6 address allocation using DHCPv6 may be supported for allocating individual /128 IPv6 address(es) for a PDU Session. The details of IPv6 address allocation using DHCPv6 are described in clause 4.6.2.2.

b. IPv6 Prefix Delegation using DHCPv6 may be supported for allocating additional IPv6 prefixes for a PDU Session. The details of Prefix Delegation are described in clause 4.6.2.3.

The mechanisms in a. and b. above are only applicable for IPv6 and IPv4v6 PDU Session types.

The requested IPv6 address or set of IPv6 Prefixes may be (as defined in TS 23.501 [2] clause 5.8.2.2.1):

– allocated from a local pool in the SMF or

– obtained from the UPF. In that case the SMF shall interact with the UPF via N4 procedures to obtain a suitable IP address/Prefix, or

– obtained from an external server.

When obtaining the IP address from the UPF, the SMF provides the UPF with the necessary information allowing the UPF to derive the proper IP address (e.g. the network instance, IP version, size of the IP address or Prefix the UPF is to allocate).

The SMF may also provide IP configuration parameters (e.g. MTU value) to the 5G-RG, as described in clause 5.6.10 of TS 23.501 [2].

NOTE: In order to provide an IP MTU value that is specifically suitable for W-5GAN without considering N3 in case of combined W-AGF/UPF, the SMF can e.g. be configured with such MTU for a given DNN and/or for a given slice whether the DNN and/or the slice only serves wireline access and a UPF combined with the W-AGF has been selected for the PDU Session.

In this clause, unless specified otherwise, the RG may correspond either to a 5G RG or to a FN RG.

4.6.2.2 IPv6 Address Allocation using DHCPv6

Optionally, and instead of using Stateless IPv6 Address Autoconfiguration, individual 128-bit IPv6 address(es) may be assigned to a PDU Session.

In this case, after PDU Session Establishment, the SMF sends a Router Advertisement message (solicited or unsolicited) towards the RG. The SMF shall set the Managed Address Configuration Flag (M-flag) in the Router Advertisement messages to indicate towards the RG that IPv6 Address allocation using DHCPv6 is available, as described in RFC 4861 [34]. In that case the IPv6 address of the RG is allocated using DHCPv6 Identity Association for Non-temporary Addresses (IA_NA) and mechanisms defined in RFC 3315 [15].

The SMF may receive a Router Solicitation message, soliciting a Router Advertisement message.

When using DHCPv6 address allocation, a prefix (e.g. /64) may be allocated for the PDU Session at PDU Session Establishment from which the /128 addresses are selected. The SMF determines the size of the prefix for a PDU Session to a specific DNN and S-NSSAI based on subscription data and local configuration. The individual /128 address(es) allocated to the RG as part of DHCP IA_NA procedure are then selected from the prefix allocated to the PDU Session. For statically assigned prefix, the subscription data in UDM for a DNN and S-NSSAI includes the prefix. Alternatively, individual 128-bit address(es) are allocated for the PDU Session without allocating a prefix to the PDU Session and provided to the RG as part of DHCP IA_NA procedure.

When a prefix is allocated to the PDU Session, the SMF provides the prefix to the PCF instead of each /128 address. When individual /128 address(es) are allocated without allocating a prefix to the PDU Session, the SMF provides the /128 bits address(es) to PCF. Whether the SMF allocates a prefix for the PDU Session or individual 128-bit addresses is transparent to the RG and W-5GAN.

If Prefix Delegation (as described in clause 4.6.2.3) is also supported, a SMF may receive both DHCP options for IA_NA and IA_PD together in a single DHCPv6 message. An SMF may provide a reply to both IA_NA and IA_PD in the same message or alternatively process the DHCPv6 IA_NA before the DHCPv6 IA_PD.

The SMF may receive multiple different IA_NA related DHCP requests within the same PDU Session.

NOTE: This is applicable if the RG acts as a DHCP relay for devices behind the RG.

When IPv6 Address Allocation using DHCPv6 is used, 5GC does not support IPv6 multi-homing for enabling SSC mode 3 and PDU Sessions with multiple PDU Session Anchors.

4.6.2.3 IPv6 Prefix Delegation via DHCPv6

Optionally a single network prefix shorter than the default /64 prefix may be assigned to a PDU Session.

If IPv6 stateless autoconfiguration is used, the /64 default prefix used for IPv6 stateless autoconfiguration may be allocated from this network prefix; the remaining address space from the network prefix can be delegated to the PDU session using prefix delegation after the PDU Session establishment and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in TS 23.501 [2] clause 5.8.2.2.3. In this case the address space provided is maintained as an IPv6 address space pool available to the PDU Session for DHCPv6 IPv6 prefix requests with the exclusion of the IPv6 prefix that is allocated to the PDU Session using stateless IPv6 address allocation. In that case it is possible to aggregate the total IPv6 address space available for the PDU Session into one IPv6 prefix that will represent all IPv6 addresses that the RG may use.

The SMF determines the maximum size of the prefix that may be allocated for the PDU Session based on subscription data and local configuration.

If stateless IPv6 address autoconfiguration procedure is used by the RG to get the first Prefix of the PDU Session, DHCPv6 is used to request additional IPv6 prefixes (e.g. prefixes in addition to the default prefix) from the SMF after completing stateless IPv6 address autoconfiguration procedures. If IPv6 address allocation using DHCPv6 is used, the DHCPv6 message may include a request for a delegated prefix (IA_PD) together with a request for an IPv6 address (IA_NA). Alternatively, a delegated prefix may be requested after an IPv6 address has been assigned using IA_NA.

The RG acts as a "Requesting Router" as described in IETF RFC 3633 [17] and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent to the SMF via the user plane and the UPF. The SMF acts as the DHCP server and fulfils the role of a "Delegating Router" according to IETF RFC 3633 [17]. The RG optionally includes the RAPID_COMMIT option in the DHCPv6 Solicit message to trigger two-message DHCPv6 procedure instead of the four-message DHCPv6 procedure.

In response to the DHCPv6 Solicit message, the SMF sends a DHCPv6 Reply message with one or more IA_PD prefix(es) for every IA_PD option that was received in the DHCPv6 Solicit message.

If the DHCPv6 request indicates support for prefix exclusion via the OPTION_PD_EXCLUDE option code in an OPTION_ORO option and if the SMF accepts this option, the SMF delegates a prefix excluding the default prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow IETF RFC 6603 [16].

4.6.2.4 The procedure of Stateless IPv6 Address Autoconfiguration

Stateless IPv6 Address Autoconfiguration applies as described in clause 5.8.2.2.3 of TS 23.501 [2] with the differences described below.

When the W-AGF is serving an FN-RG, the W-AGF may include in the PDU Session Establishment Request an interface identifier of the FN-RG IPv6 link-local address associated with the PDU Session. If the SMF receives an interface identifier in the PDU Session Establishment Request message, the SMF provides this interface identifier value as the UE interface identifier in the PDU Session Establishment Accept message. To ensure that the link-local address used by the FN-RG does not collide with the link-local address of the SMF in this case, the SMF selectes a different link-local address for use as the SMF link local address for the PDU Session. If the PDU Session Establishment Request message does not contain an interface identifier, the SMF selects interface identifier for the UE, and SMF link-local address, as described in clause 5.8.2.2.3 of TS 23.501 [2].

NOTE 1: An FN-RGs is configuring its IPv6 link local address based on its MAC address and is not able to use an interface identifier selected by SMF as described in clause 5.8.2.2.3 of TS 23.501 [2].

In case of wireline access, independent of whether SMF received an interface identifier in the PDU Session Establishment Request message or not, the SMF includes the SMF link local address in the PDU Session Establishment Accept message.

NOTE 2: The SMF link local address is needed by the W-AGF to support procedures towards the FN-RG defined in BBF TR-456 [9].

4.6.3 Packet Detection Rule

PDR used to support PDU Sessions for RG follow the specifications in TS 23.501 [2] clause 5.8.2.11.3 with the clarifications and additions shown below.

For PDU Session used for IPTV service, (see also clause 4.6.6):

– Packets Filter Set support Packet Filters for IGMP, including IGMPv2 specified in RFC 2236 [33], IGMPv3 specified in RFC 4604 [21], for MLDv1 specified in RFC 2710 [36] and MLDv2 specified in RFC 4604 [21]. The PDR may also contain IP Multicast addressing information that may refer to ranges of IP multicast addresses. Such IP Multicast addressing information is not part of the PDI. The packets filters for IGMPv1 defined in RFC 1112 [35] are not supported.

4.6.4 Forwarding Action Rule

FAR used to support PDU Sessions for RG follow the specifications in TS 23.501 [2] clause 5.8.2.11.6 with the clarifications and additions and difference shown below.

For PDU Sessions used for IPTV service (see also clause 4.6.6):

– Following additional "Action" values are used to support IPTV service:

– "IP Multicast Accept" indicates whether in the case of IGMP and MLD Membership Report message to accept the multicast join and add the PDU Session to the requested multicast group distribution. This may also imply acting as an IP Multicast Router as described in clause 7.7.1.1

NOTE 1: The IGMP "Join message" and MLD "Join message" are generic terms used in this document to indicate the request of a host to join a multicast group which can express via IGMP and MLD Report message (e.g. Membership Report) or via Join message.

NOTE 2: In this specification the generic term IGMP refers to both IGMPv2 and IGMPv3 unless specifically defined. The term MLD refers to both MLDv1 and MLDV2 unless specifically defined.

– "IP Multicast Accept" indicates that when UPF detects the IGMPv3 Leave message or a MLD Done message via the PDU Session, the UPF needs also to ensure that the PDU Session is removed from the requested multicast group distribution.

– "IP Multicast Deny" indicates that the UPF shall not accept the corresponding IGMP and MLD Membership Report message to join a multicast group.

4.6.5 Usage Reporting Rule

URR used to support PDU Sessions for RG follow the specifications in TS 23.501 [2] clause 5.8.2.11.5 with the clarifications and additions shown below:

For PDU Sessions used for IPTV service (see also clause 4.6.6), an URR may indicate a Reporting trigger (defined in TS 23.501 [2] clause 5.8.2.11.5) with a value Reporting Trigger set to "IGMP reporting" for IGMP or set to "MLD reporting" for MLD where the UPF is to report to the SMF when

– it adds a PDU session to the DL replication tree associated with an IP Multicast flow;

– it removes a PDU session from the DL replication tree associated with an IP Multicast flow.

The corresponding notification shall contain the (Source IP address of the DL multicast flow, Destination IP address of the DL multicast flow).

NOTE: The corresponding notification can be used by the SMF to report the information to the PCF and/or to CHF.

4.6.6 Usage of N4 to support IPTV

The SMF sends to the UPF acting as PSA N4 rules such as PDR, FAR related to IP Multicast traffic allowed for the PDU Session of a 5G-RG. IP Multicast traffic allowed for the PDU Session corresponds to IPTV services allowed for the user. IP Multicast Addressing information identifies such traffic. In the case Source Specific Multicast is configured to be used on the PDU Session, IP Multicast Addressing information refers to both IP Multicast address and Source IP address.

The SMF may need to take into account UPF capability to support the features described in this clause when selecting an UPF to serve a PDU Session. For IPv6 PDU session IPTV services will be based on MLD , for IPV4 PDU session on IGMP.

N4 rules for IP Multicast traffic related to IPTV service may correspond to:

– Rules related with UL IGMP or MLD traffic:

– a PDR identifying IGMP signalling or MLD together with IP Multicast Addressing information identifying a set of IP multicast groups;

NOTE 1: The IP Multicast Addressing information may correspond to ranges of IP Multicast addresses

– a FAR with:

– an "IP Multicast Accept" action in order to request the UPF to accept UE requests to join the corresponding IP multicast group(s); or

– an "IP Multicast Deny" action in order to request the UPF to deny UE requests to join the corresponding IP multicast group(s);

– possibly a URR with a Reporting Trigger set to "IGMP reporting" for IGMP or set to "MLD reporting" for MLD.;

– Rules related with DL IP Multicast traffic:

– a PDR identifying IP Multicast Addressing information (DL IP Multicast traffic);

NOTE 2: The IP Multicast Addressing information may correspond to ranges of IP Multicast addresses

– a FAR asking to add outer header = GTP-u tunnel related with the PDU Session of the 5G RG;

– a QER indicating the QoS to use towards the 5G-RG for the IP Multicast traffic that has been replicated.

4.7 Identifiers

4.7.1 General

As described in TS 23.501 [2], each subscriber in the 5G System shall be allocated one 5G Subscription Permanent Identifier (SUPI) for use within the 3GPP system. As described in TS 23.501 [2], each FN-RG or 5G-RG accessing the 5G System shall be assigned a Permanent Equipment Identifier (PEI).

The clauses below describe specific aspects for supporting 5G-RG and FN-RG.

4.7.2 SUPI and SUCI for 5G-BRG support

The SUPI for an 5G-BRG shall contain an IMSI, as described in clause 5.9.2 of TS 23.501 [2].

The SUCI provided by the 5G-BRG to the network contains the concealed SUPI, as described in TS 33.501 [11].

4.7.3 SUPI and SUCI for FN-BRG support

The SUPI for an FN-BRG subscription shall, based on operator configuration, either contain an IMSI or a GLI as defined in clause 4.7.8. A SUPI containing a GLI takes the form of a NAI whose user part is the GLI and whose realm part is an identifier of the operator owning the subscription.

The SUCI provided by the W-AGF to the 5GC for FN-BRG always corresponds to a SUPI containing a GLI. This SUCI acts as pseudonym of the SUPI and the UDM performs a mapping to the actual SUPI that, depending on operator configuration, contains either an IMSI or the same GLI that was provided in the SUCI.

As described in TS 23.003 [14], the SUCI also contains an identifier of the Home network, i.e. the identifier of the operator owning the subscription.

4.7.4 SUPI and SUCI for 5G-CRG and FN-CRG support

The SUPI for a FN-CRG subscription shall, based on operator configuration, contain either an IMSI, as described in clause 5.9.2 of TS 23.501 [2], or a GCI (Global Cable identifier defined in clause 4.7.9).

The SUPI for a 5G-CRG subscription shall, based on operator configuration, contain either an IMSI, as described in clause 5.9.2 of TS 23.501 [2], or a GCI (Global Cable identifier defined in clause 4.7.9).

Only 5G-CRG whose SUPI corresponds to an IMSI may use 3GPP access to connect to 5GC.

A SUPI containing a GCI takes the form of a NAI where the user part is the GCI and the realm part is an identifier of the operator managing the subscription.

NOTE 1: The realm part used to identify the operator managing the subscription can differ depending on whether the wireline access network belongs to a PLMN or SNPN. The NAI format for SUPI containing GCI for PLMN and SNPN is defined in TS 23.003 [14].

The SUCI provided by the 5G-CRG to the network contains the concealed SUPI, as described in TS 33.501 [11].

The SUCI provided to the network for FN-CRG support always corresponds to a SUPI containing a GCI. This SUCI acts as pseudonym of the SUPI and the UDM performs a mapping to the SUPI that, depending on operator configuration, contains either an IMSI or the same GCI than in the SUCI.

As described in TS 23.003 [14], for both cases where the SUCI contains an IMSI or contains a GCI, the SUCI contains an identifier of the Home network i.e. an identifier of the operator managing the subscription.

NOTE 2: If the SUCI contains an IMSI, the identifier of the operator managing the subscription is carried in the MCC/MNC part of the IMSI as defined in TS 23.003 [14].

4.7.5 Line ID

The Line ID is defined in BBF Specifications, see BBF TR-470 [38].

4.7.6 HFC identifier

The HFC_Identifier may contain a cable modem MAC address or an overall HFC account identifier, as defined by CableLabs in DOCSIS MULPI [8].

4.7.7 PEI

If the 5G-RG (i.e. 5G-BRG and 5G-CRG) supports at least one 3GPP access technology (i.e. NG-RAN, E-UTRAN), the 5G-RG must be allocated a Permanent Equipment Identifier (PEI) in the IMEI or IMEISV format, as described in TS 23.501 [2]. The 5G-RG shall present this PEI to the network independent of access technology used by the 5G-RG (3GPP access technology or W-5GAN access technology).

If the 5G-BRG supports only W-5GAN access, the PEI shall contain the 5G-BRG MAC address.

If the 5G-CRG supports only W-5GAN access, the PEI shall contain the cable modem MAC address.

For FN-RG (i.e. FN-BRG and FN-CRG), the W-AGF shall provide a PEI containing:

– The FN-RG MAC address: this shall be used by the W-AGF when it is known by configuration that the MAC address received by the W-AGF is unique (no other entity can use the same MAC address) and corresponds to the permanent MAC address configured on the RG by the manufacturer.

NOTE 1: This assumes that the W-AGF can see the actual permanent MAC address of the FN-RG and not the MAC address of any intermediate entity (e.g. DSLAM).

– The MAC address received by the W-AGF, together with an indication provided by the W-AGF that this address cannot be used as an Equipment identifier of the FN-RG: this shall be used by the W-AGF when the conditions to provide a PEI containing the FN-RG MAC address are not met.

NOTE 2: This is to support the case of legacy deployments for FN RG where either multiple FN RG can share the same MAC address or where the MAC address received by the W-AGF is not that of the FN RG but the MAC address of an intermediate entity between the FN RG and the W-AGF.

NOTE 3: When the PEI contains an indication that the MAC address cannot be used as an Equipment identifier of the FN-RG, the PEI cannot be trusted for regulatory purpose but it can be stored in CDR and used for troubleshooting.

4.7.8 Global Line Identifier

For usage with 5GC, a Global Line Identifier (GLI) is specified in order to define a globally unique identifier of the line connecting the RG to the network. In this release an RG is associated with a unique GLI.

For FN BRG, the GLI is used to build a SUCI. For FN-BRG the GLI may be used to build a SUPI. See clause 4.7.3. For all types of RG, the GLI is used as User Location Information on wireline access.

The GLI contains an identifier of the Line ID source and the Line ID value. The identifier of the Line ID source ensures the unicity of the GLI while the Line ID may not be unique in some deployments. The identifier of the Line ID source and Line ID are administered by the W-AGF operator.

The Global Line Identifier is a variable length identifier encoded as defined in TS 23.003 [14] and in BBF TR‑470 [38].

4.7.9 Global Cable Identifier

For usage with 5GC, a Global Cable Identifier (GCI) is specified in order to define a globally unique identifier of the line connecting the CRG to the network. In this release an RG is associated with a unique GCI.

The GCI contains the HFC_Identifier which is defined in CableLabs WR-TR-5WWC-ARCH [27].

For FN CRG, the GCI is used to build a SUCI. For FN CRG the GCI may be used to build a SUPI. See clause 4.7.4. For all types of CRG the HFC Node ID is used to build User Location Information on Cable access.

The identifier of the HFC Node ID and the HFC_Identifier are administered by the W-AGF operator.

The Global Cable Identifier is a variable length identifier encoded as defined in TS 23.003 [14] and CableLabs WR‑TR‑5WWC‑ARCH [27].

4.7.10 RAT types dedicated for Wireline access

The AMF, as described in TS 23.501 [2] clause 5.3.2.3, determines the RAT Type for Wireline access, taking into account the Global W-AGF Node ID and possibly ULI information provided by the W-AGF. The RAT Type may allow to distinguish between Wireline, Wireline-Cable access andWireline-BBF access.

4.7.11 SUPI and SUCI for N5GC device support

The SUPI for non-5G capable (N5GC) device connecting via CRG shall contain a network-specific identifier. A SUPI containing a network-specific identifier takes the form of a Network Access Identifier (NAI) as defined in TS 23.003 [14].

The SUCI provided by the W-AGF to the AMF is derived from the EAP-Identity message received from the N5GC device, as defined in TS 33.501 [11]. The format of this SUCI is defined in TS 23.003 [14].

4.8 Security aspects

TS 23.501 [2] clause 5.10 applies to the FN-CRG with the following deltas:

– Mutual authentication of the FN-CRG and the wireline access network is completed as specified by CableLabs DOCSIS MULPI [8]. The successful completion of the authentication of the FN-CRG is conveyed by the W-AGF serving the FN-CRG to the AMF.

– UE is replaced by W-AGF on behalf of the FN-CRG for the balance of TS 23.501 [2] clause 5.10 and clauses.

– See TS 33.501 [11] for additional requirements

TS 23.501 [2] clause 5.10 applies to the 5G-CRG with the following deltas:

– The UE is replaced by the 5G-CRG

– Signalling security aspects between the 5G-CRG and the W-AGF are specified by CableLabs in WR-TR-5WWC-ARCH [27].

– See TS 33.501 [11] for additional requirements

4.9 Support of specific services

4.9.0 General

This clause specifies high level definition of services specific for WWC scenario.

PWS functionality as described in TS 23.041 [40] is not supported for Wireline access but may be supported by RG(s) connected over 3GPP access.

4.9.1 IPTV

IPTV is defined as multimedia services such as television/video/ audio/text/graphics/data delivered over IP-based networks managed to support the required level of QoS/QoE, security, interactivity and reliability. STB obtains IPTV service via RG, including 5G-RG and FN-RG, which are connected to 5GC.

The procedures to support IPTV is specified in clause 7.7.1.

4.10 UE behind 5G-RG and FN-RG

An RG connecting via W-5GAN or NG-RAN access towards 5GC can provide connectivity for a UE behind the RG to access an N3IWF or TNGF. It is assumed that the UE is 5GC capable, i.e. supports untrusted non-3GPP access and/or trusted non-3GPP access. This allows the RG, W-5GAN and the RG’s connectivity via 5GC to together act as untrusted/trusted N3GPP access to support UEs behind the RG.

When FN-RG/5G-RG is serving a UE, the control and user plane packets of the UE is transported using a FN-RG/5G-RG IP PDU session and then from PSA UPF of that PDU session to an IWF. A single FN-RG/5G-RG IP PDU session can be used to serve multiple UEs.

Figure 4.10-1 shows the non-roaming architecture for a UE, behind a 5G-RG, accessing the 5GC via TNGF where the combination of 5G-RG, W-5GAN and UPF serving the 5G-RG is acting as a trusted Non-3GPP access network.

NOTE 1: FN-RG and W-5GAN acting as trusted Non-3GPP access is not considered in this specification as it is assumed that FN-RG does not support EAP-based access control (e.g. 802.1X).

Figure 4.10-1: Non-roaming architecture for UE behind 5G-RG using trusted N3GPP access

The 5G-RG can be connected to 5GC via W-5GAN, NG-RAN or via both accesses. The UE can be connected to 5GC via 5G-RG, NG-RAN or via both accesses.

The TNGF and Ta reference point are defined in TS 23.501 [2].

NOTE 2: The reference architecture in figure 4.10-1 only shows the architecture and the network functions directly connected to W-5GAN or TNGF, and other parts of the architecture are the same as defined in clause 4.2 of TS 23.501 [2].

NOTE 3: The reference architecture in figure 4.10-1 supports service based interfaces for AMF, SMF and other NFs not represented in the figure.

NOTE 4: The two N2 instances in Figure 4.10-1 apply to a single AMF for a 5G-RG which is simultaneously connected to the same 5G Core Network over 3GPP access and W-5GAN.

4.10a Non-5G capable device behind 5G-CRG and FN-CRG

For isolated 5G networks (i.e. roaming is not considered) with wireline access, non-5G capable (N5GC) devices connecting via W-5GAN can be authenticated by the 5GC using EAP based authentication method(s) as defined in TS 33.501 [11]. The following call flow describes the overall registration procedure of such a device.

Roaming is not supported for N5GC devices

The usage of N5GC device correspond to a subscription record in UDM/UDR that is separate from that of the CRG.

Figure 4.10a-1: 5GC registration of Non-5GC device

1. The W-AGF registers the FN-CRG to 5GC as specified in clause 7.2.1.3 or the 5G-CRG registers to 5GC as specified in clause 7.2.1.1.

2. The CRG is configured as L2 bridge mode and forwards any L2 frame to W-AGF. 802.1x authentication may be triggered. This can be done either by N5GC device sending a EAPOL-start frame to W-AGF or W-AGF receives a frame from an unknown MAC address.

How the CRG is configured to work in L2 bridge mode and how the W-AGF is triggered to apply procedures for N5GC devices is defined in CableLabs WR-TR-5WWC-ARCH [27].

The N5GC device send an EAP-Resp/Indentity including its Network Access Identifier (NAI) in the form of username@realm.

3. W-AGF, on behalf of the N5GC device, sends a NAS Registration Request message to AMF with a device capability indicator that the device is non-5G capable. For this purpose, the W-AGF creates a NAS Registration Request message containing a SUCI. The W-AGF constructs the SUCI from the NAI received within EAP-Identity from the N5GC device as defined in TS 33.501 [11].

Over N2 there is a separate NGAP connection per N5GC device served by the W-AGF.

When it provides (over N2) ULI to be associated with a N5GC device, the W-AGF builds the N5GC’s ULI using the GCI (see clause 4.7.9) of the CRG connecting the N5GC device.

NOTE: How the W-AGF determines the CRG connecting a N5GC device is specified in CableLabs WR-TR-5WWC-ARCH [27].

4. AMF selects a suitable AUSF as specified in TS 23.501 [2] clause 6.3.4.

5. EAP based authentication defined in TS 33.501 [11] is performed between the AUSF and N5GC device.

Once the N5GC device has been authenticated, the AUSF provides relevant security related information to the AMF. AUSF shall return the SUPI (this SUPI corresponds to a NAI that contains the username of the N5GC device and a realm as defined in TS 33.501 [11]) to AMF only after the authentication is successful.

NOTE: Each N5GC device is registered to 5GC with its own unique SUPI.

6. The AMF performs other registration procedures as required (see TS 23.502 [3] clause 4.2.2.2.2).

When providing a PEI for a N5GC device, the W-AGF shall provide a PEI containing the MAC address of the N5GC device. The W-AGF may, based on operator policy, encode the MAC address of the N5GC device using the IEEE Extended Unique Identifier EUI-64 format (see IEE Publication [41]).

7. The AMF sends Registration Accept message to W-AGF.

Once the registration procedure is completed, the W-AGF requests the establishment of a PDU Session on behalf of the N5GC device. Only one PDU session per N5GC device is supported. The procedure is the same as the PDU Session establishment procedure specified in clause 7.3.4 with the difference as below:

After successful registration, PDU Session establishment/modification/release procedure specified in clause 7.3.4, 7.3.6, and 7.3.7 apply with the difference as below:

– FN-RG is replaced by N5GC device.

The W-AGF shall request the release of the NGAP connection for each N5GC device served by a CRG whose NGAP connection has been released.

5G-CRG behaves as FN-CRG (i.e. L2 bridge mode) when handling N5GC devices.

4.11 Fixed Wireless Access

For the 5G-RG connected to 5GC via NG-RAN the specifications defined TS 23.501 [2], TS 23.502 [3] and TS 23.503 [4] applies with the following modification:

– The UE corresponds to the 5G-RG.

– The 5G-RG may support LTE access connected to EPC and EPC interworking as defined in TS 23.501 [2], clause 5.17. This is controlled by SMF Selection Subscription data defined in Table 5.2.3.3.1-1 of TS 23.502 [3].

– The configuration of 5G-RG via ACS server based on TR-069 [18] and TR-369 [19] is specified clause 9.6.

– The Home Routing roaming is supported for 5G-RG connected via NG RAN in this release.

– 5G Multi-Operator Core Network (5G MOCN) is supported for 5G-RG connected via NG RAN as defined in clause 5.18 of TS 23.501 [2]

– The LBO roaming for 5G-RG connected via NG RAN is not specified in this release.

– The LADN service defined in clause 5.6.5 in TS 23.501 [2] applies to the 5G-RG connected to 5GC via 3GPP access. The specification in clause 5.6.5 in TS 23.501 [2] applies via 5G-RG replacing UE with the following difference:

– UE Configuration Update procedure is referred to the procedures in clause 7.2.3.1.

NOTE 1: HR roaming over 3GPP access is defined for 5G_RG but in some countries it can not apply due to local regulations.

– If the 5G-RG is registered via both 3GPP access and W-5GAN, and the AMF has received W-AGF identities from the AGF, the AMF may provide the W-AGF identities to the SMF also when AMF forwards N1 SM container sent by the 5G-RG via 3GPP access.

NOTE 2: If the SMF receives the W-AGF information also in case of 5G-RG sending a PDU Session Establishment via 3GPP access, based on operator configuration, the SMF can take this into account for selecting a UPF collocated with the W-AGF.

4.12 Hybrid Access

4.12.1 General

This clause specifies the support of Hybrid Access considering both the support of PDU session and MA PDU session.

Hybrid Access applies to a 5G-RG capable of connecting to both NG-RAN and to W-5GAN. Hybrid Access also applies to a 5G-RG capable of connecting to W-5GAN/5GC and E-UTRAN/EPC using EPC interworking architecture. Hybrid Access does not apply to FN-RG.

The following Hybrid Access scenarios are supported with single-access PDU sessions:

– Hybrid Access using PDU session carried only on a single access, either NG-RAN or W-5GAN, but that cannot be simultaneously on both accesses. Such PDU Session can be handed over between NG-RAN and W-5GAN using procedures described in clause 4.9.2 of TS 23.502 [3], but with UE replaced by 5G-RG and N3IWF replaced by W-5GAN.

– Hybrid Access using single access connectivity for 5G-RG supporting LTE/EPC and EPC interworking. In that case mobility between W-5GAN/5GS and E-UTRAN/EPC is handled using interworking procedures described in clause 4.11.3 of TS 23.502 [3], but with UE replaced by 5G-RG and N3IWF replaced by W-5GAN.

The following Hybrid Access scenarios are supported with multi-access connectivity:

— Hybrid Access with Multi-Access PDU Session connectivity over NG-RAN and W-5GAN and operator-controlled traffic steering. This scenario is further detailed in clause 4.12.2.

– Hybrid Access with simultaneous multi-access connectivity to LTE/EPC and W-5GAN/5GS using EPC interworking. This scenario is further detailed in clause 4.12.3.

In this Release of the specification, a RG that supports MA PDU Sessions and LTE/EPC access as described in clause 4.12.2, shall also support MA PDU using LTE/EPC as 3GPP access as defined in clause 4.12.3.

4.12.2 Hybrid Access with Multi-Access PDU Session connectivity over NG-RAN and W-5GAN

This clause applies to the case where multi-access PDU Session connectivity via NG-RAN and W-5GAN is supported in the 5G-RG and network. The Hybrid Access architecture of 5G-RG is defined in TS 23.501 [2] in Figure 4.2.8.4-1. This scenario uses the ATSSS solution described in clause 5.33 of the Release 16 version of TS 23.501 [2], with the following difference:

– UE is replaced by 5G-RG.

– Non-3GPP access(es) is specifically referred to wireline access.

The Release 17, ATSSS functionalities defined in TS 23.501 [2], TS 23.502 [3] and TS 23.503 [4] are not supported, except for the feature described in clause 4.12.3.

4.12.3 Hybrid Access with multi-access connectivity over E-UTRAN/EPC and W-5GAN

4.12.3.1 General

This clause applies to the case where multi-access connectivity via both EPC and 5GC is supported in the 5G-RG and network. In this case, multi-access connectivity using ATSSS via both EPC and 5GC may be provided as described in this clause.

For a 5G-RG, a Multi-Access PDU Session may use user-plane resources of an associated PDN Connection on 3GPP access in EPC. This enables a scenario where a MA PDU Session can simultaneously be associated with user-plane resources on 3GPP access network connected to EPC and W-5GAN connected to 5GC. Such a PDN Connection in EPS would thus be associated with multi-access capability in 5G-RG and PGW-C+SMF.

The feature is supported as defined in clause 5.32 of TS 23.501 [2] (Release 17) and TS 23.502 [3] (Release 17) with following differences:

– UE is replaced by 5G-RG.

– 5G-RG is connected to 5GC via a non-3GPP access corresponding to W-5GAN.

– MA PDU Sessions of Ethernet PDU Session type where the 3GPP access corresponds to E-UTRAN/EPC are not applicable for 5G-RG.

4.12.3.2 Void

4.12.3.3 Void

4.13 Support of FN-RG

FN-RG is a legacy type of residential gateway that does not support N1 signalling and is not 5GC capable. The architecture to support FN-RG is depicted in clause 4.2.8.4 in TS 23.501 [2]. Support for FN-RG connectivity to 5GC is provided by means of W-AGF supporting 5G functionality on behalf of the FN-RG, e.g. UE NAS registration and session management functionality. In particular, the W-AGF supports the following functionality on behalf of the FN-RG:

– Has access to configuration information, as defined in BBF TR-456 [9], WT-457 [10] and CableLabs WR-TR-5WWC-ARCH [27], to be able to serve FN-RGs and to construct AS and NAS messages.

– Acting as end-point of N1 towards AMF, including maintaining CM and RM states and related dynamic information received from 5GC. This also includes support of URSP.

– Mapping between Y5 towards FN-RG and N1/N2 towards 5GC as well as mapping between a Y5 user plane connection and a PDU Session user plane tunnel on N3.

Authentication of FN-RG may be done by the W-AGF, as defined by BBF and Cablelabs. The W-AGF provides an indication on N2 that the FN-RG has been authenticated. The W-AGF also provides a SUCI or a 5G-GUTI as described in TS 23.501 [2].

4.14 Support of slicing

Slicing as defined in TS 23.501 [2] is supported with following clarifications and modifications:

– 5G-RG may receive USRP rules mapping application flows to S-NSSAI (and other 5GC related parameters). For 5G-RG, the detection of application flows may refer to traffic from devices within the customer premises.

NOTE: In this case, even though an URSP rule refers to the IP PDU Session type, Non-IP Traffic descriptors e.g. layer 2 related Traffic descriptors can be used to identify application flows.

– For 5G-RG access over 3GPP access (FWA), slicing is supported as described in TS 23.501 [2].

– For 5G-RG access over Wireline, the Wireline access is assumed to be able to carry slicing information in W-CP together with NAS signalling between the 5G-RG and the W-AGF.

– The W-AGF shall support the same requirements for AMF selection based on slicing request from the UE than defined for N3IWF / TNGF in TS 23.501 [2] clause 5.15.

4.15 Support for IMS services

When FN RG is used, support IMS Emergency sessions without a SUPI are not supported.