Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.316  Word version:   16.3.0

Top   Up   Prev   Next
1…   4…   4.5…   4.7…   5…   6…   7…   7.2.2…   7.2.3…   7.2.4…   7.3…   7.6…   7.7…   8…   9…   10…   A…

 

4.5  QoS model
4.5.0  General overview
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.
Up
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 WT-456 [9].
Up
4.5.1  Wireline access specific 5G QoS parametersWord-p. 15
In addition to the 5G QoS parameters specified in clause 5.7.2 of TS 23.501, the parameters defined in clause 4.5.1.1 and in clause 4.5.1.2 are applicable for the wireline access network related PDU sessions.
4.5.1.1  Total Maximum Bit Rates
For wireline access networks (W-5GAN) that do not provide dynamic resource reservation, the GBR QoS flows cannot be catered for independently of non-GBR flows. In such W-5GANs, the aggregate bitrate need to reflect both GBR and non-GBR flows instead. These reflect the characteristics of the wireline access provided for the 5G-RG or FN-RG.
Each RG is associated with the following aggregate rate limit QoS parameter:
  • per RG Total Maximum Bit Rate (RG-TMBR).
The RG-TMBR limits the aggregate bit rate that can be expected to be provided across all GBR and Non-GBR QoS Flows of a RG. The RG-TMBR is a parameter provided to the W-5GAN by the AMF based on the value of the Subscribed RG-TMBR retrieved from UDM. The RG-TMBR is measured over a TMBR averaging window which is an operator specific value.
In the case of wireline access, the AMF provides W-AGF with Subscribed RG-TMBR in Initial UE context NGAP message (e.g. in registration and Service Request procedures) instead of Subscribed UE-AMBR.
The RG subscription data parameters for RG-TMBR is defined in clause 8.1.1.
Up
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.
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.
Up
4.5.2  QoS model applied to FN-RGWord-p. 16
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.
Up
4.6  User Plane management
4.6.1  General
The management of the user plane follows the description in TS 23.501, clause 5.8 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, clause 5.8.2.2.
In addition to the IP address management features described in TS 23.501, clause 5.8.2.2 the 5GC network functions and RG support the following mechanisms:
  1. 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.
    The details of Prefix Delegation are described in clause 4.6.2.3.
  2. 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 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).
In this clause the RG may correspond either to a 5G RG or to a FN RG;
Up
4.6.2.2  IPv6 Address Allocation using DHCPv6Word-p. 17
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.
Up
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, 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].
Up
4.6.3  Packet Detection RuleWord-p. 18
PDR used to support PDU Sessions for RG follow the specifications in TS 23.501, 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.
Up
4.6.4  Forwarding Action Rule
FAR used to support PDU Sessions for RG follow the specifications in TS 23.501, 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.
Up
4.6.5  Usage Reporting Rule
URR used to support PDU Sessions for RG follow the specifications in TS 23.501, 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, 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.
Up
4.6.6  Usage of N4 to support IPTVWord-p. 19
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.
Up

Up   Top   ToC