WO2024038110A1 - Surveillance de qualité de service pour de multiples flux de données de service - Google Patents

Surveillance de qualité de service pour de multiples flux de données de service Download PDF

Info

Publication number
WO2024038110A1
WO2024038110A1 PCT/EP2023/072613 EP2023072613W WO2024038110A1 WO 2024038110 A1 WO2024038110 A1 WO 2024038110A1 EP 2023072613 W EP2023072613 W EP 2023072613W WO 2024038110 A1 WO2024038110 A1 WO 2024038110A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
media component
qos
media
monitoring
Prior art date
Application number
PCT/EP2023/072613
Other languages
English (en)
Inventor
Yong Yang
Susana Fernandez Alonso
Ignacio RIVAS MOLINA
Fuencisla Garcia Azorero
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2024038110A1 publication Critical patent/WO2024038110A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/026—Capturing of monitoring data using flow identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management

Definitions

  • [001] Disclosed are embodiments related to quality-of-service (QoS) monitoring.
  • QoS quality-of-service
  • FIG. 1 illustrates an exemplifying wireless communication system 100 represented as a 5G network architecture comprising an Access Network (AN) (e.g., a Radio AN (RAN)) and a Core network (CN) comprising network entities in the form of Network Functions (NFs).
  • AN Access Network
  • CN Core network
  • NFs Network Functions
  • the AN comprises base stations, e.g., such as evolved Node Bs (eNBs) or 5G base stations (gNBs) or similar.
  • eNBs evolved Node Bs
  • gNBs 5G base stations
  • AMF Access and Mobility Management Function
  • the 5G CN NFs include: a User Plane Function (UPF), a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Unified Data Management (UDM), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Policy Control Function (PCF), an Application Function (AF), a NF Repository Function (NRF), and a Network Exposure Function (NEF).
  • UPF User Plane Function
  • NSSF Network Slice Selection Function
  • AUSF Authentication Server Function
  • UDM Unified Data Management
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • PCF Policy Control Function
  • AF Application Function
  • NRF Network Exposure Function
  • a number of 5G core network NFs of different types are typically instantiated per default in the 5G core network, e.g., such as an AMF, a NRF, a PCF and a SMF etc.
  • Other 5G core network NFs may be instantiated as needed and several NFs of the same type can also be instantiated if required, e.g., to distribute load to additional NF(s) of the same type.
  • an NF instance may be seen as an example or a specimen of a certain NF.
  • the terms NF and NF instance are used interchangeably, unless otherwise expressly stated or is apparent from the context in which the terms are used.
  • An NF instance exposes one or more NF Service Instances.
  • Downlink (DL) data packets i.e., packets received at UPF and then transmitted towards the UE are classified by the UPF based on DL Packet Detection Rules (PDRs) received from the SMF in the order of their precedence. That is, once a DL packet is determined by UPF to match a flow description (FD) (a.k.a., filter) included in the PDR, then the packet is bound to a QoS flow associated with the PDR by marking the patent with the QoS Flow Identifier (QFI) that identifies the QoS flow.
  • FD flow description
  • QFI QoS Flow Identifier
  • the AN binds QoS Flows to AN resources (i.e. Data Radio Bearers in the case of 3GPP RAN).
  • the UE evaluates UL packets against UL Packet Filters in a Packet Filter Set in QoS rules based on the precedence value of QoS rules in increasing order until a matching QoS rule (i.e. whose Packet Filter matches the UL packet) is found. If no matching QoS rule is found, the UE shall discard the UL data packet. The UE uses the QFI in the corresponding matching QoS rule to bind the UL packet to a QoS Flow. The UE then binds QoS Flows to AN resources.
  • 3GPP defines a PCC architecture (see e.g., 3GPP Technical Specification TS 23.503 V17.5.0 (“TS 23.503”)).
  • the PCF is a functional element that encompasses policy control decision and flow based charging control functionalities.
  • the PCF provides network control regarding service data flow (SDF) detection, gating, QoS management (including handling of alternative service profiles, QoS notification control, QoS monitoring) and flow based charging (except credit management) towards the SMF.
  • SDF service data flow
  • QoS management including handling of alternative service profiles, QoS notification control, QoS monitoring
  • flow based charging except credit management
  • the PCF receives session related information from the AF, and informs AF of traffic plane events or forwards the event subscription information towards the event reporting function.
  • the PCF authorizes the AF request and creates/updates/deletes the authorized PCC rule(s) that comprise the session related information requested by the AF, as specified in 3GPP TS 29.513 V17.7.0, clause 6.3.
  • the PCF shall provision PCC Rules to the SMF via the N7 reference point.
  • the PCF shall inform the SMF through the use of PCC rules about the treatment of each SDF that is under PCC control, in accordance with the PCF policy decision(s).
  • the SMF/UPF encompasses SDF detection based on the filters definitions included in the PCC rules and policy enforcement.
  • the QoS Monitoring mentioned here corresponds to the QoS Monitoring that is specified in the 3GPP specifications.
  • QoS Monitoring is applied for packet delay measurement.
  • the packet delay between UE and the Protocol Data Unit (PDU) Session Anchor (PSA) UPF is a combination of the RAN part of UL/DL packet delay and UL/DL packet delay between the RAN and UPF.
  • the RAN is required to provide the QoS Monitoring on the RAN part of UL/DL packet delay measurement.
  • the QoS Monitoring on UL/DL packet delay between RAN and UPF can be performed on different levels of granularities, i.e. per QoS Flow per UE level, or per GTP-U path level, subject to the operators' configuration, and/or 3rd party application request, and/or PCF policy control.
  • the PCF generates the authorized QoS Monitoring policy for a SDF based on a QoS Monitoring request if received from an AF.
  • the PCF includes the authorized QoS Monitoring policy in a PCC rule and provides the PCC rule to the SMF, which then provides PDR(s), QER(s), and SRR(s) to the UPF.
  • the QoS Monitoring policy includes the following:
  • [0014] 2 frequency of reporting (event triggered, periodic, when no packet delay measurement result is received for a delay exceeding a threshold, or when the PDU Session is released); if the reporting frequency is event triggered, the policy includes the corresponding reporting threshold to each QoS parameter and minimum waiting time between subsequent reports; else if the reporting frequency is periodic, the policy includes the the reporting period; threshold for reporting packet delay measurement failure;
  • NEF indicated as Notification Target Address + Notification Correlation ID as specified in clause 4.15.1 of 3GPP TS 23.502 V17 4.0 (“TS 23 502”));
  • TS 23.503 specifies how an application may request QoS monitoring for a SDF.
  • the QoS Monitoring for URLLC refers to the real time packet delay measurement between the UE and the UPF for a QoS Flow corresponding to an URLLC service.
  • the PCF generates the authorized QoS Monitoring policy for the SDF based on the QoS Monitoring request if received from the AF.
  • the QoS Monitoring policy includes the following:
  • the PCF includes the authorized QoS Monitoring policy in the PCC rule and provides it to the SMF.
  • SMF may activate the end to end UL/DL packet delay measurement between UE and UPF for a QoS Flow during the PDU Session Establishment or Modification procedure.
  • the SMF sends a QoS Monitoring request to the UPF to request the QoS monitoring between UPF and RAN.
  • the QoS Monitoring request may contain monitoring parameters determined by SMF based on the authorized QoS Monitoring policy received from the PCF and/or local configuration.
  • the RAN initiates the RAN part of UL/DL packet delay measurement based on the QoS Monitoring request from SMF.
  • RAN reports the RAN part of UL/DL packet delay result to the UPF in the UL data packet or dummy UL packet.
  • some real time network information e.g. user path latency
  • the UPF may provide QoS monitoring results to the AF.
  • the UPF may be instructed to report information about a PDU Session directly to the AF or NEF (i.e. , bypassing the SMF and the PCF).
  • NEF deployed at the edge may be used to support network exposure with low latency to AF.
  • AF subscribes to the QoS Monitoring results from the PCF via a NEF.
  • the AF may also subscribe the Npcf_PolicyAuthorization_Subscribe service via PCF directly. In this case, reporting is done directly from the UPF to the local AF.
  • the PCF may include an indication of direct event notification (including target local NEF address or target AF address) within the PCC rule that it provides to the SMF.
  • the SMF sends the QoS monitoring request to the RAN and N4 rules to the UPF.
  • the N4 rules may indicate the SDF needs local notification of QoS Monitoring.
  • the UPF upon the detection of the QoS monitoring event (e.g. when latency threshold of the QoS flow is reached), the UPF notifies the QoS Monitoring event information to the AF (directly or via Local NEF).
  • the UPF sends the Nupf_EventExposure_Notify to the Notification Target Address indicated by the Session Reporting Rule (SRR) received from the SMF.
  • the Notification Target Address may correspond to the AF or to a local NEF.
  • the local NEF reports the QoS Monitoring information to the AF.
  • This service provides events related to PDU Sessions towards consumer NF (e.g., AF or NEF).
  • the service operations exposed by this service allow other NFs to subscribe and get notified of events happening on PDU Sessions.
  • Many events can be subscribed by a NF consumer, including QFI allocation.
  • the QFI allocation event notification is sent when a new QoS flow is established within a PDU session.
  • the event notification contains both the allocated QFI and either one of the following (Application Identifier or IP Packet Filter Set or Ethernet Packet Filter Set).
  • the DNN, S-NSSAI corresponding to the PDU session are also sent.
  • the Target of Event Reporting is a SUPI
  • the event notification contains both the allocated QFI and either one of the following (Application Identifier or IP Packet Filter Set or Ethernet Packet Filter Set) for each PDU session ID established for this SUPI.
  • the DNN, S-NSSAI corresponding to each PDU session are also sent If the Target of Event Reporting is an I nternal-Group-ld or any UE, the event notification contains multiple instances of the tuple (allocated QFI and either one of the following (Application Identifier or IP Packet Filter Set or Ethernet Packet Filter Set). PDU session ID, SUPI). The DNN, S-NSSAI corresponding to each PDU session are also sent.
  • TS 29.514 interprets TS 23.503 as follows: (1) the AF, for an AF session (i.e., for all the SDFs of an AF session) subscribes to QoS monitoring events; and (2) The AF, for all the SDFs of an AF session, sets the same QoS monitoring requirements (i e., frequency of reporting, target of reporting (notification URI + Notification correlation Id), etc.). This interpretation creates two problems.
  • NF e.g., AF or NEF
  • the method includes transmitting to a policy function (e.g., a PCF) a monitoring notification request (e.g., an AF request).
  • a policy function e.g., a PCF
  • a monitoring notification request e.g., an AF request
  • the monitoring notification request comprises: i) a first media data structure corresponding to a first media component (e.g., media subcomponent - i.e., the first media data structure may be of type MediaSubComponent as defined in 3GPP TS 29.514 table 5.6.2.8-1); ii) a second media data structure corresponding to a second media component; and iii) first QoS monitoring information (e.g., this corresponds to the QosMonitoringPerSdf data structure) comprising: i) first QoS requirement information indicating a first QoS requirement and ii) first media component information indicating that the first QoS requirement applies at least to the first media component and/or the second media component.
  • a first media data structure corresponding to a first media component e.g., media subcomponent - i.e., the first media data structure may be of type MediaSubComponent as defined in 3GPP TS 29.514 table 5.6.2.8-1
  • the monitoring notification request comprises: A) a first media data structure corresponding to a first media component (e.g., a first media subcomponent), the first media data structure comprising: i) a first flow number indicating an ordinal number for the first media component; ii) first flow description information (e.g., array of FlowDescriptions and/or array of Eth FlowDescriptions) that defines a first set of one or more flows (e.g., an UL IP flow, a DL IP flow, an UL Ethernet flow, and/or a DL Ethernet flow), and iii) a first monitoring correlation identifier (MCI) (e.g., monCorrelationld); and B) a second media data structure corresponding to a second media component, the second media data structure comprising: i) a second flow number indicating an ordinal number for the second media component; ii) second flow description information that defines a second set of one or more flows, and iii)
  • MCI monitoring correlation
  • a method performed by a policy function includes receiving from a network function (NF) a monitoring notification request (e.g., an AF request).
  • the monitoring notification request comprises: i) a first media data structure corresponding to a first media component (e.g., media subcomponent); ii) a second media data structure corresponding to a second media component; and iii) first QoS monitoring information comprising: i) first QoS requirement information indicating a first QoS requirement and ii) first media component information indicating that the first QoS requirement applies at least to the first media component and/or the second media component.
  • NF network function
  • a monitoring notification request comprises: i) a first media data structure corresponding to a first media component (e.g., media subcomponent); ii) a second media data structure corresponding to a second media component; and iii) first QoS monitoring information comprising: i) first QoS requirement information indicating a first QoS requirement and
  • a computer program comprising instructions which when executed by processing circuitry of a network node causes the network node to perform any one of the methods disclosed herein.
  • a carrier containing the computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.
  • a network node where the network node is configured to perform any one of the methods disclosed herein.
  • the network node includes processing circuitry and a memory containing instructions executable by the processing circuitry, whereby the network node is configured to perform any one of the methods disclosed herein.
  • An advantage of the embodiments disclosed herein is that they enable differentiation of the different media components (e.g., media subcomponents) of a service that share the same QoS monitoring requirements in a lighter way than reporting the different FDs for the different media components. Moreover, the embodiments enable an entity (e.g., AF) to specify different QoS monitoring requirements per media component. This solution also allows to specify a different notification correlation identifier per media component granularity.
  • FIG. 1 illustrates an exemplifying wireless communication system.
  • FIG. 2 illustrates binding packets to QoS Flows.
  • FIG. 3 is a message flow diagram illustrating a message flow according to an embodiment.
  • FIG. 4 is a flowchart illustrating a process according to an embodiment.
  • FIG. 5 is a flowchart illustrating a process according to an embodiment.
  • FIG. 6 illustrates a network node according to an embodiment.
  • an AF for each SDF of a session that requires the same network treatment as another flow of the session, includes in data structure for the SDF (e.g., a media subcomponent data structure) a monitoring correlation identifier (MCI) (a.k.a., monCorrelationld) that functions as an index to the flows that require the same network treatment.
  • MCI monitoring correlation identifier
  • the scope of the allocated MCls are per AF session (i.e., per notification correlation Id + Notification URI).
  • this disclosure proposes that the AF includes within the monitoring notification request (e.g., AF Request) one or more QoS monitoring information elements, wherein each QoS monitoring information element indicates the different SDFs to which it applies and includes a different notification correlation ID.
  • the monitoring notification request e.g., AF Request
  • each QoS monitoring information element indicates the different SDFs to which it applies and includes a different notification correlation ID.
  • the AF request specified in TS 29.514 is extended. More specifically, the MediaSubcomponent data type is updated to include the monitoring correlation identifier (monCorrelationld).
  • type MediaSubComponent is as shown in Table 1 below.
  • the EventsSubscReqData data type is updated to include the possibility to subscribe to QoS monitoring reports per media component/subcomponent.
  • a new attribute qosMonPerSdfs gathers the QoS monitoring requirements per SDF (media subcomponent). This attribute is an array of a new data type QosMonitoringPerSdf. This new data type indicates the SDF(s) (media subcomponents within a media component) that share the same QoS monitoring requirements.
  • the Notification Item specified in 3GPP TS 29.544 V17.1.0 is extended.
  • the Notificationitem data type is updated to include the monitoring correlation identifier (monCorrelationld).
  • type Notificationitem is as shown in Table 5 below.
  • FIG. 3 illustrates a message flow illustrating a process according to a 5G embodiment.
  • the process begins with a network function (NF) 302 (e.g., AF or NEF) invoking the Npcf_PolicyAuthorization service to create an application session (e.g., an AF session).
  • NF network function
  • the NF 302 may be triggered to invoke this service in response to a user equipment (UE) requesting a service supported by the NF.
  • UE user equipment
  • Invoking the Npcf_PolicyAuthorization service comprises the NF transmitting to PCF 304 a monitoring notification request message 351 (e.g., an HTTP message) that includes: i) a first media data structure (e.g., data structure of type MediaSubComponent) corresponding to a first media component (e.g., media subcomponent), ii) a second media data structure corresponding to a second media component, and iii) event subscription information for subscribing to QoS monitoring of the first and second media components (e.g., data structure of type EventsSubscReqData), which event subscription information comprises event information indicating one or more subscribed events for the first and second media components, a notification URI (i.e., address information (e.g., IP address or domain name) indicating the address to which notifications should be sent), and QoS monitoring information (e g., a data structure of type QosMonitoringPerSdf), which includes a notification correlation identifier to be
  • the first media data structure corresponding to the first media component comprises a first flow description (e.g., a flow description for an Ethernet flow and/or a flow description for an IP flow) and a first MCI
  • the second media data structure corresponding to the second media component comprises a second flow description and a second MCI.
  • the second MCI may be the same MCI as the first MCI or it may have a different value.
  • the event subscription information comprises: i) first QoS monitoring information (e.g., a data structure of type QosMonitoringPerSdf) for subscribing to QoS information pertaining to the first media component and ii) second QoS monitoring information for subscribing to QoS information pertaining to the second media component.
  • the first QoS monitoring information includes: i) first QoS requirement information indicating a first QoS requirement, ii) media component information indicating that the first QoS requirement applies to the first media component, and iii) a first notification correlation ID.
  • the second QoS monitoring information includes: i) second QoS requirement information indicating a second QoS requirement, ii) media component information indicating that the second QoS requirement applies to the second media component, and iii) a second notification correlation ID that is different than the first notification correlation ID.
  • the PCF After receiving the message 351 from the NF, the PCF creates one or more PCC rules with a reference to QoS monitoring data as requested including the notification URI. The PCF then invokes a Npcf_SMFPol icyControl Service (e.g. , Npcf_SMPolicyControl_UpdateNotify) . That is, the PCF then sends to an SMF 306 a message 352 comprising the PCC rule(s).
  • Npcf_SMFPol icyControl Service e.g. , Npcf_SMPolicyControl_UpdateNotify
  • first PCC rule corresponding to the first QoS monitoring information and a second PCC rule corresponding to the second QoS monitoring information, where the first PCC rule includes the first MCI and related QoS monitoring information and the second PCC rules includes the second MCI and related QoS monitoring information.
  • the monitoring notification request message 351 includes a third media data structure corresponding to a third media component and having a third flow description, and the third media data structure contains the same MCI as the first media data structure, then the first PCC rule includes the first flow description and the third flow description.
  • the SMF After receiving message 352, the SMF, based on the PCC rule(s) which contains QoS monitoring request, the SMF creates the corresponding PDR(s), QER(s), and SRR(s), where each PDR contains the packet detection information that includes one of the FDs, and associates the PDR(s) with the corresponding QER(s), where each QER defines a separate QoS flow (each QoS flow being identified by a QFI). Each SRR includes one of the QFIs as well as the notification URI and a notification correlation id. The SMF then requests a UPF 308 to perform QoS monitoring by providing to the UPF the PDR(s), QER(s), and SRR(s).
  • the SMF sends to the UPF a PFCP Session Modification request message 353 containing the PDR(s), QER(s), and SRR(s). Because an SRR includes a QFI, UPF is able to determine the QoS flow (QER) corresponding to the SRR (i.e., the QER that contains said QFI), and because this QER is associated with a single PDR, the UPF is able to obtain the FD associated with the QoS Flow being monitored.
  • QER QoS flow
  • the UPF After receiving the message 353 from the SMF, the UPF performs QoS monitoring for the given QoS Flows identified by the QFIs in the SRRs received from the SMF
  • the UPF when the UPF receives a DL packet, the UPF will, for one or more of the PDRs that it received from the SMF in message 353, determine whether the packet matches the PDR based on a packet filter (e.g., FD) included in the PDR.
  • a packet filter e.g., FD
  • the UPF When UPF detects that the DL packet matches a PDR, the UPF will get the QFI associated with the matching PDR (e.g., it may get the QFI from the QER associated with the matching PDR). After getting the QFI, the UPF will determine whether there is an SRR that contains the QFI, and, if there is, the UPF will perform QoS monitoring as directed by the SRR, which may contain an MCI (monCorrelationld).
  • the UPF may determine a packet round-trip time by recording the time at which it transmits the DL packet to the access network (An) and recording the time that it receives from the AN a packet corresponding to the DL packet. By recording these times, UPF can calculate a round-trip time.
  • the SSR containing the QFI associated with the PDR that the DL matched configures the UPF such that, as a result of UPF detecting an event (e.g., determining that the round-trip time (or a calculated average round-trip time) exceeds a threshold), the UPF sends a notification message 354 comprising a notification item (e.g., of type Notificationitem defined above) related to the detected event (this notification message 354 may be sent directly to the NF 302 or it may be sent to the PCF or SMF, which will then forward the notification item(s) included in the notification message to the NF).
  • a notification item e.g., of type Notificationitem defined above
  • the UPF sends the notification message 354 to the address indicated in the notification URI included in the SRR, and the notification message 354 also contains the notification correlation ID included in the SRR as well as the monCorrelationlD, if any, included in the SRR.
  • the NF correlates the received QoS monitoring reports with the affected media components based on the received monitoring correlation Identifier.
  • FIG. 4 is a flowchart illustrating a process 400 according to an embodiment.
  • Process 400 is performed by an NF (e.g , AF or NEF) and may begin in step s402.
  • Step s402 comprises generating a monitoring notification request (e.g , request 351).
  • Step s404 compries transmitting the monitoring notification request to a policy function (e.g., PCF).
  • NF e.g , AF or NEF
  • PCF policy function
  • the monitoring notification request comprises: a first media data structure corresponding to a first media component (e.g., media subcomponent); a second media data structure corresponding to a second media component; and first quality-of-service, QoS, monitoring information comprising: i) first QoS requirement information indicating a first QoS requirement and ii) first media component information indicating that the first QoS requirement applies at least to the first media component and/or the second media component.
  • a first media data structure corresponding to a first media component e.g., media subcomponent
  • second media data structure corresponding to a second media component
  • first quality-of-service, QoS monitoring information comprising: i) first QoS requirement information indicating a first QoS requirement and ii) first media component information indicating that the first QoS requirement applies at least to the first media component and/or the second media component.
  • the monitoring notification request comprises: A) a first media data structure corresponding to a first media component, the first media data structure comprising: i) a first flow number indicating an ordinal number for the first media component; ii) first flow description information (e.g., array of FlowDescriptions and/or array of EthFlowDescriptions) that defines a first set of one or more flows (e.g., an UL IP flow, a DL IP flow, an UL Ethernet flow, and/or a DL Ethernet flow), and Hi) a first monitoring correlation identifier (MCI) (e.g., monCorrelationld); and B) a second media data structure corresponding to a second media component, the second media data structure comprising: i) a second flow number indicating an ordinal number for the second media component; ii) second flow description information that defines a second set of one or more flows, and ill) a second MCI.
  • MCI monitoring correlation identifier
  • FIG. 5 is a flowchart illustrating a process 500 according to an embodiment.
  • Process 500 is performed by policy function (e.g., PCF) and may begin in step s502.
  • Step s502 comprises receiving from an NF a monitoring notification request (e.g., an AF request).
  • the monitoring notification request comprises: a first media data structure corresponding to a first media component (e.g., media subcomponent); a second media data structure corresponding to a second media component; and first quality-of-service, QoS, monitoring information comprising: i) first QoS requirement information indicating a first QoS requirement and ii) first media component information indicating that the first QoS requirement applies at least to the first media component and/or the second media component.
  • the fist media component information indicates that the first QoS requirement applies to both the first media component and the second media component
  • the first media data structure comprises a monitoring correlation identifier
  • MCI monitoring correlation identifier
  • the second media data structure comprises said MCI
  • the first media component information indicating that the first QoS requirement applies to both the first media component and the second media component comprises said MCI.
  • the first media component information indicates that the first QoS requirement applies to both the first media component and the second media component
  • the first media data structure comprises a first monitoring correlation identifier, MCI, identifying the first media component
  • the second media data structure comprises a second MCI identifying the second media component
  • the first media component information indicating that the first QoS requirement applies to both the first media component and the second media component comprises said first MCI and said second MCI.
  • the first QoS requirement information comprises one or more of: information indicating a requested QoS monitoring parameter to be measured (e.g., information indicating that DL, UL and/or round trip packet delay should be measured); and/or QoS threshold information (e.g., a delay threshold for downlink; a delay threshold for uplink; and/or a delay threshold for round trip).
  • the QoS threshold information may be a data structure of type QosMonitoringlnformation as defined in clause 5.6.2.34 of TS 29.514.
  • the information indicating a requested QoS monitoring parameter to be measured may be a data structure of type RequestedQosMonitoringParameter as defined in clause 5.6.2.34 of TS 29.514.
  • the first QoS monitoring information further comprises a notification correlation ID for identifying the subscribed QoS information
  • the first media component information indicates that the first QoS requirement does not apply to the second media component
  • the monitoring notification request further comprises second QoS monitoring information comprising: i) second QoS requirement information indicating a second QoS requirement and ii) second media component information indicating that the second QoS requirement applies to the second media component.
  • the monitoring notification request further comprises a third media data structure corresponding to a third media component
  • the second media component information further indicates that the second QoS requirement applies to the third media component
  • the monitoring notification request further comprises event subscription information (e.g., an EventsSubscReqData data structure), and the event subscription information comprises: the first QoS monitoring information, the second QoS monitoring information, information identifying a subscribed event, and an address (e.g., IP address, domain name) to which notifications pertaining to the event are to be sent.
  • the event subscription information may further include a single notification correlation ID that applies to both the first QoS monitoring information and the second QoS monitoring information, or the first QoS monitoring information may include a single notification correlation ID specific to the first QoS monitoring information and the second QoS monitoring information may include a single notification correlation ID specific to the second QoS monitoring information.
  • process 500 also includes, after receiving the monitoring notification request, generating i) a first policy rule for the first media component and ii) a second policy rule for the second media component; and providing the first and second policy rules to a management function (e.g., SMF).
  • a management function e.g., SMF.
  • the fist media component information indicates that the first QoS requirement applies to both the first media component and the second media component
  • the first policy rule further comprises the first QoS requirement information
  • the second policy rule further comprises the first QoS requirement information.
  • the first media data structure corresponding to the first media component comprises first service data flow, SDF, information identifying at least a first flow (e.g., an UL FlowDescription and/or a DL FlowDescription), the second media data structure corresponding to the second media component comprises second service data flow information identifying at least a second flow, the first policy rule further comprises the first SDF information, and the second policy rule further comprises the second SDF information.
  • first service data flow e.g., an UL FlowDescription and/or a DL FlowDescription
  • the second media data structure corresponding to the second media component comprises second service data flow information identifying at least a second flow
  • the first policy rule further comprises the first SDF information
  • the second policy rule further comprises the second SDF information.
  • FIG. 6 is a block diagram of a network node 600, according to some embodiments, which can be used to implement any of the network functions (NFs) disclosed herein (e.g., AF, NEF, PCF, SMF, UPF).
  • NFs network functions
  • network node 600 may run (or execute a virtual machine that runs) the NF. As shown in FIG.
  • network node 600 may comprise: processing circuitry (PC) 602, which may include one or more processors (P) 655 (e.g., one or more general purpose microprocessors and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., network node 600 may be a distributed computing apparatus); at least one network interface 648 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 645 and a receiver (Rx) 647 for enabling network node 600 to transmit data to and receive data from other nodes connected to a network 110 (e.g., an Internet Protocol (IP) network) to which network interface 648 is connected (physically or wirelessly) (e.g., network interface 648 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node 600 to wirelessly
  • a computer readable storage medium (CRSM) 642 may be provided.
  • CRSM 642 may store a computer program (CP) 643 comprising computer readable instructions (CRI) 644.
  • CP computer program
  • CRI computer readable instructions
  • CRSM 642 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like.
  • the CRI 644 of computer program 643 is configured such that when executed by PC 602, the CRI causes network node 600 to perform steps described herein (e.g., steps described herein with reference to the flow charts).
  • network node 600 may be configured to perform steps described herein without the need for code. That is, for example, PC 602 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.
  • the first media component information indicates that the first QoS requirement applies to both the first media component and the second media component
  • the first media data structure comprises a first monitoring correlation identifier, MCI, identifying the first media component
  • the second media data structure comprises a second MCI identifying the second media component
  • the first media component information indicating that the first QoS requirement applies to both the first media component and the second media component comprises said first MCI and said second MCI.
  • the first QoS requirement information comprises one or more of: information indicating a requested QoS monitoring parameter to be measured (e.g., information indicating that DL, UL and/or round trip packet delay should be measured); and/or
  • QoS threshold information e.g., a delay threshold for downlink; a delay threshold for uplink; and/or a delay threshold for round trip.
  • AA5 The method of any one of embodiments AA1-AA4, wherein the first QoS monitoring information further comprises a notification correlation ID for identifying the subscribed QoS information
  • AA6 The method of any one of embodiments AA1 -AA5, wherein the first media component information indicates that the first QoS requirement does not apply to the second media component, and the monitoring notification request further comprises second QoS monitoring information comprising: i) second QoS requirement information indicating a second QoS requirement and ii) second media component information indicating that the second QoS requirement applies to the second media component.
  • the monitoring notification request further comprises a third media data structure corresponding to a third media component, and the second media component information further indicates that the second QoS requirement applies to the third media component.
  • the monitoring notification request further comprises event subscription information (e.g., an EventsSubscReqData data structure), and the event subscription information comprises: the first QoS monitoring information, the second QoS monitoring information, information identifying a subscribed event, and an address (e.g., IP address, domain name) to which notifications pertaining to the event are to be sent.
  • event subscription information e.g., an EventsSubscReqData data structure
  • the event subscription information comprises: the first QoS monitoring information, the second QoS monitoring information, information identifying a subscribed event, and an address (e.g., IP address, domain name) to which notifications pertaining to the event are to be sent.
  • the monitoring notification request further comprises event subscription information (e.g., EventsSubscReqData data structure) comprising event information indicating one or more subscribed events for the first and second media components.
  • event subscription information e.g., EventsSubscReqData data structure
  • AB3 The method of embodiment AB1 or AB2, further comprising: receiving a first notification comprising: i) first Quality-of-Service, QoS, reporting information pertaining to the first media component and ii) the first MCI; and receiving a second notification comprising: i) second QoS reporting information pertaining to the second media component and ii) the second MCI.
  • the monitoring notification request further comprises event subscription information (e.g., EventsSubscReqData data structure) comprising event information indicating one or more subscribed events for the first and second media components and a first notification correlation identifier
  • event subscription information e.g., EventsSubscReqData data structure
  • the first notification further comprises the first notification correlation identifier
  • the second notification further comprises the first notification correlation identifier.
  • the monitoring notification request further comprises event subscription information (e.g., EventsSubscReqData data structure) comprising event information indicating one or more subscribed events for the first and second media components and further comprising: a) first QoS monitoring information (e.g., this corresponds to the QosMonitoringPerSdf data structure) for the first media component, the first QoS monitoring information comprising: first QoS requirement information indicating a first QoS requirement, and a first notification correlation identifier; and b) second QoS monitoring information for the second media component, the second QoS monitoring information comprising: second QoS requirement information indicating a second QoS requirement, and a second notification correlation identifier.
  • event subscription information e.g., EventsSubscReqData data structure
  • first QoS monitoring information e.g., this corresponds to the QosMonitoringPerSdf data structure
  • the second QoS monitoring information comprising: second QoS requirement information indicating a second Qo
  • receiving the first and second notifications comprises receiving a notification request message comprising the first notification and the second notification.
  • receiving the second notification comprises receiving a second notification request message comprising the second notification
  • a monitoring notification request e.g., an AF request
  • the monitoring notification request comprises: a first media data structure corresponding to a first media component (e.g., media subcomponent); a second media data structure corresponding to a second media component; and first quality-of-service, QoS, monitoring information comprising
  • the first media component information indicates that the first QoS requirement applies to both the first media component and the second media component
  • the first media data structure comprises a first monitoring correlation identifier, MCI, identifying the first media component
  • the second media data structure comprises a second MCI identifying the second media component
  • the first media component information indicating that the first QoS requirement applies to both the first media component and the second media component comprises said first MCI and said second MCI
  • the first QoS requirement information comprises one or more of: information indicating a requested QoS monitoring parameter to be measured (e.g., information indicating that DL, UL and/or round trip packet delay should be measured); and/or
  • QoS threshold information e.g., a delay threshold for downlink; a delay threshold for uplink; and/or a delay threshold for round trip.
  • the monitoring notification request further comprises second QoS monitoring information comprising: i) second QoS requirement information indicating a second QoS requirement and ii) second media component information indicating that the second QoS requirement applies to the second media component.
  • monitoring notification request further comprises a third media data structure corresponding to a third media component
  • second media component information further indicates that the second QoS requirement applies to the third media component
  • the monitoring notification request further comprises event subscription information (e.g., an EventsSubscReqData data structure), and the event subscription information comprises: the first QoS monitoring information, the second QoS monitoring information, information identifying a subscribed event, and an address (e.g , IP address, domain name) to which notifications pertaining to the event are to be sent.
  • event subscription information e.g., an EventsSubscReqData data structure
  • the event subscription information comprises: the first QoS monitoring information, the second QoS monitoring information, information identifying a subscribed event, and an address (e.g , IP address, domain name) to which notifications pertaining to the event are to be sent.
  • the first media data structure corresponding to the first media component comprises first service data flow, SDF, information identifying at least a first flow (e.g., an UL FlowDescription and/or a DL FlowDescription),
  • the second media data structure corresponding to the second media component comprises second service data flow information identifying at least a second flow
  • the first policy rule further comprises the first SDF information
  • the second policy rule further comprises the second SDF information.
  • a computer program (643) comprising instructions (644) which when executed by processing circuitry (655) of a network node (600) causes the network node to perform the method of any one of the above embodiments.
  • the PCF may generate separate PCC rules per media subcomponent.
  • the notification correlation identifier included within the QoS monitoring request might not be enough.
  • the NEF/AF correlates the reports received from the different PCC rules/QoS flows resulting of the same AF request, it is proposed to use the "monCorrelationld” attribute (or alternatively denoted “flowCorrelationl D” attribute), so that the AF request includes it with different values for flows with different network treatment requirement (different values per media subcomponent).
  • This procedure is used to set up an AF application session context for the service as defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4],
  • FIG.2.2.2-1 illustrates the initial provisioning of service information.
  • the NF service consumer shall invoke the Npcf_PolicyAuthorization_Create service operation by sending the HTTP POST request to the resource URI representing the "Application Sessions" collection resource of the PCF, as shown in figure 4.2.2.2- 1, step 1.
  • the NF service consumer shall include in the "AppSessionContext” data type in the payload body of the HTTP POST request a partial representation of the "Individual Application Session Context” resource by providing the "AppSessionContextReqData” data type.
  • the "Individual Application Session Context” resource and the "Events Subscription” sub-resource are created as described below.
  • the NF service consumer shall provide in the body of the HTTP POST request: for IP type PDU sessions, the IP address (IPv4 or IPv6) of the UE in the "uelpv4" or "uelpv6" attribute; and for Ethernet type PDU sessions, the MAC address of the UE in the "ueMac” attribute.
  • the IP address of the PDU session is used as identifier of the PDU session related to the reported TSC user plane node information.
  • the NF service consumer shall provide the corresponding service information in the "medComponents" attribute if available.
  • the AF shall indicate to the PCF as part of the "medComponents” attribute whether the service data flow(s) (IP or Ethernet) should be enabled or disabled with the "fStatus” attribute.
  • the service data flow(s) filter(s) are encoded within the "medSubComps" array, where each UL and/or DL flow filter(s) are encoded within a MediaSubComponent entry.
  • the NF service consumer may includedine in each MediaSubcomponent entry the "sdfCorrelationld” attribute, set to different values for each media subcomponents of the AF session that require the same QoS monitoring handling.
  • the AF may provide within the MediaComponent data structure required QoS information as specified in clause 4.2.2.32.
  • the AF may include the AF application identifier in the "afAppid" attribute into the body of the HTTP POST request in order to indicate the particular service that the AF session belongs to.
  • the AF application identifier may be provided at both "AppSessionContextReqData” data type level, and "MediaComponent” data type level. When provided at both levels, the AF application identifier provided at "MediaComponent” data type level shall have precedence.
  • the AF application identifier at the "AppSessionContextReqData" data type level may be used to trigger the PCF to indicate to the SMF/UPF to perform the application detection based on the operator's policy as defined in 3GPP TS 29.512 [8],
  • the NF service consumer may include the AF charging identifier in the "afChargld” attribute for charging correlation purposes.
  • the NF service consumer may provide TSC information as specified in clauses 4.2.2.24 and 4.2.2.25.
  • the NF service consumer may also include the "evSubsc” attribute of "EventsSubscReqData” data type to request the notification of certain user plane events.
  • the NF service consumer shall include the events to subscribe to in the "events” attribute, and the notification URI where to address the Npcf_PolicyAuthorization_Notify service operation in the "notifllri” attribute.
  • the events subscription is provisioned in the "Events Subscription" sub-resource.
  • the AF shall also include the "notifllri" attribute in the "AppSessionContextReqData” data type to indicate the URI where the PCF can request to the AF the deletion of the "Individual Application Session Context” resource.
  • the PCF shall send the HTTP error response as specified in clause 5.7.
  • the PCF shall apply session binding as described in 3GPP TS 29.513 [7],
  • the NF service consumer shall provide in the body of the HTTP POST request: for IP type PDU session, either the "uelpv4" attribute or "uelpv6" attribute containing the IPv4 or the IPv6 address applicable to an IP flow or IP flows towards the UE; and for Ethernet type PDU session, the "ueMac" attribute containing the UE MAC address applicable to an Ethernet flow or Ethernet flows towards the UE.
  • the NF service consumer may provide DNN in the "dnn” attribute, SUPI in the “supi” attribute, GPSI in the "gpsi” attribute, the S-NSSAI in the "sliceinfo” attribute if available for session binding.
  • the NF service consumer may also provide the domain identity in the "ipDomain” attribute.
  • the "ipDomain" attribute is helpful in the following scenario: Within a network slice, there are several separate IP address domains, with SMF/UPF(s) that allocate I pv4 IP addresses out of the same private address range to UE PDU sessions. The same IP address can thus be allocated to UE PDU sessions served by SMF/UPF(s) in different address domains. If one PCF controls several SMF/UPF(s) in different IP address domains, the UE IP address is thus not sufficient for the session binding.
  • a NF service consumer can serve UEs in different IP address domains, either by having direct IP interfaces to those domains, or by having interconnections via NATs in the user plane between the UPF and the NF service consumer.
  • the NF service consumer obtains the IP address allocated to the UE PDU session via application level signalling and supplies it for the session binding to the PCF in the "uelpv4" attribute.
  • the NF service consumer supplies an "ipDomain” attribute denoting the IP address domain behind the NAT in addition.
  • the NF service consumer can derive the appropriate value from the source address (allocated by the NAT) of incoming user plane packets.
  • the value provided in the "ipDomain" attribute is operator configurable.
  • the "sliceinfo" attribute is helpful in the scenario where multiple network slices are deployed in the same DNN, and the same IPv4 address may be allocated to UE PDU sessions in different network slices. If one PCF controls several network slices, the UE IP address is not sufficient for the session binding.
  • the NF service consumer supplies "sliceinfo" attribute denoting the network slice that allocated the IPv4 address of the UE PDU session. How the NF service consumer derives S-NSSAI is out of the scope of this specification.
  • the PCF shall reject the Npcf_PolicyAuthorization_Create service operation with an HTTP ”500 Internal Server Error” response including the "cause” attribute set to "PDU_SESSION_NOT_AVAILABLE".
  • the PCF shall store the received service information.
  • the PCF shall process the received service information according to the operator policy and may decide whether the request is accepted or not.
  • the PCF may take the priority information within the "resPrio" attribute into account when making this decision.
  • the PCF shall indicate in an HTTP "403 Forbidden” response message the cause for the rejection including the "cause” attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED".
  • the PCF shall reject the request with an HTTP "403 Forbidden” response including the "cause” attribute set to "TEMPORARY_NETWORK_FAILURE".
  • the PCF may include in the "403 Forbidden” response the "cause” attribute set to "REQUESTED_SERVICE_TEMPORARILY_NOT_AUTHORIZED".
  • the PCF may also provide a retry interval within the "Retry-After” HTTP header field.
  • the NF service consumer When the NF service consumer receives the retry interval within the "Retry- After” HTTP header field, the NF service consumer shall not send the same service information to the PCF again (for the same application session context) until the retry interval has elapsed.
  • the "Retry-After" HTTP header is described in 3GPP TS 29.500 [5] clause 5.2.2.2.
  • the PCF may additionally provide the acceptable bandwidth within the attribute "acceptableServInfo" included in the "ExtendedProblemDetails” data structure returned in the rejection response message.
  • the NF service consumer shall supply: for IP type PDU session, both source and destination IP addresses and port numbers in the "fDescs" attribute within the "medSubComps” attribute, if such information is available; and for Ethernet type PDU session, the Ethernet Packet filters in the "ethfDescs" attribute within the "medSubComps” attribute, if such information is available.
  • the NF service consumer may specify the ToS traffic class within the "tosTrCI” attribute for the described service data flows together with the "fDescs” attribute.
  • the NF service consumer may include the "resPrio" attribute at the "AppSessionContextReqData” data type level to assign a priority to the AF Session as well as include the "resPrio” attribute at the "MediaComponent” data type level to assign a priority to the service data flow.
  • the presence of the "resPrio” attribute in both levels does not constitute a conflict as they each represent different types of priority.
  • the reservation priority at the "AppSessionContextReqData” data type level provides the relative priority for an AF session while the reservation priority at the "MediaComponent” data type level provides the relative priority for a service data flow within a session. If the "resPrio" attribute is not specified, the requested priority is PRIO_1 .
  • the PCF shall check whether the received service information requires PCC rules to be created and provisioned as specified in 3GPP TS 29.513 [7], Provisioning of PCC rules to the SMF shall be carried out as specified at 3GPP TS 29.512 [8],
  • the PCF may create a subscription to event notifications for a related PDU session from the SMF, as described in 3GPP TS 29.512 [8], If the PCF created an "Individual Application Session Context" resource, the PCF shall send to the NF service consumer a "201 Created” response to the HTTP POST request, as shown in figure 4.2.2.2-1 , step 2.
  • the PCF shall include in the "201 Created” response: a Location header field; and an "AppSessionContext" data type in the payload body
  • the Location header field shall contain the URI of the created individual application session context resource i.e. " ⁇ apiRoot ⁇ /npcf-policyauthorization/v1/app-sessions/ ⁇ appSessionld ⁇ ".
  • the NF service consumer shall build the subresource URI by adding the path segment "/events-subscription" at the end of the URI path received in the Location header field.
  • the "AppSessionContext" data type payload body shall contain the representation of the created “Individual Application Session Context” resource and may include the "Events Subscription” sub-resource.
  • the PCF shall include in the "evsNotif” attribute: if the NF service consumer subscribed to the event "PLMN_CHG" in the HTTP POST request, the "event” attribute set to "PLMN_CHG” and the "plmnld” attribute including the PLMN Identifier or the SNPN Identifier if the PCF has previously requested to be updated with this information in the SMF;
  • the SNPN Identifier consists of the PLMN Identifier and the NID. if the NF service consumer subscribed to the event "ACCESS_TYPE_CHANGE” in the HTTP POST request, the "event” attribute set to "ACCESS_TYPE_CHANGE” and: i. the "accessType” attribute including the access type, and the “ratType” attribute including the RAT type when applicable for the notified access type; and ii. if the "ATSSS" feature is supported, the "addAccessinfo” attribute with the additional access type information if available, where the access type is encoded in the "accessType” attribute, and the RAT type is encoded in the "ratType” attribute when applicable for the notified access type; and
  • the PCF includes the "accessType” attribute and the "ratType” attribute with a currently active combination of access type and RAT type (if applicable for the notifed access type).
  • the PCF includes the information corresponding to the 3GPP access. iii.
  • the NF service consumer subscription to other specific events using the Npcf_PolicyAuthorization_Create request is described in the related clauses. Notification of events when the applicable information is not available in the PCF when receiving the Npcf_PolicyAuthorization_Create request is described in clause 4.2.5.
  • the acknowledgement towards the NF service consumer should take place before or in parallel with any required PCC rule provisioning towards the SMF.
  • This procedure is used to modify an existing application session context as defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4] when the feature "PatchCorrection" is supported.
  • FIG.2.3.2-1 illustrates the modification of service information using HTTP PATCH method.
  • the NF service consumer may modify the application session context information at any time (e.g. due to an AF session modification or internal NF service consumer trigger) and invoke the Npcf_PolicyAuthorization_Update service operation by sending the HTTP PATCH request message to the resource URI representing the "Individual Application Session Context" resource, as shown in figure 4.2.3.2-1, step 1 , with the modifications to apply.
  • the JSON body within the PATCH request shall include the "AppSessionContextUpdateDataPatch” data type and shall be encoded according to "JSON Merge Patch”, as defined in IETF RFC 7396 [21], The modifications to apply are encoded within the attributes of the "ascReqData” attribute, as described below and in subsequent clauses.
  • the NF service consumer may include the updated service information in the "medComponents" attribute of the "ascReqData” attribute. If the "AuthorizationWithRequiredQoS" feature as defined in clause 5.8 is supported, the NF service consumer may provide within the MediaComponentRm data structure an update of the required QoS information as specified in clause 4.2.3.30.
  • the NF service consumer may include in the "ascReqData” attribute an AF application identifier in the "afAppid” attribute to trigger the PCF to indicate to the SMF/UPF to perform the application detection based on the operator's policy as defined in 3GPP TS 29.512 [8],
  • the NF service consumer may provide TSC user plane node related information as specified in clauses 4.2.3.24 and 4.2.3.25.
  • the NF service consumer may include the "sdfCorrelationl d" attribute set to different values for each of the media subcomponents of the AF session that require the same QoS monitoring handling.
  • the NF service consumer may also create, modify or remove events subscription information by sending the HTTP PATCH request message to the resource URI representing the "Individual Application Session Context" resource.
  • the NF service consumer shall create event subscription information by including in the "ascReqData” attribute the "evSubsc” attribute of "EventsSubscReqDataRnT data type with the corresponding list of events to subscribe to; and the "notifllri” attribute with the notification URI where the PCF shall send the notifications.
  • the NF service consumer shall update existing event subscription information by including in the "ascReqData” attribute an updated value of the "evSubsc” attribute of the "EventsSubscReqDataRm” data type as follows:
  • the "events” attribute shall include the new complete list of subscribed events.
  • the NF service consumer When the NF service consumer requests to update the additional information related to an event (e.g. the NF service consumer needs to provide new thresholds to the PCF in the "usgThres" attribute related to the "USAGE_REPORT” event) the NF service consumer shall include the additional information, which shall completely replace the previously provided one.
  • the additional information related to an event e.g. the NF service consumer needs to provide new thresholds to the PCF in the "usgThres" attribute related to the "USAGE_REPORT" event
  • the NF service consumer shall include the additional information, which shall completely replace the previously provided one.
  • the NF service consumer shall remove existing event subscription information by setting to null the "evSubsc” attribute included in the "ascReqData” attribute.
  • Events with "notif Method” set to "ONE_TIME” shall only apply at the time the NF service consumer requests their subscription. Once the event report is performed, the subscription to this event is automatically terminated in the PCF and the related information is removed. The presence of a one-time event, together with its related additional information when applicable, during an update procedure shall represent the recreation of the subscription to this event in the PCF.
  • NOTE 4 The "notifUri" attribute within the EventsSubscReqData data structure can be modified to request that subsequent notifications are sent to a new NF service consumer.
  • the PCF shall send the HTTP error response as specified in clause 5.7.
  • the PCF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5],
  • the PCF shall process the received service information according the operator policy and may decide whether the HTTP request message is accepted or not.
  • the PCF shall include in an HTTP "403 Forbidden” response message the "cause” attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED".
  • the PCF shall reject the request with an HTTP "403 Forbidden” response including the "cause” attribute set to "TEMPORARY_NETWORK_FAILURE".
  • the PCF may include in the "403 Forbidden” response the "cause” attribute set to "REQUESTED_SERVICE_TEMPORARILY_NOT_AUTHORIZED".
  • the PCF may also provide a retry interval within the "Retry-After” HTTP header field.
  • the NF service consumer When the NF service consumer receives the retry interval within the "Retry- After” HTTP header field, the NF service consumer shall not send the same service information to the PCF again (for the same application session context) until the retry interval has elapsed.
  • the "Retry-After" HTTP header is described in 3GPP TS 29.500 [5] clause 5.2.2.2.
  • the PCF may additionally provide the acceptable bandwidth within the attribute "acceptableServinfo" included in the "ExtendedProblemDetails” data structure returned in the rejection response message.
  • the PCF shall update the service information with the new information received. Due to the updated service information, the PCF may need to create, modify or delete the related PCC rules as specified in 3GPP TS 29.513 [7] and provide the updated information towards the SMF following the corresponding procedures specified in 3GPP TS 29.512 [8], Based on the received subscription information from the NF service consumer, the PCF may create a subscription to event notifications or may modify the existing subscription to event notifications, for a related PDU session from the SMF, as described in 3GPP TS 29.512 [8],
  • the PCF shall reply with the HTTP response message to the NF service consumer and may include the "AppSessionContext" data type payload body with the representation of the modified "Individual Application Session Context" resource and may include the "Events Subscription" sub-resource.
  • the PCF shall include in the "evsNotif” attribute: if the NF service consumer subscribed to the "PLMN_CHG" event in the HTTP PATCH request, the "event” attribute set to "PLMN_CHG” and the "plmnld” attribute including the PLMN Identifier or the SNPN Identifier if the PCF has previously requested to be updated with this information in the SMF;
  • the SNPN Identifier consists of the PLMN Identifier and the NID. if the NF service consumer subscribed to the event "ACCESS_TYPE_CHANGE" event in the HTTP PATCH request, the "event” attribute set to "ACCESS_TYPE_CHANGE” and: the attributes i. the "accessType” attribute including the access type, and the “ratType” attribute including the RAT type when applicable for the notified access type; and ii. if the "ATSSS" feature is supported, the "addAccessinfo” attribute with the additional access type information if available, where the access type is encoded in the "accessType” attribute, and the RAT type is encoded in the "ratType” attribute when applicable for the notified access type; and
  • the PCF includes the "accessType” attribute and the "ratType” attribute with a currently active combination of access type and RAT type (if applicable for the notifed access type).
  • the PCF includes the information corresponding to the 3GPP access. ill.
  • the HTTP response message towards the NF service consumer should take place before or in parallel with any required PCC rule provisioning towards the SMF.
  • the PCF shall reject the HTTP request message with the HTTP response message with the applicable rejection cause.
  • the subscription to Service Data Flow QoS monitoring information is used by a NF service consumer to receive a notification about the packet delay between UPF and RAN.
  • the NF service consumer shall use the "EventsSubscReqData” data type as described in clause 4.2.2.2 and shall include: the requested QoS monitoring parameters) to be measured (i.e. DL, UL and/or round trip packet delay) within the "reqQosMonParams" attribute; an entry of the "AfEventSubscription" data type in the "events” attribute with: a) the "event” attribute set to the value "QOS_MONITORING”; and b) the "notifMethod” attribute set to the value "EVENTJDETECTION", "PERIODIC” or PDU_SESSION_RELEASE; and c) when the "notifMethod” attribute is set to the value "PERIODIC", the reporting period within the "repPeriod” attribute; and d) when the "notifMethod” attribute set to the value "EVENTJDETECTION", the minimum waiting time between subsequent reports within the "waitTime” attribute.
  • the "qosMon” attribute when the "notifMethod” attribute set to the value "EVENTJDETECTION", the "qosMon” attribute, with the required Qos Monitoring information, i.e.: the delay threshold for downlink with the "repThreshDI” attribute; the delay threshold for uplink with the "repThreshUI” attribute; and/or the delay threshold for round trip with the "repThreshRp" attribute.
  • the NF service consumer may include in "EventsSubscReqData” data type the notification correlation identifier assigned by the AF within the “notifCorrel d” attribute and, if the feature "ExposureToEAS" is supported, the "directNotifl nd” attribute set to true to indicate direct event notification of QoS Monitoring data from the UPF.
  • the NF service consumer shall include more than one "AfEventSubscription" data type within the "EventsSubscReqData” data type if more than one notify method is required.
  • the NF service consumer When the feature "CorrelationOfM ultipleSDFs" is supported, and the NF service consumer provides more than one MediaComponent and/or MediaSubcomponent entries, the NF service consumer shall include within in each MediaSubcomponent entry the "sdfCorrelationld" attribute, set to different value for each of the media subcomponents of the AF session that require the same QoS monitoring handling.
  • the PCF shall reply to the AF as described in clause 4.2.2 2.
  • the PCF shall set the appropriate subscription to QoS Monitoring information for the corresponding PCC rule(s) as described in 3GPP TS 29.512 [8], Next change
  • This procedure is used by NF service consumer to modify the PCF subscription for notification about packet delay between UPF and RAN.
  • the NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.
  • the NF service consumer shall include in the HTTP PATCH request message described in clause 4.2 3.2, in the "ascReqData” attribute, the updated values of the "evSubsc” attribute of "EventsSubscReqDataRm” data type, as follows: to create a subscription to QoS monitoring information: a) shall include the "events" array with an array that contains a new entry with the "event” attribute set to "QOSJVIONITORING", and notification related information as described in clause 4.2.2.23; and b) when the "notifMethod" of the new entry is "EVENT_DETECTION", shall include a "qosMon” attribute with the QoS monitoring information as described in clause 4.2.2.23.
  • c) shall include the new requested QoS monitoring parameter(s) to be measured (i.e. DL, UL and/or round trip packet delay) within the "reqQosMonParams" attribute; to remove a subscription to QoS monitoring information: a) shall include the "events” array containing an array that shall omit the corresponding entry with the "event” attribute value "QOSJVIONITORING”; and b) when the "notifMethod" of the removed entry is "EVENTJDETECTION", it shall contain the "qosMon” attribute set to null.
  • the NF service consumer When the feature "CorrelationOfM ultipleSDFs" is supported, and the NF service consumer provides more than one MediaComponent and/or Mediasubcomponent entries, the NF service consumer shall include within in each Mediasubcomponent entry the "sdfCorrel ation Id" attribute, set to different value for each of the media subcomponents of the AF session that share the same QoS monitoring requirements.
  • the PCF shall set the appropriate subscription to QoS monitoring information for the corresponding active PCC rule(s) as described in 3GPP TS 29.512 [8],
  • the PCF shall reply to the NF service consumer as described in clause 4.2.3.2.
  • the NF service consumer shall include in the HTTP PUT request message described in clause 4.2.6.2 the "EventsSubscReqData" data type, that shall contain: to create a subscription to QoS monitoring information: a) shall include the "events” array with an array that contains a new entry with the "event” attribute set to
  • ExposureToEAS may include the "directNotifl nd" attribute set to true to indicate the direct event notification of QoS Monitoring data from the UPF.
  • a) shall include the "events” array containing an array that shall omit the corresponding entry with the "event” attribute value "QOSJVIONITORING”; and b) when the "notifMethod" of the removed entry is "EVENTJDETECTION", it shall omit the "qosMon”.
  • the NF service consumer shall include other events related information that shall remain unchanged.
  • the NF service consumer When the feature "CorrelationOfM ultipleSDFs" is supported, the NF service consumer provides updated/new QoS monitoring requirements, and the service consists of multiple media components and/or media subcomponents, the NF service consumer shall have previously included within in each MediaSubcomponent entry the "sdfCorrelationld" attribute, set to different value for each of the media subcomponents of the AF session that share the same QoS monitoring requirements.
  • the PCF shall set the appropriate subscription to QoS monitoring information for the corresponding active PCC rule(s) as described in 3GPP TS 29.512 [8],
  • the PCF shall reply to the NF service consumer as described in clause 4.2.6.2
  • bit rate information and flow status information provided within the "MediaSubComponent" data type takes precedence over information provided within "MediaComponent” data type.
  • This data type is defined in the same way as the "MediaSubComponent” data type, but: with the OpenAPI "nullable: true” property; the removable attributes "marBwDI”, “marBwlll”, defined with the removable data type “BitRateRm”; the removable attribute “tosTrCI”, defined with the removable data type “TosTrafficClassRm”; the removable attribute “sdfCorrelationld”, defined with the removable data type "UintegerRm”; and the removable attributes "ethfDescs” and "fDescs” are defined as nullable in the OpenAPI.
  • the optional features in table 5.8-1 are defined for the Npcf_PolicyAuthorization API. They shall be negotiated using the extensibility mechanism defined in clause 6.6.2 of 3GPP TS 29.500 [5], When requesting the PCF to create an Individual Application Session Context resource the NF service consumer shall indicate the optional features the NF service consumer supports for the Npcf_Pol icyAuthorization service by including the "suppFeat" attribute in the "AppSessionContextReqData" data type of the HTTP POST request.
  • the PCF shall determine the supported features for the created Individual Application Session Context resource as specified in clause 6.6 2 of 3GPP TS 29.500 [5]
  • the PCF shall indicate the supported features in the HTTP response confirming the creation of the Individual Application Session Context resource by including the "suppFeat 11 attribute in the "AppSessionContextRespData" data type.
  • the UPF will include QFI to enable AF/NEF to correlate the QoS Monitoring Report.
  • QFI allocation mechanism is not fully specified, e g. how AF/NEF can find the SMF serving the PDU session, in the Event Subscription data type as specified in TS29.508, it is not possible to include multiple media components as described by(ethernet) flow description, and in the Event Notification (in TS29.508) only one pair of (ethernet) flow description can be provided. More importantly, Nudm_ee service seems lack of support for QFI allocation.
  • the SMF is required to create a separate QoS flow to transport the packets pertaining to the AF session (as identified by the application id or service data flow(s) filter(s)) according to the PCC rule authorized by the PCF and when the PCC contains QoS Monitoring requirement, so that the SMF will provision Packet Detection Rule(s) generated according to the PCC rule and associate it with QoS Enforcement Rule (QER)(s) where the UPF can learn the QFI(s) (QoS Flow Identifier).
  • QER QoS Enforcement Rule
  • the SMF will provide Session Reporting Rule to request the UPF to perform QoS Monitoring for the QoS flow(s) as identified by the QFI.
  • the UPF can use QFI to derive the PDRs associated with the QFI in the QoS enforcement Rule (QER).
  • UPF shall include the application Id, or by ethernet flow description or (IP) flow description which can be derived from the Packet Detection Rule in the Notificationitem to enable AF/NEF to correlate the QoS Monitoring Reports with different service data flows.
  • IP ethernet flow description
  • Rev1 Considering using flow description (for either IP flow or ethernet flow) to identify the corresponding service data flow will lead higher processing load in the receiver, i.e. theNEF/AF, since the flow description is large chunk of octets and NEF/AF has to use JSON matching.
  • the AF may allocate a "sdfCorrelationld" for each Media Subcomponent, so that those Media Subcomponents which should have the same QoS treatment will share the same "sdfCorrelationld", then the PCF will create a PCC including all the flows defined in these Media Subcomponent, i.e. per "sdfCorrelationld", the PCC rule is then provisioned to the SMF.
  • the SMF will then make sure the application packets matching the PCC rule will be transported over a separated QoS flow and it will request the UPF to perform QoS Monitoring per QoS Flow. Therefore, the "sdfCorrelationld" can be used by the AF/NEF to correlate the received QoS Monitoring Report with the corresponding service data flow(s). So, it is further proposed, when sending QoS Monitoring Reports to AF/NEF, the UPF shall include the sdfCorrelationld if it is received from the SMF.
  • Table 6.1.6.1-1 Nupf_EventExposure specific Data Types Table 6.1.6.1-2 specifies data types re-used by the Nupf_EventExposure service from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nupf_EventExposure service.
  • This disclosure provides a method that allows the network to correlate media components (e.g., SDFs) that share the same QoS monitoring requirements when these media components correspond to different media, and allows the network to request different QoS monitoring requirements for different media component/subcomponent(s) (i.e. , for different flows with different QoS requirements).
  • media components e.g., SDFs
  • QoS monitoring requirements for different media component/subcomponent(s)
  • transmit to means “transmit directly or indirectly to.” Accordingly, transmitting a message to a node encompasses transmitting the message directly to the node or transmitting the message indirectly to the node such that the message is relayed to the node via one or more intermediate nodes.
  • receive from means “receive directly or indirectly from.” Accordingly, receiving a message from a node encompasses receiving the message directly from the node or receiving the message indirectly from node such that the message is relayed from the sender to the node via one or more intermediate nodes.
  • the term “a” means “at least one” or “one or more” unless expressly indicated otherwise or the context in which "a” is used clearly indicates otherwise.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Est divulgué un procédé mis en œuvre par une fonction réseau (NF) (302) (par exemple, AF ou NEF). Le procédé consiste à : générer (s402) une demande de notification de surveillance (351) (par exemple, une demande AF) ; et transmettre (s404) la demande de notification de surveillance à une fonction de politique (PF) (304), la demande de notification de surveillance comprenant : une première structure de données multimédia correspondant à un premier composant multimédia (par exemple, un sous-composant multimédia - c'est-à-dire que la première structure de données multimédia peut être de type MediaSubComponent comme défini dans la table 5.6.2.8-1 de la norme 3GPP TS 29.514) ; une seconde structure de données multimédia correspondant à un second composant multimédia ; et des premières informations de surveillance de qualité de service (QoS) (par exemple, qui correspondent à la structure de données QosMonitoringPerSdf) comprenant : i) des premières informations sur l'exigence QoS indiquant une première exigence QoS et ii) des premières informations sur le composant multimédia indiquant que la première exigence QoS s'applique au moins au premier composant multimédia et/ou au second composant multimédia.
PCT/EP2023/072613 2022-08-17 2023-08-16 Surveillance de qualité de service pour de multiples flux de données de service WO2024038110A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202263398763P 2022-08-17 2022-08-17
US63/398,763 2022-08-17
US202263422580P 2022-11-04 2022-11-04
US63/422,580 2022-11-04

Publications (1)

Publication Number Publication Date
WO2024038110A1 true WO2024038110A1 (fr) 2024-02-22

Family

ID=87747916

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/072613 WO2024038110A1 (fr) 2022-08-17 2023-08-16 Surveillance de qualité de service pour de multiples flux de données de service

Country Status (1)

Country Link
WO (1) WO2024038110A1 (fr)

Non-Patent Citations (14)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3 (Release 16)", 18 June 2021 (2021-06-18), XP052028514, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ct/WG3_interworking_ex-CN3/DRAFT_SPEC_IMPLEMENTATIONS/CT_92e/Draft/draft_29513-g80.doc> [retrieved on 20210618] *
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Policy Authorization Service; Stage 3 (Release 17)", 10 June 2022 (2022-06-10), XP052201659, Retrieved from the Internet <URL:https://ftp.3gpp.org/3guInternal/3GPP_ultimate_versions_to_be_transposed/sentToDpc/29514-h50.zip 29514-h50.doc> [retrieved on 20220610] *
3GPP TECHNICAL SPECIFICATION 23.501
3GPP TECHNICAL SPECIFICATION TS 23.503
3GPP TS 23.501
3GPP TS 23.502
3GPP TS 23.503
3GPP TS 23.548
3GPP TS 29.500
3GPP TS 29.512
3GPP TS 29.513
3GPP TS 29.514
3GPP TS 29.544
DEVAKI CHANDRAMOULI ET AL: "KI#1/#2 New Sol: Policy Control enhancements for multi-modal traffic", vol. 3GPP SA 2, no. Online; 20220516 - 20220520, 6 May 2022 (2022-05-06), XP052167969, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_151E_Electronic_2022-05/Docs/S2-2204609.zip S2-2204609 FS_XRM_multi-modal.docx> [retrieved on 20220506] *

Similar Documents

Publication Publication Date Title
JP7463019B2 (ja) サービス性能の監視および報告
US11533401B2 (en) Charging policy information for a packet data unit session in a wireless network
US12015734B2 (en) Policy information to policy control and confirmation to session management
US11909907B2 (en) Charging policy information for a home session management function
CN114008980B (zh) 用于非公共网络的收费控制方法和系统
CN112889254B (zh) 使用策略处理数据包的方法和系统
US12108470B2 (en) Application triggering for a wireless device
US20240163938A1 (en) Charging Aggregation Control for Network Slices
WO2020139696A1 (fr) Restriction de services et de commande de politique pour une session pdu toujours active
US11026078B2 (en) Priority handling for data flow transport in communication systems
US20150110044A1 (en) Third party interface for provisioning bearers according to a quality of service subscription
US20150245240A1 (en) Network resource modification
WO2023213796A1 (fr) Mise en corrélation d&#39;un rapport de surveillance de qualité de service (qos) avec un flux de paquets
US20210022204A1 (en) Methods and apparatuses for accessing a service outside a mobile communications network in a multipath connection
KR20230062254A (ko) 단말 라우팅 선택 정책의 준수를 확인하는 방법 및 장치
WO2024038110A1 (fr) Surveillance de qualité de service pour de multiples flux de données de service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23757618

Country of ref document: EP

Kind code of ref document: A1