NETWORK BEHAVIOR

BACKGROUND

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.

In the following disclosure, technology is described with respect to communications systems that comply with standards published by the 3 ^rd Generation Partnership Project (3 GPP). In this context, the following and other terms, as well as the underlying technology to which these terms individually refer, are well-known and understood in the art: 3 GPP - 3rd Generation Partnership Project

AF - Application Function

EPS - Evolved Packet System

MME - Mobility Management Entity

PCC - Policy and Charging Control

PCEF - Policy and Charging Enforcement Function

PCRF - Policy Control and Charging Rules Function

PGW - Packet Gateway

QoS - Quality of Service

SGW - Serving Gateway

The use of this terminology is adopted to facilitate an understanding of the herein-described technology by a person of ordinary skill in the art. However, the use of 3 GPP terminology is not intended to limit the scope of the invention to only 3GPP systems. Rather, a person of ordinary skill in the art would readily understand how to apply the various concepts described herein to other comparable communication systems. 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.

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.).

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). In the 3GPP network, 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.

If 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 above functionality is described in the 3GPP specification as part of the Policy and Charging Control function (see 3 GPP TS 23.203).

The following example, described with reference to the signaling diagram of FIG. 1, shows the current capabilities in the 3GPP PCC architecture for notifying the service layer when resources cannot be allocated in the network. 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).

However, if all the service data flows within the AF session are affected, then the PCRF informs the AF by sending an ASR command (abort session request).

More particularly, 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:

INDICATION OF FAILED RESOURCES ALLOCATION.

102. The PCRF identifies and authorizes the service.

103. The PCRF sends to the AF an AAA message including the Supported Features AVP matching the features requested by the AF.

104. The PCRF determines the authorized QoS for the service.

105. The PCRF determines the corresponding PCC rules to be provided to the PCEF via the Gx interface.

106. The PCRF provides the PCC Rules to the PCEF by means of an RAR message.

107. The PCEF acknowledges the message by means of an RAA message.

108. The PCEF performs bearer binding and provides the request to the radio network to reserve the QoS authorized by the PCRF.

If it is the case that one or more service data flows have been deactivated, then:

109. 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.

110. The PCRF informs the PCEF that it accepts the notification.

What happens next depends on whether all service data flows within the AF session are affected:

111-113. If not all the service data flows within the AF session are affected and the AF has requested that it be notified, then 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.

114-118. If all the service data flows within the AF session are deactivated, then 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 current technology (as described above) presents a number of problems, such as:

It is not possible for the application to know which QoS the PCRF has authorized in the network. 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.

It is not possible for the application to indicate the preferred treatment in the network if the network cannot fulfill the service requirements.

It is not possible for the application to indicate whether it prefers/needs to be notified if the service requirements are not expected to be met.

Currently, the service layer is informed if the network has successfully allocated the resources to meet the service QoS requirements (the bearer) or if the bearer is not established or is removed in the network. Turning to another issue, today's 3 GPP networks provide two parameters to control the priority handling in a 3 GPP network. These two parameters are Admission and Retention Priority (ARP) and QoS Class Identifier (QCI). As defined in TS 23.203, QCI is a scalar that is used as a reference to a specific packet forwarding behavior (e.g. packet loss rate, packet delay budget) to be provided to a Service Data Flow (SDF). 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).

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.

The requirements and characteristics of the service on the bearer are primarily described by two parameters: Guaranteed Bitrate (GBR) and the previously described QoS Class Identifier (QCI).

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.

The use of the conventional parameters presents a number of problems. In one instance, since scheduling priority and service characteristics are combined in one parameter, QCI, it is not possible to enforce user differentiation for users with the same service, without defining different QCFs. For example, in order to give priority to a public safety user, specific QCFs must be defined for all services needed.

Also, it is not possible to define different priorities to a bearer depending on whether the service needs more resources to work, or just want more resources to get better Quality of Experience (QoE).

Further, in LTE, there are different parameters for Allocation/Retention and for scheduling. This is inconsistent, since, as recognized by the inventors, all three functions should work together to optimize the user's QoE based on the operator policy.

There is therefore a need for technological solutions to address the above and/or related problems and issues. SUMMARY OF THE INVENTION

One object of present invention is to accomplish an optimization in signalling. According to one aspect of the invention there is provided 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

- upon receiving, from the AP, a request for network service, wherein the request includes:

- - an indication of service requirements requested by the AP; and

- - an indication of service preferred network treatment when the service requirements are not, the indication comprising information on whether the application should be notified when the requested service requirements cannot be met.

According to another aspect there is provided 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

- upon receiving, from the application , a request for network service, wherein the request includes:

- - an indication of service requirements requested by the AP; and - - an indication of service preferred network treatment when the service requirements are not, the indication comprising information on whether the application should be notified when the requested service requirements cannot be met;

the core network control plane node

- acting in accordance with the service preferred network treatment when the service requirements are not met.

According to a further aspect a method for 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 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

- upon receiving, from the AP, a request for network service, wherein the request includes:

- - an indication of service requirements requested by the AP; and

- - an indication of service preferred network treatment when the service requirements are not, the indication comprising information on whether the application should be notified when the requested service requirements cannot be met. According to a still further aspect, a method for a communication system is provided 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

- upon receiving, from the application, a request for network service, wherein the request includes:

- - an indication of service requirements requested by the AP; and

- - an indication of service preferred network treatment when the service requirements are not, the indication comprising information on whether the application should be notified when the requested service requirements cannot be met;

the core network control plane node

- acting in accordance with the service preferred network treatment when the service requirements are not met.

Moreover, programs and computer program products are provided.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects and advantages of the invention will be understood by reading the following detailed description in conjunction with the drawings in which:

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

Network and Application during the delivery of a requested service treatment.

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

RAN.

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.

DETAILED DESCRIPTION

The various features of the invention will now be described with reference to the figures, in which like parts are identified with the same reference characters.

The various aspects of the invention will now be described in greater detail in connection with a number of exemplary embodiments. To facilitate an understanding of the invention, many aspects of the invention are described in terms of sequences of actions to be performed by elements of a computer system or other hardware capable of executing programmed instructions. It will be recognized that in each of the embodiments, the various actions could be performed by specialized circuits (e.g., analog and/or discrete logic gates interconnected to perform a specialized function), by one or more processors programmed with a suitable set of instructions, or by a combination of both. The term "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). Moreover, 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. Thus, 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. For each of the various aspects 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.

It should be emphasized that the terms "comprises" and "comprising", when used in this specification, are taken to specify the presence of stated features, integers, steps or components; but the use of these terms does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Moreover, 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.

In an aspect of exemplary embodiments, the application is provided a mechanism that enables it to indicate the preferred actions when the network cannot satisfy a requested QoS. In conventional technology, the actions are derived by the network (e.g., the PCRF) implicitly based on the input from the application. By contrast, and as will be seen in more detail below, the new technology described herein allows applications, residing in the service layer

(either the server or client side), to indicate to the network 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

Only admit the service if the service requirements may be met

- Continue to deliver the service regardless of whether the service

requirements may be met, and do not inform the application

Continue to deliver the service regardless of whether the service requirements may be met, but inform the application that the requirements are not being met

- Do not continue to deliver the service if the service requirements may not be met, and inform the application that the delivery is off

Thus, in some aspects of the inventive embodiments, 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.

In another aspect of some but not necessarily all embodiments, 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.

In yet another aspect of some but not necessarily all embodiments, 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.

These and other aspects are described in further detail in the following:

Embodiment 1 :

In addition to providing the network with service requirements, service information and service behavior, applications residing in the service layer (server or client side) are given the ability to indicate what action the network shall take if the requested service requirements cannot be delivered by the network. The network in turn interacts with the application accordingly. These aspects are described in the following:

Application input to network

The network needs to know the application requirements in order to apply the correct QoS parameters. Information needed from the service layer (server or client side) include:

Service Behavior, such as:

o Maximum bitrate per flow: the Maximum bitrate that the service is expected to deliver

o Periodicity

Service Requirements, such as:

o Minimum bitrate per flow: the bitrate that is required for the

service to be delivered with sufficient Quality of Experience (QoE) o Transfer delay

o Packet Loss/Delay Rate - Service Preferred Network Treatment

o Always admit the service, regardless of whether the service

requirements may be met

o Only admit the service if the service requirements may be met o Continue to deliver the service regardless of whether the service requirements may be met, and do not inform the application about whether the service requirements are being met.

o Continue to deliver the service regardless of whether the service requirements may be met, but inform the application that the requirements are not being met (when applicable)

o Do not continue to deliver the service if the service requirements may not be met, and inform the application that the delivery is off o Inform in advance that the service requirements will not be met, and in some but not necessarily all embodiments, provide this information an amount of time in advance that is specified by the application.

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:

Network Behaviors

o Always admit the service, regardless of whether the service

requirements may be met

o Only admit the service if the service requirements may be met o Continue to deliver the service regardless of whether the service requirements may be met, but do not inform the application about whether service requirements are being met

o Continue to deliver the service regardless of whether the service requirements may be met, but inform the application that the requirements are not being met

o Do not continue to deliver the service if the service requirements may not be met, and inform the application that the delivery is off o Inform in advance that the service requirements will not be met, and the required time in advance Network to inform application about authorized QoS/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. In an aspect of the herein- described technology, 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.)

In the cases in which there is no interaction between the service layer (application) and the network, it shall be possible to set the preferred network behavior as part of the operator QoS policies and include this in the Service QoS (Service QoS includes QoS targets and network behavior) that is sent from the PCRF to the enforcement node(s).

Network monitoring and notification

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. In case the QoS targets are not being met, 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.

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:

In the cases where there is no interaction between the service layer

(application) and the network, 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.

The interaction between Network and Application during the authorization of a requested service treatment will now be further described with reference to FIG. 2, which 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:

201. 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.

202. 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.

203. The network evaluates and authorizes the service request.

What happens next depends on the outcome of the attempt to have the network authorize the service request. Three different possibilities are described below, called "Case A", "Case B", and "Case C": 204. Case A: During the evaluation and authorization of the service request the network accepts the requested service treatment.

205. An acknowledgement is sent from the network to the application informing that the network will deliver connectivity according to the requested service treatment.

206. The already established session is updated to enable connectivity according to the request. To distribute the requested service treatment to the different parts of the network, QoS targets are used.

207. Traffic is exchanged between the Service consumer and the application according to the requested service treatment. End case A.

208. 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.

209. 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.

210. The already established session is updated to enable connectivity according to the request. To distribute the requested service treatment to the different parts of the network, QoS targets are used.

211. Traffic is exchanged between the Service consumer and the application according to the requested service treatment. End case B.

212. Case C: During the evaluation and authorization of the service request the network does not authorize the request.

213. A message is sent from the network to the application informing that the network has not accepted the service treatment request. End case C.

The interaction between Network and Application during the delivery of a requested service treatment will now be further described with reference to FIG. 3, which 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:

301. 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.

302. 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.

303. The network evaluates and authorizes the service request. During the evaluation and authorization of the service request the network accepts the requested service treatment.

304. An acknowledgement is sent from the network to the application informing that the network will deliver connectivity according to the requested service treatment.

305. The already established session is updated to enable connectivity according to the request. To distribute the requested service treatment to the different parts of the network, QoS targets are used.

306. Traffic is exchanged between the Service consumer and the application according to the requested service treatment.

307. The network detects that the QoS targets indicated in the authorized service treatment cannot be met.

What happens next depends on the outcome of the attempt to have the network authorize the service request. Three different possibilities are described below, called "Case A", "Case B", and "Case C": 308. 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.

309. 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.

310. After establishing that it is not possible to fulfill the requested service treatment, the network sends a notification telling this to the application. End

Case B.

311. 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.

312. The session is updated to remove the resources associated with the authorized service treatment.

313. 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. 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: 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.

402. 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.

403. The PCRF evaluates and authorizes the service request. During the evaluation and authorization of the service request, the network accepts the requested service treatment.

404. 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.

405. 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.

406. 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.

407. The SGW forwards the bearer establishment request to an MME. The expected network behavior is part of the bearer establishment request.

408. The MME sends a message to an eNodeB, initiating the dedicated bearer with the QoS targets including the expected network treatment.

409. The eNodeB forwards the dedicated bearer request to the UE, including the QoS targets and the expected network treatment.

410. The UE and the eNodeB send their responses to the bearer request.

411. The MME forwards the bearer response to the SGW.

412. 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.

414. The eNodeB monitors whether the QoS targets are being fulfilled.

415. The eNodeB detects that the QoS targets indicated in the authorized service treatment cannot be met.

416. The eNodeB sends to the MME a notification that the QoS targets are not fulfilled.

417. The MME forwards the notification to the SGW.

418. The SGW forwards the notification to the PGW.

419. 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

420. The PCRF notifies the application that the requested service treatment is not being fulfilled.

421. Consistent with the requested network behavior, 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.

It will be appreciated that 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. In another aspect, the technology also ensures that the application can be made aware of the network behavior with respect to QoS. Turning now to other issues, a section of the Background section of this document describes how the conventional parameters for controlling the priority handling in 3GPP networks present a number of problems. These and/or related issues are addressed in the following additional aspects of the herein-described technology.

In an aspect, the service requirements are described by a set of QoS parameters per bearer or data flow. In another aspect, 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. Also, there might be service characteristics parameters that describe the characteristics of the data flow. These and other aspects are described further in the following:

Embodiment 3 :

Service requirements parameters

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:

• Required bitrate

• Measurement window for required bitrate, size of token bucket, or similar

• Maximum packet delay

• Maximum packet loss

• Maximum packet late loss

Service characteristics parameters

The service characteristics parameters describe characteristics of the data flow that is useful to know for network optimizations. Some examples are:

• Transmission periodicity

• Object size Service Priority parameters

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:

• Priority to fulfill the requirements

• Priority to get more resources than needed for required bitrate

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

characteristics. For example, 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:

· Priority to get shorter packet delays than required

• Priority to get lower packet error rate than required

Embodiment 5 :

In this embodiment, several sets of requirement parameters are included that define the QoS required to get different levels of QoE, such as requirements for acceptable QoE, good QoE and excellent QoE. These parameters are then complemented with priority parameters defining the operator policy, for example, "Priority of acceptable QoE", "priority of good QoE", "priority of excellent QoE", and "Priority of extra resources". The above and other aspects of the technology are now described with reference to the following exemplary embodiment which, among other things, introduces the premises for the service layer to request a network behavior related to admission, retention and notification in relation to the fulfilment of the service requirements. The solution therefore supports the behavior requested by GBR type SDFs.

Embodiment 6: PDU Flow QoS Solution

6.1 Architecture description

This solution addresses a key issue on a QoS framework.

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 table 6.1.1 below lists the QoS functional split corresponding to the Figure 5.

Table 6.1.1 : QoS functional split between UE, AN, CN and SL

Function Distribution Comment

Subscription(incl CN

Default QoS Profile)

QoS Operator control CN

Admission control AN Admission to AN resources

Configuration of QoS UE, AN, CN

parameters

Application From CN/SL to CN The application requirements input From UE/SL to CN requirements input may

From UE/SL to be sent from either the CN/SL server or the client.

Classification: CN (DL), UE (UL) Provides classification of packets for QoS purposes

Max rate control CN (DL, UL)

AN (DL. UL)

UE (UL)

Transport marking AN (UL), CN (UL,

DL)

Resource Mgmt AN Packet scheduling with regards to resource utilization and availability (RRM) Resource mgmt is also performed in the transport domain (not visible in figure 5) Subscription (incl Default QoS Profile): 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

PDU flows that shall be admitted in the access network when the resources are scarce based on the QoS parameters applied for the session and flows. The admission control also includes to sacrify already admitted flows to allow more prioritized flows.

Configuration of QoS parameters: 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: Max rate control function 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.

Note: It is FFS if all functions described above are needed for NextGen system.

Note: Functions related to policy control are not described in the solution above and will need to be addressed as solutions to the key issue on Policy Framework.

6.1.1 Relation between PDU Flow and Service Data Flow

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.

6.1.2 Application requirements input

Network needs to know the application requirements in order to apply the correct QoS parameters to the Application's Service Data Flows.

The application requirements information may be provided from the service layer (server or client side):

Service identification:

How to identify the Service Data Flows associated with the application. Note: The Service Data Flows may be of IP type or non-IP type depending on the PDU session type.

Service Behavior (the behavior the network can expect from the application), such as:

- Maximum bitrate per SDF: the Max bitrate that the service is expected to deliver.

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.

Delay requirements.

Priority between different SDFs within the application. Requested network behavior with respect to Admission, Retention and Notification. Note: The list of service behavior and service requirements is not exhaustive and it is FFS which application requirement input that shall be specified within the QoS framework e.g. which input that is determined to be useful. 6.1.3 Network Authorized QoS parameters

Based on the subscription, application requirements input from the service layer and QoS configuration as well as operator policies, the QoS parameters for the PDU session, for Service-specific and non-Service-specific PDU flows and for service data flows are decided.

QoS parameters per PDU session:

Aggregated maximum bitrate for the session.

Note: It is FFS if some flows should be excluded from the Aggregated maximum bitrate or not.

QoS related parameters per Service-specific and non-Service-specific

PDU flows:

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.

Required bitrate per PDU flow: the bitrate (Minimum or

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.

QoS parameters per Service Data Flow:

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.

- Maximum bitrate per SDF: UL and DL authorized bitrate value for a single SDF.

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.

6.1.3.1 Flow Priority

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.

6.1.4.2 Network behavior per flow

Network behavior per flow shall indicate the following behavior

Admission. If the flow shall be admitted in the network even if there are not enough network resources to fulfil the service requirements

(required bitrate and/or delivery characteristics) associated with the flow cannot be met (Keep/Drop)

- Retention: If the flow can be discontinued to allow the network to admit a flow with higher priority (Retain/May be dropped)

Notification. If a network element shall send a notification (to the PCRF???) if the service requirements associated with the flow cannot be met. (Yes/No)

The Network behavior may apply to both the SDF/PDU flow. 6.2 Function description

Note: This clause will contain function descriptions and the interactions among the network functions.

Note: The QoS related IEs at each step of the flows is FFS.

6.2.1 QoS Authorization at PDU session establishment During the PDU session establishment, the QoS for a generic treatment of service data flows in the network is decided and associated to a non-Service- specific PDU flow:

Figure 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.

2. If deployed, 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. Alternatively, the CN_CP (QOS) 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.

3. The CN CP (QOS) forward the Authorized QoS to CN UP. The CN UP acknowledge the reception.

4. 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.

6.2.2 QoS Authorization based on application requirements 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.

Figure 8 is a Sequence diagram for Authorized Flow QoS. The following is a description of the depicted steps:

1. 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. 2. An Application Session consisting of one or multiple service data flows is established between the UE and the Application Server.

3. The App Server (Service Layer) indicates the application QoS

requirements as well as the necessary information to classify the application's service data flow(s). The request from the App Server may be originating from the App Server or from the UE through Service Layer communication.

4. Based on the operator policies, the Policy Function authorizes the QoS that the network will enforce on the application's service data flow(s) and acknowledge the Application layer.

5. 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.

6. 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

QoS per service data flow. The CN UP acknowledge the reception.

7. 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.

Note: In case of non-3 GPP accesses, it is up to the access network to apply the Authorized QoS per PDU flow to the available priority and packet forwarding mechanisms available and implemented in the access network. 8. The CN CP (QoS) 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.

9. The CN CP (QOS) may confirm that the Authorized QoS can be fulfilled to the Policy Function.

10. The Policy Function may confirm that the Authorized QoS can be fulfilled to the App Server. 6.3 Solution evaluation

Note: This clause will contain evaluation on the system impacts, e.g. UE, access network and non-access network.

6.3.1 Solution comparison to the existing framework

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.

The following enhancements are proposed, for example driven by the high reliable communication use cases:

Improved Service-Network interaction allowing the service layer to request a specific network behavior related to Admission, Retention and Notification. With this approach the network behavior is extended beyond the currently available distinction between GBR (Guaranteed Bit Rate) (submitted to admission control) and nonGBR bearers (no admission control and no network commitments)

Enhanced QoS parameters and alignment between application

requirements parameters and authorized QoS parameters per PDU flow and SDF

o Introduction of Required Bit Rate parameter for any kind PDU flow (regardless if "GBR" or "nonGBR" type).

o A single priority parameter per PDU flow for admission and QoS targets (delay, bitrate etc.) fulfilment.

o Decoupling of the PDU flow priority for QoS targets fulfilment from the delivery characteristics per flow

o Option for explicit QoS targets (delay, bitrate etc.) Those enhancements aim to simplify configuration, improve the predictability of the effects of QoS differentiation and limit the proliferation of standardized QCI values. Looking at further aspects of embodiments consistent with the invention,

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. In particular, any of the nodes described above (e.g., PCRF) can be provisioned with 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. 8, however, is programmable circuitry, comprising a processor 903 coupled to one or more memory devices 905 (e.g., Random Access Memory, Magnetic Disc Drives, Optical Disk Drives, Read Only Memory, etc.) and to an interface 907 to other elements within the same or a different space. The interface 907 enables bidirectional communication with those other elements. 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 various embodiments provide a number of advantages over conventional technology. For example:

• 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.

With well-defined service requirement parameters, 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. There are further advantages with requirements: measurement method defined, minimum bitrate for all bearers, etc.

By setting a separate priority parameter that defines how important it is to fulfill the service requirements of a flow, it is possible to prioritize a data flow based on both service and subscription. Also, since the parameter is used for both admission and congestion control, as well as packet forwarding, a consistent treatment is guaranteed in different network algorithms.

By setting a second priority parameter that defines how important it is to get more than minimum requirements, it is possible to define meaningful policies for flexible services with low minimum requirements, like web surfing, or variable rate video. If the parameter is defined as a relative priority, it is possible to define how large portion of the extra resources that each flow should get.

The invention has been described with reference to particular embodiments. However, it will be readily apparent to those skilled in the art that it is possible to embody the invention in specific forms other than those of the embodiment described above. For example, various nodes have been described and illustrated in the figures, and to facilitate an understanding of the technology each of these is described and depicted as stand-alone hardware. However, in some but not necessarily all embodiments, the functionality of any given node can be distributed among a plurality of hardware components connected by means of a network.

Thus, the described embodiments are merely illustrative and should not be considered restrictive in any way. The scope of the invention is further illustrated by the following listed aspects, and all variations and equivalents which fall within the range of these aspects are intended to be embraced therein.

In fig. 10, there is shown 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). In fig. 10, there is moreover 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.

There is also shown 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. Further, 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.

Moreover, a core network control plane node or entity CN CP is provided 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.

In fig. 14, there is moreover shown 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.

It is understood that the term node in this application can also be understood as entity.

The methods discussed above may alternatively be implemented by means of a system based on network functions virtualization. In fig. 11 , further embodiments of the invention are implemented by means of such a network function virtualization system, NFVS, formed on e.g. general purpose servers, standard storage and switches. 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

Orchestrator, ORCH, a VNF manager, VNF MGR, and a virtualized

Infrastructure manager, VIRT INFRA. 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) and 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.

Aspects of inventive embodiments

1. A network node that:

receives, from an application or from another node, a request for network service, wherein the request includes:

an indication of service requirements; and

an indication of service preferred network treatment when the service requirements are not met; and

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.

3. The network node as in any of 1 through 2, wherein the service preferred network treatment is for the network to always admit the service, regardless of whether the service requirements can be met.

4. The network node as in any of 1 through 3, wherein the service preferred network treatment is for the network to only admit the service if the service requirements can be met. 5. The network node as in any of 1 through 4, wherein the service preferred network treatment is for the network to continue to deliver the service regardless of whether the service requirements can be met, and to do so without informing the application and/or the other node.

6. The network node as in any of 1 through 5, wherein the service preferred network treatment is for the network to continue to deliver regardless of whether the service requirements can be met, and to inform the application and/or the other node that the requirements are not met.

7. The network node as in any of 1 through 6, wherein the service preferred network treatment is for the network to not continue to deliver the service if the service requirements cannot be met, and to inform the application and/or the other node that the delivery is off.

8. The network node as in any of 1 through 7, wherein the service preferred network treatment is for the network to inform the application and/or the other node in advance that the service requirements will not be met, wherein the service preferred network treatment specifies the required time in advance that the information about service requirements not being met is to be provided to the application and/or the other node.

9. The network node as in any of 1 through 8, wherein the request for network service is a bearer establishment request.

10. The network node as in any of 1 through 9, wherein the service requirements include Quality of Service targets.

11. The network node as in any of 1 through 10, wherein the request includes an indication of priority for fulfilling the service requirements. 12. The network node as in any of 1 through 1 1 , wherein the request includes an indication of a priority to get more than the required service requirements.

13. A method performed in a packet inspection node, wherein the method performs the functionality stated in any one of aspects 1 through 12.

14. Method for a policy node in a communication system comprising an access node (AN)

a core network user plane, CNUP, (CN_UP) node

a core network control plane, 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),

the method comprising

- upon receiving, from the AP, a request (3, 201; 302; 402) for network service, wherein the request (3, 201; 302; 402) includes:

- - an indication of service requirements requested by the AP; and

- - an indication of service preferred network treatment when the service requirements are not, the indication comprising information on whether the application should be notified (4, 404) when the requested service requirements cannot be met. 15. Method according to 14, wherein the service requirements comprise Quality of Service targets.

16. 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.

18. Method for a communication system comprising

an access node (AN)

a core network user plane, CNUP, (CN_UP) node

a core network control plane, 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 policy node,

wherein the (policy/ PCRF) policy node

- 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 requirements requested by the AP; and

- - an indication of service preferred network treatment when the service requirements are not, the indication comprising information on whether the application (AP) should be notified (4, 404) when the requested service requirements cannot be met;

the core network control plane node (CN CP; PGW)

- acting (403) in accordance with the service preferred network treatment when the service requirements are not met (308, 310, 313).

19. Method according to 18, the communication system being configured to monitor fulfillment of the service requirements in order to detect when the service requirements are not met. 20. Method according to any of 18 or 19, wherein the service preferred network treatment constitutes at least one of always admit the service, regardless of whether the service requirements are met;

only admit the service if the service requirements are met;

continue to deliver the service regardless of whether the service requirements are met, and do not inform the application;

continue to deliver the service regardless of whether the service requirements are met, but inform the application that the requirements are not being met;

do not continue to deliver the service if the service requirements are not met, and inform the application that the service delivery is off.

21. Method according to any of 18 - 20, wherein the service requirements, define

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).

22. Method according to any of 18 - 21, wherein

the PDU flows being realized in the UP layer and are constituting a logical packet transport,

one or more Service Data flows, SDF, 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. 23. Method according to 22, wherein

based on

- the subscription,

- AP requirements input information from the service layer, that is, the application

- QoS configuration as well as

- operator policies, the policy node is deciding, that is, authorizing, network authorized QoS parameters

- for the PDU session,

- for Service-specific and non-Service-specific PDU flows and

- for the SDF.

24. Method according to 22 or 23, wherein

the AP requirements input information (3) from the application comprises moreover

- a service identification,

- a service behavior, the network can expect from the application, and

- service requirements requested by the application.

25. Method according to 24, wherein

the service requirements requested by the application comprises

- a minimum bitrate per SDF that is required for the service to be delivered with sufficient Quality of Experience, QoE,

- delay requirements,

- priority between different SDFs within the AP,

- requested network behavior with respect to admission, retention and notification (9, 10).

26. Program or computer program product comprising instructions according to any of 14 - 25.