WO2017194768A1 - Interaction réseau-service concernant le comportement d'un réseau demandé - Google Patents

Interaction réseau-service concernant le comportement d'un réseau demandé Download PDF

Info

Publication number
WO2017194768A1
WO2017194768A1 PCT/EP2017/061525 EP2017061525W WO2017194768A1 WO 2017194768 A1 WO2017194768 A1 WO 2017194768A1 EP 2017061525 W EP2017061525 W EP 2017061525W WO 2017194768 A1 WO2017194768 A1 WO 2017194768A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
network
application
requirements
node
Prior art date
Application number
PCT/EP2017/061525
Other languages
English (en)
Inventor
Åsa LARSEN
Aldo Bolle
Ann-Christine Eriksson
Angel Navas Cornejo
Ylva Timner
Jonas Pettersson
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 WO2017194768A1 publication Critical patent/WO2017194768A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment

Definitions

  • the present invention relates to communication system networks, and more particularly to interactions between applications having network service requirements, and networks that provide the service.
  • the Quality of Service (QoS) framework for a 3GPP defined EPS network describes how to differentiate the traffic from different subscribers and services in the 3 GPP network. Differentiation of the traffic is achieved by assigning the traffic to different EPS bearers.
  • QoS Quality of Service
  • An application may interact with the PCRF, through the 3 GPP Rx interface described in 3GPP TS 29.214, to provide service information and service requirements (such as minimum requested bandwidth, maximum requested bitrate, etc.).
  • the PCRF Based on operator policies and the information received from the application, the PCRF authorizes the request and decides what the corresponding QoS will be.
  • the decided QoS is sent to the 3GPP network over the Gx interface (defined in the 3GPP specifications).
  • different QoS targets are realized as different dedicated EPS bearers (i.e., virtual connections between endpoints in the network). Bearers are established (or modified) when the request is received from the PCRF.
  • bearer establishment fails in the network, or if a bearer is removed, information about this event is sent to the PCRF that can forward the information to the application.
  • the following example shows the current capabilities in the 3GPP PCC architecture for notifying the service layer when resources cannot be allocated in the network.
  • the PCRF Upon reception of a notification that one or more PCC rules (service data flows) have been deactivated, the PCRF informs the AF accordingly if the AF has previously subscribed by using the Specific-Action AVP in the AAR command. If not all the service data flows within the AF session are affected, the PCRF informs the AF by sending an RAR command (re-authorization request).
  • the PCRF informs the AF by sending an ASR command (abort session request).
  • FIG. 1 depicts the following steps: 101.
  • the PCRF receives from the AF the service information, and also the list of Specific Actions, which includes:
  • the PCRF identifies and authorizes the service.
  • the PCRF sends to the AF an AAA message including the Supported Features AVP matching the features requested by the AF.
  • the PCRF determines the authorized QoS for the service.
  • the PCRF determines the corresponding PCC rules to be provided to the PCEF via the Gx interface.
  • the PCRF provides the PCC Rules to the PCEF by means of an RAR message.
  • the PCEF acknowledges the message by means of an RAA message.
  • the PCEF performs bearer binding and provides the request to the radio network to reserve the QoS authorized by the PCRF.
  • the PCEF sends a CCR-Update message which includes the Charging-Rule- Report (with PCC-Rule-Status set to INACTIVE) indicating that one or more service data flows have been deactivated. This means that the QoS authorized by the PCRF cannot be reserved by the network.
  • the PCRF informs the PCEF that it accepts the notification.
  • the PCRF sends a RAR message to the AF, including the Specific Action and the deactivated IP Flows encoded in the Flows AVP.
  • the PCRF sets the Specific-Action AVP to INDICATION OF FAILED RESOURCES ALLOCATION according to the notification event the AF has previously subscribed to.
  • the PCRF informs the AF by sending an ASR command (step 15), including the Abort-Cause AVP set to BEARER RELEASED. This is acknowledged to the PCRF by the AF by means of an ASA command (step 16). It will be noted that the PCRF sends the ASR command in this case regardless of whether the AF has previously subscribed to any notification event. Consequently the AF terminates the Rx session by sending an STR message to the PCRF (step 17). The PCRF acknowledges this to the AF by means of an STA message (step 18).
  • the authorized QoS is decided based on the input from the application and from operator policies. This means that the authorized QoS can differ from what the application has requested.
  • ARP Admission and Retention Priority
  • QCI QoS Class Identifier
  • SDF Service Data Flow
  • This may be implemented in the access network by the QCI referencing node specific parameters that control packet forwarding treatment (e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), that have been pre-configured by the operator at a specific node(s) (e.g. eNodeB).
  • control packet forwarding treatment e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.
  • the ARP parameter contains information about the priority level, the pre- emption capability and the pre-emption vulnerability.
  • the priority level defines the relative importance of a resource request. This provides a basis for deciding whether a bearer establishment or modification request can be accepted or alternatively whether it needs to be rejected in case of resource limitations. It can also be used as a basis for deciding which existing bearers to pre-empt during resource limitations.
  • GRR Guaranteed Bitrate
  • QCI QoS Class Identifier
  • the GBR parameter describes the bitrate required for the service. It is only defined for QCI values that have service class set to "GBR", and the QCI defines requirements on packet delay and packet loss.
  • a policy node in a communication system comprising an access node a core network user plane, CNUP, node, a core network control plane, CNCP, node handing at least Quality of Service, QoS, the communication system facilitating communication between a user equipment, UE, having a subscription, and at least one application, AP, running on a peer ,
  • the communication system catering for one or more Packet Data Unit, PDU, flows .
  • the policy node is adapted for
  • a request for network service upon receiving, from the AP, a request for network service, wherein the request includes:
  • an indication of service preferred network treatment when the service requirements are not comprising information on whether the application should be notified when the requested service requirements cannot be met.
  • communication system comprising an access node , a core network user plane, CNUP, node, a core network control plane, CNCP, node handing at least Quality of Service, QoS, the communication system facilitating communication between a UE, having a subscription, and at least one application running on a peer , the communication system catering for one or more Packet Data Unit, PDU, flows .
  • the policy node is adapted for
  • a request for network service upon receiving, from the application , a request for network service, wherein the request includes:
  • the communication system comprising an access node, a core network user plane, CNUP, node, a core network control plane, CNCP, node handing at least Quality of Service, QoS.
  • the communication system is facilitating communication between a UE, having a subscription, and at least one application, AP, running on a peer, and the communication system catering for one or more Packet Data Unit, PDU, flows.
  • the method comprises the steps of
  • a request for network service upon receiving, from the AP, a request for network service, wherein the request includes:
  • a method for a communication system comprising an access node, a core network user plane, CNUP, node, a core network control plane, CNCP, node handing at least Quality of Service, QoS, the communication system facilitating communication between a UE, having a subscription, and at least one application running on a peer.
  • the communication system is catering for one or more Packet Data Unit,
  • PDU flows, a policy node, wherein the policy node
  • FIG. 1 depicts a signaling diagram of the current capabilities in the 3GPP PCC architecture for notifying the service layer when resources cannot be allocated in the network.
  • FIG. 2 is a signaling/flow diagram of an exemplary interaction between Network and Application during the authorization of a requested service treatment.
  • FIG. 3 is a signaling/flow diagram of an exemplary interaction between
  • FIG. 4 is a signaling/flow diagram of an exemplary interaction between Network and Application in which the network continues to deliver the service regardless of whether the service requirements are met, but in which it informs the application if the QoS targets that correspond to the requested service treatment cannot be met.
  • FIG. 5 is a diagram depicting a QoS functional split including 3GPP
  • FIG. 6 is a diagram showing the relation between PDU Flow and Service Data Flow.
  • FIG. 7 is a sequence diagram for Authorized PDU Session QoS.
  • FIG. 8 is a sequence diagram for Authorized Flow QoS.
  • FIG. 9 is a block diagram of elements for carrying out various aspects of the invention as described above, such as in connection with FIGS. 2 through 7.
  • FIG. 10 shows embodiments of various nodes and entities according to the invention.
  • FIG. 11 shows another implementation of the invention.
  • circuitry configured to perform one or more described actions is used herein to refer to any such embodiment (i.e., one or more specialized circuits alone or in combination with one or more programmed processors).
  • the invention can additionally be considered to be embodied entirely within any form of non-transitory computer readable carrier, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
  • Further embodiments can be in the form of computer instructions carried by signals.
  • the various aspects of the invention may be embodied in many different forms, and all such forms are contemplated to be within the scope of the invention.
  • any such form of embodiments as described above may be referred to herein as "logic configured to" perform a described action, or alternatively as “logic that" performs a described action.
  • reference letters may be provided in some instances (e.g., in the claims and summary) to facilitate identification of various steps and/or elements. However, the use of reference letters is not intended to impute or suggest that the so-referenced steps and/or elements are to be performed or operated in any particular order.
  • the application is provided a mechanism that enables it to indicate the preferred actions when the network cannot satisfy a requested QoS.
  • the actions are derived by the network (e.g., the PCRF) implicitly based on the input from the application.
  • the new technology described herein allows applications, residing in the service layer
  • the preferred treatment for checking whether the service requirements may be met at the start of service, whether the service shall be delivered even if the requested service requirements cannot be met, and whether the application should be notified when the requested service requirements cannot be met.
  • Different options of service preferred treatment include any one or combination of the following: - Always admit the service, regardless of whether the service requirements may be met
  • the enforcement nodes in the network are able to receive notification instructions from the application when the QoS targets are received, and if called for by those instructions, to send a notification to the application informing if the QoS targets are not met.
  • a mechanism is provided for the system to inform the application in advance when there is a risk that the QoS targets cannot be met.
  • a mechanism is provided for the system to follow the application's preferences with respect to whether to continue or stop delivering the service when the QoS targets are not met.
  • Embodiment 1 is a diagrammatic representation of Embodiment 1 :
  • the network needs to know the application requirements in order to apply the correct QoS parameters.
  • Information needed from the service layer include:
  • the indicated service behavior and requirements are translated into QoS targets (QoS parameters) and the service preferred network treatments are translated into expected network behaviors by the PCRF. These QoS targets and expected network behaviors are distributed to the enforcement nodes in the network.
  • a mechanism is provided for distributing the following network behaviors in the network as part of the QoS targets:
  • the application input is provided to assist with deciding what the QoS targets/QoS parameters will be. But the application's input is not the only basis for making this decision: Other input is for example operator policies.
  • the resulting QoS targets/QoS parameters are not necessarily the same as the treatment that was requested by the application.
  • the network shall be able to inform the application about the authorized QoS targets so that the application will know which treatment its traffic is given in the network. (This aspect is described further with respect to FIG. 2, below.)
  • Service QoS includes QoS targets and network behavior
  • the enforcement node(s) use the information about expected network behavior, distributed from the PCRF, when admitting and delivering a service.
  • the QoS target fulfilment is monitored in the enforcement nodes, using the indicated measurement method.
  • the enforcement nodes inform the PCRF that the service requirements are no longer met, and whether the service delivery is discontinued.
  • the PCRF in turn informs the service about the service requirements not being met, and about whether the service delivery is discontinued.
  • the enforcement nodes In instances in which the application is to be notified in advance about the expected network behavior, the enforcement nodes also monitor the state of QoS target fulfilment and estimate/predict if the QoS targets will no longer be fulfilled. If it is estimated/predicted that the QoS targets will no longer be fulfilled, the enforcement nodes inform the PCRF, which in turn informs the application, if such notification was previously requested.
  • Embodiment 2 is a diagrammatic representation of Embodiment 1:
  • the preferred network behavior is set as part of the operator QoS policies and this is included in the Service QoS that is sent from the PCRF to the enforcement node(s) as part of the QoS framework. All interaction within the network is the same as described above with respect to Embodiment 1.
  • FIG. 2 is a signaling diagram of the interaction. It can be seen from the figure that, after receiving a requested service treatment from the application, the network informs the application about the result of the authorization of the requested service treatment. In the exemplary embodiment, the following steps are performed:
  • a session is established and the QoS targets for the session are decided by the network as specified in the subscription terms between the service consumer and the network provider.
  • An application (either from the client or the server of the application) requests a specific service treatment from the network.
  • the request also includes a requested network behavior from the application.
  • the network evaluates and authorizes the service request.
  • Case A During the evaluation and authorization of the service request the network accepts the requested service treatment.
  • An acknowledgement is sent from the network to the application informing that the network will deliver connectivity according to the requested service treatment.
  • the already established session is updated to enable connectivity according to the request.
  • QoS targets are used.
  • Traffic is exchanged between the Service consumer and the application according to the requested service treatment. End case A.
  • Case B During the evaluation and authorization of the service request the network changes the requested service treatment.
  • the authorized service treatment is not the same as the requested service treatment.
  • An acknowledgement is sent from the network to the application informing that the network will deliver connectivity according to the authorized service treatment which differs from the requested service treatment.
  • the already established session is updated to enable connectivity according to the request.
  • QoS targets are used.
  • Traffic is exchanged between the Service consumer and the application according to the requested service treatment. End case B.
  • a message is sent from the network to the application informing that the network has not accepted the service treatment request. End case C.
  • FIG. 3 is a signaling diagram of the interaction. It can be seen from the figure that, the network informs the application if the QoS targets that correspond to the requested service treatment cannot be met. For simplicity, this figure shows only when the requested service treatment is authorized and accepted in the network (Case A in FIG. 2). In the exemplary embodiment, the following steps are performed:
  • a session is established and the QoS targets for the session are decided by the network as specified in the subscription terms between the service consumer and the network provider.
  • An application (either from the client or the server of the application) requests a specific service treatment from the network.
  • the request also includes a requested network behavior from the application.
  • the network evaluates and authorizes the service request. During the evaluation and authorization of the service request the network accepts the requested service treatment.
  • An acknowledgement is sent from the network to the application informing that the network will deliver connectivity according to the requested service treatment.
  • the already established session is updated to enable connectivity according to the request.
  • QoS targets are used.
  • Traffic is exchanged between the Service consumer and the application according to the requested service treatment.
  • the network detects that the QoS targets indicated in the authorized service treatment cannot be met.
  • Case A The requested network behavior from the application is to not be notified when the requested service treatment is not met. Hence, even though the QoS targets indicated in the authorized service treatment cannot be met, there is no action taken. End Case A.
  • Case B The requested network behavior from the application is to be notified when the requested service treatment is not met. The network tries to deliver according to the requested service treatment.
  • the network After establishing that it is not possible to fulfill the requested service treatment, the network sends a notification telling this to the application.
  • Case C The requested network behavior from the application is to not be notified when the requested service treatment is not met, and to discontinue the requested service treatment.
  • the session is updated to remove the resources associated with the authorized service treatment.
  • the network sends a notification to the application informing that it is not possible to deliver according to the requested service treatment and that the requested service treatment is no longer delivered by the network. End Case C.
  • FIG. 4 shows signaling related to an aspect of the inventive technology in which the network continues to deliver the service regardless of whether the service requirements are met, but in which it informs the application if the QoS targets that correspond to the requested service treatment cannot be met.
  • this figure shows only when the requested service treatment is authorized and accepted in the network (Case A in FIG. 2).
  • the following steps are performed: 401.
  • a session is established and the QoS targets for the session are decided by the network as specified in the subscription terms between the service consumer and the network provider.
  • An application (either from the client or the server of the application) requests a specific service treatment from the network.
  • the request also includes a requested network behavior from the application.
  • the request is sent to the PCRF over the Rx interface.
  • the PCRF evaluates and authorizes the service request. During the evaluation and authorization of the service request, the network accepts the requested service treatment.
  • An acknowledgement is sent from the network (e.g., PCRF) to the application informing that the network will deliver the service according to the requested service treatment.
  • the PCRF sends the QoS targets for the service over the Gx interface in a dynamic PCC rule (e.g., to a PGW).
  • the dynamic PCC rule includes the requested network behavior. This information is used by the enforcement nodes to indicate the expected behavior if the QoS targets cannot be fulfilled.
  • the PGW Since (in this example) there is no already established bearer that correspond to the QoS targets in the dynamic PCC rule (in step 5), the PGW initiates the establishment of a new dedicated bearer corresponding to the QoS targets from the PCRF.
  • the expected network behavior is part of the bearer establishment request.
  • the SGW forwards the bearer establishment request to an MME.
  • the expected network behavior is part of the bearer establishment request.
  • the MME sends a message to an eNodeB, initiating the dedicated bearer with the QoS targets including the expected network treatment.
  • the eNodeB forwards the dedicated bearer request to the UE, including the QoS targets and the expected network treatment.
  • the UE and the eNodeB send their responses to the bearer request.
  • the MME forwards the bearer response to the SGW.
  • the SGW forwards the bearer response to the PGW. 413. Traffic is exchanged between the Service consumer and the application according to the requested service treatment.
  • the eNodeB monitors whether the QoS targets are being fulfilled.
  • the eNodeB detects that the QoS targets indicated in the authorized service treatment cannot be met.
  • the eNodeB sends to the MME a notification that the QoS targets are not fulfilled.
  • the MME forwards the notification to the SGW.
  • the SGW forwards the notification to the PGW.
  • the PGW receives the notification, and send a notification to the PCRF for all PCC rules that are carried over the bearer that the notification was received for
  • the PCRF notifies the application that the requested service treatment is not being fulfilled.
  • the network continues to deliver the traffic between the service consumer and the application over the established dedicated bearer, even though the preferred service treatment is not being fulfilled.
  • the technology described herein ensures that applications can request different network treatment to be followed when the QoS targets cannot be met by the network, and that the network can act upon the requested network treatment.
  • the technology also ensures that the application can be made aware of the network behavior with respect to QoS.
  • the service requirements are described by a set of QoS parameters per bearer or data flow.
  • the operator policy is described by two or more priority parameters that define how important it is to fulfill the service requirements, and how important it is to get more resources than required.
  • the expected bearer treatment is described by a set of QoS parameters that are distributed in the network.
  • a set of service requirement parameters are provided that describe the minimum requirements for the service, and how to measure fulfillment.
  • Exemplary embodiments also include policy parameters that define how important the service is to the operator.
  • service characteristics parameters that describe the characteristics of the data flow.
  • Embodiment 3 is a diagrammatic representation of Embodiment 3 :
  • the service requirements parameters describe what is required by the service to get good QoE. In order to be able to observe fulfillment of the requirements, measurement methods are defined for the parameters. Examples are:
  • the service characteristics parameters describe characteristics of the data flow that is useful to know for network optimizations. Some examples are:
  • the network policy parameters describe how the bearer is prioritized by the operator. Parameters can be used for allocation and retention of bearers as well as for scheduling of network resources. In this embodiment, there are two policy parameters:
  • o Can be expressed as a relative priority, defining the relation of resource distribution between different bearers.
  • the service requirements and characteristics can either be defined as separate parameters, or be grouped together in a QCI, but the priority parameters should be set separately. This makes it possible to prioritize user groups differently without the need to customize the service requirements and
  • Embodiment 4 it is possible to give a public safety user high priority, while still using the bearers that are optimized for the service used. By comparison, in a conventional network, new QCFs need to be standardized for all services that are used for public safety.
  • Embodiment 4
  • the policy parameters of the third embodiment could be complemented with parameters that define the importance of getting better than minimum performance with regards to requirement parameters other than bitrate. Some examples could be:
  • Embodiment 5
  • Embodiment 6 PDU Flow QoS Solution
  • the QoS functions of current 3GPP architecture are distributed between the UE, RAN and CN.
  • This solution describes an overall QoS solution for the NextGen system, describing how the QoS functionality is distributed between the CN, the RAN and the UE, see Figure 5 for a high level view of such functional split.
  • the application requirements input From UE/SL to CN requirements input may
  • Classification CN (DL), UE (UL) Provides classification of packets for QoS purposes
  • Max rate control CN (DL, UL)
  • Transport marking AN (UL), CN (UL,
  • the subscription contains information about which QoS parameters that are included in the subscription terms.
  • the subscription QoS is an input for the network when authorizing the QoS for a PDU session and a non-Service-specific PDU flow in the QoS Operator control function.
  • QoS Operator control With the input from the subscription, operator policies and application requirements input from the service layer, the QoS parameters for PDU sessions and PDU flows are authorized in the QoS Operator control function.
  • the QoS Operator control function is also responsible for distributing the authorized QoS parameters in the network. In case of PDU connectivity services provided in network sharing and/or roaming across, the QoS Operator Control allows also to limit the QoS offered by the network providing the access.
  • Admission control (AN): The admission control function controls which
  • the admission control also includes to sacrify already admitted flows to allow more prioritized flows.
  • Each network element in the end-to-end solution is configured with the expected behavior with respect to QoS, i.e. how QoS parameters received from the QoS Operator control function shall be handled and applied to the PDUs.
  • Application requirements input To know the requirements of the Service Data Flows transmitted through the network, the network may be informed from the service layer about the service behavior and service requirements.
  • the application requirement input is used by the QoS Operator control function when authorizing the QoS parameters for PDU session and PDU flows.
  • Classification Indicates which PDU flow each packet of a Service Data Flow belongs to. The classification is used to select which authorized QoS parameters to apply to each PDU in the CN-UP, AN-UP and UE-UP. Deducible SDFs may be classified based on TFT filters in DL and UL. Non-deducible SDFs may be classified in DL based on packet inspection. UE reflective QoS according to TS 24.139 and packet inspection in CN-UP may be used for classification of non-deducible IP flows in UL.
  • Max rate control ensures that the maximum bitrate in the Authorized QoS parameters are maintained.
  • Transport marking The transport marking function is indicating the expected treatment in IP networks with a stateless QoS mechanisms, for example routers between the network elements.
  • the transport marking is per PDU.
  • Resource Mgmt The resource management function is responsible for how the resources are distributed in the access network based on the Authorized QoS parameters from the QoS Operator control function and the monitoring of the fulfilment of the QoS targets.
  • the resource management function can be different in 3 GPP and non-3 GPP ANs with regards to the possibilities to control resource utilization and availability. Resources mgmt is also done in the transport network.
  • the PDU flow is a logical packet transport of defined characteristics.
  • To a PDU Session is associated a number of logical PDU flows realized in the UP layer.
  • An application in the service layer may require one or multiple Service Data Flows that may be mapped into one or multiple PDU flows.
  • a PDU flow between the UE and the CN-UP termination of the operator domain is equivalent to an EPS bearer in the EPS QoS framework.
  • a PDU flow within the Radio Access Network is equivalent to a Radio Bearer.
  • Figure 6 is a diagram showing the relation between PDU Flow and Service Data Flow.
  • the application requirements information may be provided from the service layer (server or client side):
  • the Service Data Flows may be of IP type or non-IP type depending on the PDU session type.
  • Service Requirements (the network delivery behavior requested by the application), such as:
  • Minimum bitrate per SDF the bitrate that is required for the service to be delivered with sufficient QoE.
  • the QoS parameters for the PDU session, for Service-specific and non-Service-specific PDU flows and for service data flows are decided.
  • Traffic Flow templates and filters (when applicable): classifying the service data flow that the QoS parameters applies to.
  • the TFT filter is defined to classify IP and non-IP flows. For example Ethernet flows may be classified based on Ethernet p-bit.
  • PDU Flow Priority priority per PDU flow for admission to network resources, i.e. how the traffic associated with the flow shall be handled in the AN at admission and resource mgmt and in CN_UP.
  • Maximum bitrate per PDU flow UL and DL authorized bitrate value for a single PDU flow. This applies to Service-specific and non-Service- specific PDU flows.
  • Guaranteed bitrate per flow that is required for the service to be delivered with sufficient QoE.
  • Delivery characteristic per PDU flow for example, packet delay budget, packet loss/late rate.
  • the delivery characteristics may be expressed via a scalar value such as the QCI value, or explicitly indicated.
  • Network behavior per PDU flow the expected treatment if the QoS targets represented by the authorized QoS parameters for the flow are not met by the network.
  • Traffic templates classifying the service data flow that the QoS parameters apply to.
  • the TFT filter is defined to classify IP and non-IP flows. For example, Ethernet flows, may be classified based on Ethernet p-bit.
  • SDF Priority priority per SDF for admission to network resources, i.e. how the traffic associated with the flow shall be handled in the network at admission and resource mgmt and in CN UP.
  • Required bitrate per SDF the bitrate (Minimum or Guaranteed bitrate per flow) that is required for the service to be delivered with sufficient QoE.
  • Delivery characteristic per SDF for example, packet delay budget, packet loss/late rate.
  • the delivery characteristics may be expressed via a scalar value such as the QCI value, or explicitly indicated.
  • Network behavior per Service Data flow the expected treatment if the QoS targets represented by the authorized QoS parameters for the flow are not met by the network.
  • the Flow priority is a parameter indicating the relative priority of fulfilling the Required Bit Rate and delivery characteristics (delay budget, packet loss/late rate). It impacts both the SDF/PDU flow admission to resources in the network as well as the distribution of resources for packet forwarding treatment, allowing consistency in admission and resource distribution to fulfil the service requirements.
  • Network behavior per flow shall indicate the following behavior
  • the Network behavior may apply to both the SDF/PDU flow.
  • the QoS related IEs at each step of the flows is FFS.
  • FIG. 7 is a Sequence diagram for Authorized PDU Session QoS. Its steps are described in the following: 1. The UE attach to the network and a PDU session between the UE and a data network is requested. The PDU session carries all traffic related to PDU connectivity service regardless of the characteristics of individual Service Data flows.
  • the CN CP (QOS) establish a session towards the Policy function and invoke to authorization of the PDU session including the Authorized QoS of the PDU session for PDU flow to be used for a generic treatment of service data flows in the network.
  • the CN_CP may authorize the PDU session including the Authorized QoS of the PDU session for PDU flow to be used for a generic treatment of service flows in the network based on local policies.
  • the CN CP (QOS) forward the Authorized QoS to CN UP.
  • the CN UP acknowledge the reception.
  • the CN CP (QOS) complete the PDU session establishment and inform the network functions about the Authorized QoS of the PDU session to be enforced.
  • An application server may require a specific treatment in the network of service data flow or flows. If so the Policy Function can authorize a QoS per SDF to be associated to a PDU flow and enforced by the network.
  • FIG. 8 is a Sequence diagram for Authorized Flow QoS. The following is a description of the depicted steps:
  • a PDU session is established between the UE and a data network.
  • the PDU session carries all traffic related to PDU connectivity service regardless of the characteristics of individual Service Data flows.
  • the Policy function may be invoked to authorize the QoS characteristics of the PDU session as described in clause 6.2.1.
  • An Application Session consisting of one or multiple service data flows is established between the UE and the Application Server.
  • the App Server (Service Layer) indicates the application QoS
  • the request from the App Server may be originating from the App Server or from the UE through Service Layer communication.
  • the Policy Function authorizes the QoS that the network will enforce on the application's service data flow(s) and acknowledge the Application layer.
  • the Policy Function sends the Authorized QoS per service data flow to CN CP (QOS), as well as the necessary information to classify the application's service data flow(s).
  • the Authorized QoS per service data flow represent the treatment that the network shall apply to the flow.
  • the CN CP (QOS) process the Authorized QoS per service data flow and forward the Authorized QoS per PDU flow to CN UP as well as the Authorized
  • the CN UP acknowledge the reception.
  • the CN CP (QOS) forward the Authorized QoS to AN per PDU flow.
  • the AN acknowledges the reception and confirms that the Authorized QoS can be fulfilled to the CN CP.
  • the CN CP forward the Authorized QoS per PDU flow to the UE for classification and for information and possible actions such as rate control.
  • the UE acknowledge the reception.
  • the CN CP may confirm that the Authorized QoS can be fulfilled to the Policy Function.
  • the Policy Function may confirm that the Authorized QoS can be fulfilled to the App Server. 6.3 Solution evaluation
  • This clause will contain evaluation on the system impacts, e.g. UE, access network and non-access network.
  • the solution follows the principles of the EPS QoS framework, retaining the Policy centric control of QoS authorization and leveraging on a per PDU flow QoS for service differentiation.
  • FIG. 9 is a block diagram of elements for carrying out various aspects of the invention as described above, such as in connection with FIGS. 2 through 8.
  • any of the nodes described above e.g., PCRF
  • a controller 901 that includes circuitry configured to carry out any one or any combination of the various functions described above with respect to those elements.
  • Such circuitry could, for example, be entirely hard-wired circuitry (e.g., one or more Application Specific Integrated Circuits - "ASICs"). Depicted in the exemplary embodiment of FIG.
  • the memory device(s) 905 store program means 909 (e.g., a set of processor instructions) configured to cause the processor 903 to control other node elements so as to carry out any of the aspects described above, such as but not limited to those described with reference to FIGS. 2 through 8.
  • the memory device(s) 905 may also store data (not shown) representing various constant and variable parameters as may be needed by the processor 903 and/or as may be generated when carrying out its functions such as those specified by the program means 909.
  • the technology makes it possible for applications to indicate the preferred treatment of QoS targets in a more flexible way
  • the technology makes it possible for the application to know the QoS authorized by the network.
  • the technology makes it possible for the applications to adapt to the current network capabilities
  • the technology provides for more flexibility with respect to the making of temporary changes in the network, for example if for a limited time, QoS requirements cannot be met.
  • the PCRF can inform the Radio Access Network (RAN) of the requirements for each data flow, so that the RAN can optimize user satisfaction rates by sending the data '"just-in-time" when there is congestion.
  • RAN Radio Access Network
  • a user equipment, UE apparatus according to the invention.
  • the UE comprises processing means comprising a processor PCU UE an interface IF UE and a memory, MEM UE, in which memory instructions are stored and a processor PRC UE for carrying out the method steps explained above.
  • the UE communicates via the interface IF UE.
  • the IF UE comprises both an external interface, communicating with a transmitter and receiver, and internal interfaces (not shown).
  • an access node AN comprising processing means comprising a processor PCU A, an interface IF A; and a memory, MEM A. Instructions are stored in the memory for being performed by the processor such that the method steps explained above are carried out and signalling is communicated on the interface.
  • an application server APP SERV comprising a processor PCU S, an interface IF S; and a memory, MEM S. Instructions are stored in the memory for being performed by the processor such that the method steps explained above are carried out and signalling is communicated on the interface.
  • a core network user plane node or entity CN UP is provided comprising a processor PCU U, an interface IF U; and a memory, MEM U. Instructions are stored in the memory for being performed by the processor such that the method steps explained above are carried out and signalling is communicated on the interface.
  • a core network control plane node or entity CN CP comprising a processor PCU C, an interface IF C; and a memory, MEM C. Instructions are stored in the memory for being performed by the processor such that the method steps explained above are carried out and signalling is communicated on the interface.
  • a POLICY node comprising a processor PCU P, an interface IF P; and a memory, MEM P. Instructions are stored in the memory for being per- formed by the processor such that the method steps explained above are carried out and signal-ling is communicated on the interface.
  • node in this application can also be understood as entity.
  • NFVS network function virtualization system
  • the NFVS may be arranged along the lines described in Fig. 4, ETSI GS NFV 002 V. 1.1.1 (2013-10) and comprises the following elements:
  • a NFV management and orchestration system comprising an
  • VIRT INFRA Infrastructure manager
  • the NFVS more -over comprises an operational / business support system, OP/BUSS SUPP SYST, a number of virtual network function instances, VNF, by which the method steps explained above are instantiated, and a virtualized infrastructure, VIRT INFRA.
  • the VIRT INFRA comprises a virtual computing, VIRT COMP, virtual network; VIRT NETW, and virtual memory, VIRT MEM, a virtualization layer,
  • VIRT LAYER e.g. hypervisor
  • shared hardware resources
  • SHARED HARDW RES comprising computing devices, COMP, network devices, comprising e.g. standard switches and other network devices, and standard data storage devices, MEM.
  • a network node that:
  • a request for network service wherein the request includes:
  • the network node acts in accordance with the service preferred network treatment when the service requirements are not met. 2.
  • the network node as in 1 , wherein the network node is configured to monitor fulfillment of the service requirements in order to detect when the service requirements are not met.
  • the network node as in any of 1 through 10 wherein the request includes an indication of priority for fulfilling the service requirements.
  • the request includes an indication of a priority to get more than the required service requirements.
  • a method performed in a packet inspection node wherein the method performs the functionality stated in any one of aspects 1 through 12.
  • CNUP core network user plane
  • CNCP CNCP
  • CN CP node handing at least Quality of Service, QoS,
  • the communication system facilitating communication between a UE, having a subscription, and at least one application, AP, running on a peer (App Server), the communication system catering for one or more Packet Data Unit, PDU, flows (1),
  • a request (3, 201; 302; 402) for network service, wherein the request (3, 201; 302; 402) includes:
  • Method according to 14 or 15, wherein the request comprises an indication of priority for fulfilling the service requirements. 17. Method according to any of 15 - 16, wherein the request moreover comprises a specific network behavior related to admission and retention.
  • AN access node
  • CNUP core network user plane
  • CNCP CNCP
  • CN CP node handing at least Quality of Service, QoS,
  • the communication system facilitating communication between a UE, having a subscription, and at least one application (AP) running on a peer (App Server), the communication system catering for one or more Packet Data Unit, PDU, flows (1),
  • a request upon receiving, from the application (AP), a request (3, 201; 302; 402) for network service, wherein the request (3, 201; 302; 402) includes:
  • an indication of service preferred network treatment when the service requirements are not comprising information on whether the application (AP) should be notified (4, 404) when the requested service requirements cannot be met;
  • CN CP core network control plane node
  • a minimum bitrate per (service) flow that is, the bitrate that is required for the service to be delivered with sufficient Quality of Experience (QoE).
  • the PDU flows being realized in the UP layer and are constituting a logical packet transport
  • Service Data flows are being established (2) between the UE and an AP on the peer, whereby
  • said AP may require one or multiple SDFs that may be mapped into one or multiple PDU flows.
  • the policy node is deciding, that is, authorizing, network authorized QoS parameters
  • the AP requirements input information (3) from the application comprises moreover
  • the network can expect from the application
  • the service requirements requested by the application comprises

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un noeud de politique dans un système de communication, qui comprend: un noeud d'accès (AN); un plan utilisateur de réseau central (CNUP); un noeud (CN UP); un plan de commande de réseau central (CNCP); un noeud (CN_CP) transférant au moins une qualité de service (QoS) pour assurer une communication entre un équipement utilisateur (UE) possédant un abonnement, et au moins une application (AP) s'exécutant sur un homologue (serveur d'applications), le système de communication gérant un ou plusieurs flux d'unité de données par paquets (PDU) (1). Le noeud de politique (politique/PCRF) est adapté pour recevoir de l'AP une demande (3, 201; 302; 402) de service de réseau comprenant: une indication d'exigences de service demandée par l'AP; et une indication de traitement de réseau préféré de service lorsque les exigences de service ne sont pas, l'indication comprenant des informations relatives au point de savoir si l'application devrait être notifiée (4; 404) lorsque les exigences du service demandé ne peuvent pas être satisfaites.
PCT/EP2017/061525 2016-05-13 2017-05-12 Interaction réseau-service concernant le comportement d'un réseau demandé WO2017194768A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662335754P 2016-05-13 2016-05-13
US62/335754 2016-05-13

Publications (1)

Publication Number Publication Date
WO2017194768A1 true WO2017194768A1 (fr) 2017-11-16

Family

ID=58709945

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/061525 WO2017194768A1 (fr) 2016-05-13 2017-05-12 Interaction réseau-service concernant le comportement d'un réseau demandé

Country Status (1)

Country Link
WO (1) WO2017194768A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111405618A (zh) * 2019-01-02 2020-07-10 苹果公司 用于延迟敏感应用程序的自适应服务质量
CN112789876A (zh) * 2018-10-08 2021-05-11 瑞典爱立信有限公司 通信系统中的通知控制
CN113676924A (zh) * 2020-05-15 2021-11-19 华为技术有限公司 通信方法、装置及系统
WO2023283858A1 (fr) * 2021-07-15 2023-01-19 Zte Corporation Techniques de transmission de perception de trafic de réseau d'accès radio
US11588741B2 (en) 2018-08-13 2023-02-21 Huawei Technologies Co., Ltd. Service flow processing method, communication method, and apparatus

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009024183A1 (fr) * 2007-08-20 2009-02-26 Telefonaktiebolaget Lm Ericsson (Publ) Notification de restrictions de ressource dans un réseau de communications multimédia
US20110296032A1 (en) * 2009-01-29 2011-12-01 Telefonaktiebolaget Lm Ericsson (Publ) Resources Allocation Flexibility
US20120314632A1 (en) * 2010-02-16 2012-12-13 Pablo Martinez De La Cruz Facilitating a communication session

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009024183A1 (fr) * 2007-08-20 2009-02-26 Telefonaktiebolaget Lm Ericsson (Publ) Notification de restrictions de ressource dans un réseau de communications multimédia
US20110296032A1 (en) * 2009-01-29 2011-12-01 Telefonaktiebolaget Lm Ericsson (Publ) Resources Allocation Flexibility
US20120314632A1 (en) * 2010-02-16 2012-12-13 Pablo Martinez De La Cruz Facilitating a communication session

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Rx reference point (Release 13)", 3GPP STANDARD; 3GPP TS 29.214, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG3, no. V13.5.0, 17 March 2016 (2016-03-17), pages 1 - 67, XP051088064 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 13)", 24 March 2016 (2016-03-24), XP051086100, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/Latest_SA2_Specs/Rel-13/> [retrieved on 20160324] *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11588741B2 (en) 2018-08-13 2023-02-21 Huawei Technologies Co., Ltd. Service flow processing method, communication method, and apparatus
US11888750B2 (en) 2018-08-13 2024-01-30 Huawei Technologies Co., Ltd. Service flow processing method, communication method, and apparatus
CN112789876A (zh) * 2018-10-08 2021-05-11 瑞典爱立信有限公司 通信系统中的通知控制
CN111405618A (zh) * 2019-01-02 2020-07-10 苹果公司 用于延迟敏感应用程序的自适应服务质量
CN111405618B (zh) * 2019-01-02 2023-06-16 苹果公司 用于延迟敏感应用程序的自适应服务质量
CN113676924A (zh) * 2020-05-15 2021-11-19 华为技术有限公司 通信方法、装置及系统
CN113676924B (zh) * 2020-05-15 2023-10-13 华为技术有限公司 通信方法、装置及系统
WO2023283858A1 (fr) * 2021-07-15 2023-01-19 Zte Corporation Techniques de transmission de perception de trafic de réseau d'accès radio

Similar Documents

Publication Publication Date Title
US10999758B2 (en) Systems and method for quality of service monitoring, policy enforcement, and charging in a communications network
US10484907B2 (en) Communication method and apparatus based on quality of service (QoS) in network slice-based mobile communication network
US11284288B2 (en) Method and apparatus for microslicing wireless communication networks with device groups, service level objectives, and load/admission control
WO2017194768A1 (fr) Interaction réseau-service concernant le comportement d&#39;un réseau demandé
US11026078B2 (en) Priority handling for data flow transport in communication systems
EP3131354B1 (fr) Dispositifs et procédés correspondant de gestion de ressources de réseau partagé
US10686723B2 (en) Providing quality of service based on bandwidth
US8774207B2 (en) Methods for bearer reservation, maintenance, and use in a communication system
EP3443713B1 (fr) Gestion de flux de sous-service commandée par la mise en application de la qos/qoe dans un système 5g
WO2017128819A1 (fr) Procédé et appareil de contrôle de politique et de facturation basés sur une application, et support de stockage
KR102202458B1 (ko) 네트워크 슬라이스 기반 이동통신 네트워크에서 QoS에 기반한 통신 방법 및 장치
Taylor et al. Priority capabilities in LTE supporting national security and emergency preparedness next generation network priority services
WO2012028008A1 (fr) Procédé et système pour contrôler des réseaux hétérogènes
US9420470B2 (en) Application aware communication system
US20120311102A1 (en) Rate adaptation

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17723984

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17723984

Country of ref document: EP

Kind code of ref document: A1