The QoS model of TS 23.501, 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.
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 . The mapping of 5QI to W-5GCAN QoS parameters is specified for W-5GCAN in CableLabs WR-TR-5WWC-ARCH .
QFI or other QoS parameters are carried via W-UP to the 5G-CRG as specified in CableLabs WR-TR-5WWC-ARCH .
The QFI and RQI are carried via W-UP to 5G-RG as specified in BBF TR-456 .
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.
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.
IP address allocation is performed as described in TS 23.501, clause 220.127.116.11, with the differences and additions described in this clause.
Stateless IPv6 Address Autoconfiguration applies with the differences described in clause 18.104.22.168.
In addition to the IP address management features described in TS 23.501, clause 22.214.171.124 the 5GC network functions and RG support the following mechanisms:
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 126.96.36.199.
IPv6 Prefix Delegation using DHCPv6 may be supported for allocating additional IPv6 prefixes for a PDU Session.
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, clause 188.8.131.52.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.
In this clause, unless specified otherwise, the RG may correspond either to a 5G RG or to a FN RG.
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. 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 .
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 184.108.40.206) 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.
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.
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, clause 220.127.116.11.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 RFC 3633 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 RFC 3633. 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 RFC 6603.
Stateless IPv6 Address Autoconfiguration applies as described in clause 18.104.22.168.3 of TS 23.501 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 22.214.171.124.3 of TS 23.501.
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.
PDR used to support PDU Sessions for RG follow the specifications in TS 23.501, clause 126.96.36.199.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, IGMPv3 specified in RFC 4604, for MLDv1 specified in RFC 2710 and MLDv2 specified in RFC 4604. 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 are not supported.
FAR used to support PDU Sessions for RG follow the specifications in TS 23.501, clause 188.8.131.52.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 184.108.40.206
"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.
URR used to support PDU Sessions for RG follow the specifications in TS 23.501, clause 220.127.116.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, clause 18.104.22.168.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).
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;
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);
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.