WO2023078579A1

WO2023078579A1 - Af influence on idle service data flow timer

Info

Publication number: WO2023078579A1
Application number: PCT/EP2021/087854
Authority: WO
Inventors: Emiliano Merino Vazquez; Miguel Angel Garcia Martin; Miguel Angel MUÑOZ DE LA TORRE ALONSO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-11-03
Filing date: 2021-12-30
Publication date: 2023-05-11

Abstract

AF influence on idle service data flow timerThe present invention relates to a method for handling an application session comprising at least one data flow in a cellular network, the method comprising at a policy control entity (200) of the cellular network with the steps of receiving, from a Network Function, NF, entity (100) of the cellular network, an authorization request requesting an authorization of the application session, the authorization request comprising an indication indicating that an idle timer is supported for the application session, and determining, based on the authorization request, a policy of the application session with a timer value for the idle timer, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive, and transmitting the policy to a session management entity of the cellular network, the policy including the timer value for the at least one data flow of the application session.

Description

AF influence on idle service data flow timer

Technical Field

The present application relates to a method for handling an application session comprising at least one data flow in a cellular network as carried out by a policy control entity, a session management entity, a user plane entity and a network function. Furthermore, the corresponding entities are provided, a system comprising at least two of the entities and a computer program comprising program code. Last but not least a carrier comprising the computer program is provided.

Background

Fig. 1 shows a 5G New Radio, NR, architecture with service based interfaces in a Service Based Architecture (SBA). Service Based Interfaces are represented in the format Nxyz, such as Nsmf, and point to point interfaces in the format Nx, such as N4.

The 5G core network part 5 comprises a Network Slice Selection Function (NSSF) 18, a Network Exposure Function (NEF) 19, a Network Repository Function (NRF) 10, a Policy Control Function (PCF) 11 , a Unified Data Management (UDM) 12, an Application Function (AF) 13, an Authentication Server Function (AUSF) 18, an Access and Mobility Management Function (AMF) 16, and a Session Management Function (SMF) 17. Furthermore a Unified Data Repository, UDR, 14 and a Network Data Analytics Function 15 is provided. Having service based interfaces in the 5G Core Control Plane (CP), implies that the Network Functions (NFs) in the 5G Core CP provide services that are consumed by other NFs in the 5G Core CP.

A User Equipment (UE) 21 , is connected to the Radio Access Network (RAN) 22, wherein a User Plane Function (UPF) 23 is provided to connect the UE 60 to a Data Network (DN) 24. SBA: In 5G core network architecture, the ‘network elements’ is made available through Application Programming Interfaces (APIs). These ‘network elements’, are defined as Network Functions (NFs), and the architecture where each NF offers one or more service to other NFs is called the Service-Based Architecture, SBA.

In the following some of the relevant functional entities are explained in more detail.

The Application Function (AF) interacts with the 3GPP Core Network, and specifically allows external parties to use the Exposure APIs offered by the network operator.

The Network Exposure Function (NEF) supports different functionality and specifically supports different Exposure APIs.

The Unified Data Repository (UDR) stores data grouped into distinct collections of subscription-related information such as subscription data, policy data, Structured data for exposure, and application data.

The Policy Control Function (PCF) supports unified policy framework to govern network behavior, provides policy rules to Control Plane function(s) to enforce them and accesses subscription information relevant for policy decisions in a Unified Data Repository (UDR), taking the input from the enhanced AF/NEF QoS Exposure API.

The Session Management function (SMF) is in charge of Session Establishment, modify and release, including tunnel maintain between UPF and AF node. It also performs the selection and control of UP function, the configuration of traffic steering at UPF to route traffic to proper destination and the termination of interfaces towards Policy control functions.

The User plane function (UPF) is the anchor point for lntra-/lnter-RAT mobility. It supports, among other functions, the external PDU Session point of interconnect to Data Network, the packet routing & forwarding, packet inspection, user plane part of policy rule enforcement, traffic usage reporting and QoS handling for user plane. The present application applies inter alia to a procedure whereby an Application Function (AF) 13, typically located outside the trust domain of the Mobile (i.e. Cellular) Network, communicates with the Mobile Network for the purpose of adding or modifying one or more Service Data Flows (SDFs) (e.g., IP flows) pertaining to an existing PDU (packet Data Unit) session for a given UE (User Equipment), the Service Data Flows being served with certain Quality of Service parameters, these parameters indicated by the AF. The assumption is that the UE is registered in the network and has already established a PDU session. As a consequence of this PDU session of the UE, the UE is allocated an IP address, which is known to the AF via offline methods (for example, an application in the UE may contact the AF, so the AF knows the IP address of the UE).

The Application Function (AF) 13 requests a certain Quality of Service for one or more Service Data Flows within an existing PDU session. This request is routed from AF via NEF to the PCF 11 . This has the consequence that the proper configuration and resources are created in NEF 19, PCF 11 , SMF 17, UPF 23, RAN 22 and UE 21 , so that the user can enjoy a better Quality of Service QoS (e.g. better bit rate or bandwidth) for the Service Data Flows. These resources are kept in all 5GC network elements and the AF, so that they can be deleted when they are not required (in this case, when they are not used by the UE).

The Quality of Service for a given Service Data Flow (e.g. from the UE IP address towards the AF IP address and vice versa) is applied based on the QoS reference for the Service Data Flow associated to the UE IP Address. If the QoS demands a guaranteed bit rate/bandwidth, it makes the radio access network (RAN) to reserve the resources in radio cells permanently until the applications decide to deactivate/term inate the QoS session.

To protect the network from misusing radio and core network resources, standard implementations in SMF/UPF monitor the PDU session for each UE (where several Service Data Flows are running) and deactivate the PDU session if there is no activity (inactivity timer, as defined in 3GPP). Now, when it comes to a specific Service Data Flow (e.g. carrying conversational video), it is implementation choice to also apply an inactivity timer for Service Data Flows running in the PDU session.

The problem with this (proprietary) monitoring is that the SMF/UPF do not know what is the service running on the Service Data Flow, so the monitoring is done equally for all Service Data Flows (e.g. online gaming video, youtube, messaging, chat, photo exchange). This makes the procedure completely decoupled from the Application, e.g. if a user is having a video call (IP flow for conversational video) and stops sending and receiving video IP packets, there is no point in keeping the radio resources for video since the call is just an audio call. Hence, if the SMF/UPF need to detect this and use low timer values, that might affect other services (e.g. online gaming with chat) which might be more tolerant to absence of IP traffic during some periods of time. However the problem is not restricted to a session having different data flows such as video and audio. The same problem can occur when

Summarizing, the current solution mandates the operator to set a value which might be OK for certain applications but very restrictive for other applications. If applications which are more tolerant to inactivity are deactivated, then the AF needs to reestablish the QoS session again, causing a ping-pong of deactivation/re- establishment of the QoS flows.

Summary

Accordingly, a need exists to overcome the above-mentioned problems and to provide an effective way to control the deactivation of data flows of an application session.

This need is met by the features of the independent claims. Further aspects are described in the dependent claims.

According to a first aspect a method for handling an application session is provided, the application session comprising at least one data flow in a cellular network. A policy control entity of the cellular network receives from a network function of the cellular network, an authorization request requesting an authorization of the application session, wherein the authorization request comprises an indication indicating that an idle timer is supported for the application session. The policy control entity determines, based on the authorization request, a policy of the application session with a timer value for the idle timer. The timer value indicates how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive. Furthermore, the policy control entity transmits the policy to a session management entity of the cellular network, wherein the policy includes the timer value for the at least one data flow of the application session.

Furthermore, the corresponding policy control entity is provided comprising at least one processing unit and a memory wherein the memory contains instructions executable by the at least one processing unit, wherein the policy control entity is operative to work as discussed above or as discussed in further detail below.

As an alternative, the policy control entity comprises a first module configured to receive the authorization request from the network function entity of the cellular network, wherein the request requests the authorization of the application session and wherein the authorization request comprises the indication which indicates that an idle timer is supported for the application session. The policy control entity can comprise a second module configured to determine, based on the authorization request, the policy of the application session with a timer value for the idle timer, and the timer value indicates how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive. The policy control entity can comprise a third module configured to transmit the policy to a session management entity wherein the policy includes the timer value forward the at least one data flow of the application session.

Furthermore, a method for handling the application session with the at least one data flow is provided at a session management entity of the cellular network which receives a policy of the application session from the policy control entity. The policy includes a first indication which indicates that an idle timer is supported for the application session and the first indication further comprises a timer value of the idle timer for at least one data flow with the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive. The session management entity furthermore transmits a handling request to handle the application session to a user plane entity handling the at least one data flow, wherein the handling request comprises a second indication indicating that the idle timer is supported for the application session and wherein the second indication furthermore comprises the timer value of the idle timer for the at least one data flow.

The first indication may correspond to the second indication, however, it is also possible that the session management entity adapts the indication as received from the policy control entity before transmitting it to the user plane entity.

Furthermore, the corresponding session management entity is provided comprising at least one processing unit and a memory wherein the memory contains instructions executable by the at least one processing unit. The session management entity is operative to work as discussed above or as discussed in further detail below.

As an alternative, the session management entity comprises a first module configured to receive the policy of the application session from the policy control entity which includes the indication that an idle timer is supported for the application session, wherein the indication comprises a timer value of the idle timer for the at least one data flow which indicates how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive. The session management entity comprises a second module configured to transmit the handling request to handle the application session with the at least one data flow to the user plane entity. This handling request comprises the indication which indicates that the idle timer is supported for the application session and the indication indicates the timer value of the added idle timer for the at least one data flow.

Furthermore, a method for handling the application session with the at least one data flow in the cellular network is provided at a user plane entity, wherein the user plane entity of the cellular network which is configured to handle the at least one data flow receives the handling request to handle the application session with the at least one data flow from the session management entity. The handling request comprises the indication which indicates that an idle timer is supported for the application session and the indication further comprises a timer value of the idle timer for the at least one data flow which indicates how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive. The user plane entity is furthermore configured to monitor whether the at least one data flow is inactive using the timer value of the idle timer and if the user plane entity detects based on the timer value that the at least one data flow is inactive, it transmits a session report to the session management entity, by which the session management entity is informed of the fact that the at least one data flow is inactive.

Furthermore, the corresponding user plane entity is provided comprising at least one processing unit and a memory which contains instructions executable by the at least one processing unit. The user plane entity is operative to work as discussed above or as discussed in further detail below.

As an alternative, the user plane entity comprises a first module configured to receive the handling request from the session management entity of the cellular network to handle the application session with the at least one data flow, wherein this handling request comprises the indication which indicates that the idle timer is supported for the application. The indication furthermore includes the timer value of the idle timer for the at least one data flow which indicates how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive. The user plane entity comprises a second module configured to monitor whether the at least one data flow is inactive using the timer value of the idle timer and if the second module detects based on the timer value that the at least one data flow is inactive, a third module of the user plane entity can transmit a session report to the session management entity by which the session management entity is informed of the fact that the at least one data flow is inactive.

Furthermore, a method for handling the application session with the at least one data flow is provided wherein a network function entity of the cellular network transmits an authorization request to a policy control entity of the cellular network. This authorization request requests the authorization of an application session and comprises an indication which indicates that the idle timer is supported for the application session.

Furthermore, the corresponding network function entity is provided which comprises at least one processing unit and a memory, wherein the memory contains instructions executable by the at least one processing unit, the network function entity is operative to work as discussed above or as discussed in further detail below.

The network function entity can as an alternative contain a first module configured to transmit the authorization request to the policy control entity which requests the authorization of the application session and which comprises the indication indicating that the idle timer is supported for the application session.

Furthermore, a system is provided comprising at least two of the entities selected from the group of entities mentioned above, namely the policy control entity, the session management entity, and the user plane entity or the application function entity. Furthermore, a computer program comprising program code to be executed by at least one processing unit of a policy control entity, a session management entity, a user plane entity, or an application function entity is provided, wherein execution of the program code causes the at least one processing unit to carry out the above described methods.

Finally, a carrier comprising the computer program is provided, wherein the carrier is one of an electronic signal, optical signal, radio signal, and computer readable storage medium.

The application session could comprise a first data flow comprising audio data and a second data flow comprising video data, wherein a first timer value for the idle timer is provided for the first data flow, and a second timer value is provided for the second data flow, the timer values indicating how long the corresponding idle timer should tolerate the absence of data in the corresponding flow before finally deciding that the corresponding flow is inactive. However, it should be understood that the application session could also only contain a single data flow, and the timer value is provided for this data flow of the application session.

It is to be understood that the features mentioned above and features yet to be explained below can be used not only in the respective combinations indicated, but also in other combinations or in isolation without departing from the scope of the present invention. Features of the above-mentioned aspects and embodiments described below may be combined with each other in other embodiments unless explicitly mentioned otherwise.

Brief Description of the Drawings

The foregoing and additional features and effects of the application will become apparent from the following detailed description when read in conjunction with the accompanying drawings in which like reference numerals refer to like elements.

Fig. 1 shows a schematic view of the 5G architecture as defined by 3GPP.

Fig. 2 shows a message exchange between the involved entities in a situation where an application function initiates the use of an idle timer for a data flow and the missing data flow as detected with the idle timer is reported back to the application function. Fig. 3 shows a message exchange between the involved entities in a situation where the application function decides how to react to the detected missing data flow.

Fig. 4 shows a message exchange between the involved entities in a situation similar to Figs. 2 and 3 where the application function does not support the provision of timer values for the inactivity or idle timer.

Fig. 5 shows a message exchange between the involved entities where the policy control entity determines the timer value based on a local configuration.

Fig. 6 shows a message exchange between the involved entities where the application function also provides a suggested action to be applied by the cellular network when the idle timer expires.

Fig. 7 shows an example message flow of a method carried out at a network function when a flow specific idle timer is used as described in connection with Fig. 2 to 6.

Fig. 8 shows an example message flow carried out by a policy control entity in the message exchange described in Figs. 2 to 6.

Fig. 9 shows an example flowchart of a method carried out by a session management entity in the message exchange described in connection with Figs. 2 to 6.

Fig. 10 shows an example flowchart of a method carried out by a user plane entity handling the data flow using the idle timer and a time value.

Fig. 11 shows an example schematic representation of an application function entity involved in the message exchange discussed in connection with Figs. 2 to 6.

Fig. 12 shows another example schematic representation of the application function entity shown in Fig. 11 . Fig. 13 shows an example schematic representation of a policy control entity in the message exchange discussed in connection with Figs. 2 to 6.

Fig. 14 shows another example schematic representation of a policy control entity in the message exchange discussed in connection with Figs. 2 to 6.

Fig. 15 shows an example schematic representation of a session management entity used in the message exchange discussed in connection with Figs. 2 to 6.

Fig.16 shows another example schematic representation of a session management entity used in a message exchange discussed in connection with Figs. 2 to 6.

Fig. 17 shows an example schematic representation of a user plane entity used in the message exchange discussed in connection with Figs. 2 to 6.

Fig. 18 shows another example schematic representation of a user plane entity used in the message exchange discussed in connection with Figs. 2 to 6.

Detailed Description

In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are to be illustrative only.

The drawings are to be regarded as being schematic representations, and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components of physical or functional units shown in the drawings and described hereinafter may also be implemented by an indirect connection or coupling. A coupling between components may be established over a wired or wireless connection. Functional blocks may be implemented in hardware, software, firmware, or a combination thereof.

Within the context of the present application, the term “mobile entity” or “user equipment” (UE) refers to a device for instance used by a person (i.e. a user) for his or her personal communication. It can be a telephone type of device, for example a telephone or a Session Initiating Protocol (SIP) or Voice over IP (VoIP) phone, cellular telephone, a mobile station, cordless phone, or a personal digital assistant type of device like laptop, notebook, notepad, tablet equipped with a wireless data connection. The UE may also be associated with non-humans like animals, plants, or machines. A UE may be equipped with a SIM (Subscriber Identity Module) or electronic-SIM comprising unique identities such as IMSI (International Mobile Subscriber Identity), TMSI (Temporary Mobile Subscriber Identity), or GUTI (Globally Unique Temporary UE Identity) associated with the user using the UE. The presence of a SIM within a UE customizes the UE uniquely with a subscription of the user.

For the sake of clarity, it is noted that there is a difference but also a tight connection between a user and a subscriber. A user gets access to a network by acquiring a subscription to the network and by that becomes a subscriber within the network. The network then recognizes the subscriber (e.g. by IMSI, TMSI or GUTI or the like) and uses the associated subscription to identify related subscriber data. A user is the actual user of the UE, and the user may also be the one owning the subscription, but the user and the owner of the subscription may also be different. E.g. the subscription owner may be the parent, and the actual user of the UE could be a child of that parent.

As can be deduced from the following, the solution discussed below allows the AF to suggest or recommend an idle timer (corresponding to a sort of inactivity timer) for the Data Flows of an application session on an individual basis, so that inactive flows are either reported to AF (and rely on the AF to terminate the flows) or let the cellular network (e.g. based on AF suggested policy) deactivate those idle Service Data Flows, also called data flows hereinafter, when they have been idle for a longer time that the one recommended for the AF.

Hence, by means of new supported features in the network and AF, the core network e.g. 5GC is programmable when it comes to idle Service Data Flows detection, since the timers are now exposed to Apps instead of preconfigured in the network in a blind and equal manner for all flows, regardless of the service/type of data being sent over the Service Data Flow.

The solution is also applicable to PDU sessions of non-IP type (for loT (Internet of Things) NIDD) and Ethernet PDU sessions. It is also applicable to Application Identifiers known to the UPF (Appld).

In a first solution, when the AF requests the establishment or modification of Service Data Flows of a PDU session with a certain QoS, the AF suggests an idle timer (sort of inactivity timer) for the Service Data Flows, so that flows that are in idle state when the specified idle timer fires (i.e. expires), are either reported to AF (and rely on the AF to terminate the Service Data Flows) or let the network (based on AF suggested policy) deactivate those idle Service Data Flows when they have been idle for a longer time that the one recommended for the AF.

The sequence diagram of Figs 2 to 5 discussed below apply to the first solution, where the event “IDLE_FLOW_DETECTED” is reported to an AF 50 (and the AF previously subscribes to that event), so AF is the one in charge to take the action:

• Terminate the QoS session for that flow, by AF triggering e.g. Nnef_AFSessionWithQoS (HTTPS DELETE), and/or

• Terminate the flow (e.g. by AF/AS triggering a TCP FIN or TCP RST towards the UE application client). When the flows are (explicitly) terminated, the network entities (UPF, RAN) will release the associated resources (e.g. DPI in UPF will release the resources associated to that flow, resulting in memory savings.

The sequence diagram in Fig. 6 applies to a second solution, where the AF 50 provides a suggested action (e.g. deactivate_SD_flow) to be applied by the network when the idle timer expires for that Data Flow. This avoids the need of a local policy in the network (in any case, if the suggested action is not present, a network local policy might be applied). In this second solution, the network entity detecting idle flow (e.g. UPF), based on the AF suggested action, releases the resources (at the time idle flow is detected) and/or terminates the Service Data Flow, e.g. by UPF triggering a TCP RST towards both endpoints (AF/AS and UE application client). This might be used by RAN to release the RAN resources associated to that flow (e.g. RAN scheduler will no longer prioritize that flow).

Figs. 2 to 5 depict the first option of the proposed solution.

The examples below exemplify the creation of a PDU session used for establishing a multimedia session, where the session is composed for different Service Data Flows, namely: signaling (e.g., SIP), audio stream, and video stream. The solution is generally applicable to any PDU session composed of one or several Service Data Flows.

The flow in Fig. 2 describes a solution where an Application Function (AF) 50, in this case located outside the cellular's Network Operator's trust domain, requests the establishment or modification of Service Data Flows within an existing PDU session, the said Service Data Flows with a given Quality of Service (e.g., latency or jitter), towards a UE 21. This could be, for example, a central control and command center establishing a multimedia session with audio and video towards one of its mobile units.

In order to establish the multimedia session and request the network to reserve the

RECTIFIED SHEET (RULE 91) ISA/EP required resources, the AF 50 in Step S12 sends a reservation request e.g. an AF Session with QoS create request message to the NEF 100. This request includes an identification of the AF itself, the IP address of the UE, a reference to the desired QoS, and a description of the needed Service Data Flows. This request also includes an indication that the AF supports separate idle timers per flow, and, per each desired Service Data Flow, a suggested idle timer value.

Upon reception of the message in step S12, the NEF 100, in step S13, assigns a transaction identifier and authorizes that this AF is duly authorized to request resource reservation as per contractual agreements with the MNO (Mobile Network Operator). The NEF 100 also verifies that the AF 50 is authorized to influence the management of idle IP flows, otherwise, the request is rejected, however this is not shown in Fig. 2.

Subsequently, NEF 100 establishes contact with the PCF 200 for requesting the creation or modification of Service Data Flows within the PDU session. This is done by NEF 100 sending an authorization request, e.g. a Npcf_PolicyAuthorization_Create request message (step S14). This request includes the IP address of the UE to which the PDU session should be established, the AF application identifier, a description of the Data Flows that should be added or modified, for example Data Flow 1 containing audio, Data Flow 2 containing video. One aspect is that this request also includes an indication for the support of flow idle timers as well as the suggested Inactivity timer values for each Service Data Flow, as received from the AF 50.

The PCF 200, in step S15, evaluates its local policies and determines, among other aspects, whether the suggested idle timer can be monitored per Service Data Flow, and whether the suggested values of idle timers can be honored. For example, the PCF 200 may modify the values of the suggested idle timers due to local policy of the MNO.

With this, PCF 200 instructs SMF with a new policy, e.g. to modify the existing PDU session, in step S16, according to the parameters determined by the PCF. The PCF 200 could send an Npcf_SMPolicyControl_UpdateNotify request to the SMF including a new set of Policy and Charging Control (PCC) rules. Each PCC rule of the set includes a description of the new or modified Service Data Flow. One aspect is that each PCC rule also includes an indication for the support of flow idle timers as well as the suggested Inactivity timer value for each Service Data Flow, as determined by the PCF.

The SMF 300 sends a handling request e.g. Packet Flow Control Protocol (PFCP) Session Modification Request to the LIPF400 in step S17, indicating the modification of a PDU session, by adding or creating new SDFs. One aspect is that this message also includes an indication for the support of flow idle timers as well as the suggested Inactivity timer values for each Service Data Flow, as determined by the PCF.

In step S18 the UPF 400 and the UE 21 establish the new UPF flows. The UPF 400 is configured to monitor the inactivity timer for each flow, according to the idle timers received from PCF.

In step S19, the SMF 300 sends an Npcf_SMPolicyAuthorization_Update request to the PCF indicating the success of the creation or modification of the Service Data Flows requested in step 6. This message also includes, as one aspect, that the Flow idle timer feature is supported, as well as the effective inactivity timers determined by PCF 200 (in step S15) for each of the Service Data Flows.

In step S20, the PCF 200 sends an Npcf_PolicyAuthorization_Notify request to the NEF 100 indicating the success of the creation or modification of the Service Data Flows requested in step S14. This message also includes, as one aspect, that the Flow idle timer feature is supported, as well as the effective inactivity timers determined by PCF (in step S15) for each of the Service Data Flows.

In step S21 , NEF 100 sends an Nnef_AFSessionWithQoS_Notify request to the AF. This message also includes, as one aspect, that the Flow idle timer feature is supported, as well as the effective inactivity timers determined by PCF 300 for each of the Data Flows.

At this point in time, both AF 50 and NEF 100 are aware that the idle timer per flow is supported end-to-end in all the relevant network functions of the network.

Since the requested Service Data Flows are established, the UE 21 and AF 50 may start their communication. In step S23, one of the Service Data Flows, for example, the one carrying a video stream, becomes idle. This might be, for example, due to the user disconnecting the camera from an ongoing multimedia call.

After a time determined by the inactivity timer where no packets are sent or received in this Service Data Flow, UPF 400 determines that the flow should be set to inactive, as indicated in step S24.

In step S25 the UPF 400, upon detection of an idle flow, sends a session report such as a PFCP Session Report Request to the SMF, indicating the affected flow and its status. As one aspect, the message includes a failure code indicating the reason, in this case, IDLE_FLOW_DETECTED. The SMF sends an appropriate response in step S26.

In step S26 the SMF 300 sends a notification to the PCF 200, e.g. in an Npcf_SMPolicyAuthorization_Update request message, including a new set of affected (modified) PCC rules, each PCC rule describing a modified Service Data Flows of the PDU session. Each Service Data Flow includes a status information. The flow that was detected as idle is marked with the status inactive. As one aspect, the message includes a failure code indicating the reason for the new PCC rule, in this case, IDLE_FLOW_DETECTED.

In step S27 the PCF 200 sends an Npcf_PolicyAuthorization_Notify request to the NEF indicating, as novel aspects, a new event of IDLE_FLOW_DETECTED and also indicating that the video flow has reached the status INACTIVE. In step S28 the NEF 100 sends an AF Session with QoS Notify request to the AF 50 indicating, as one aspects, a new event of IDLE_FLOW_DETECTED and also indicating that the video flow has reached the status INACTIVE. At this point in time, the AF 50 may take additional actions for freeing resources previously in used by the inactivated service data flow.

In Fig. 2 the NEF is provided as the AF 50 may not be in the trusted domain. If the AF 50 is in the trusted domain, the NEF may not be involved and the PCF may directly communicate to with the AF so that step S12 is from the AF 50 directly to the PCF 200.

The description of this solution continues in Fig. 3.

In step S29, the AF 50 decides whether to end the total established session with QoS or just order the removal of the inactive flows. In this example the AF 50 decides to just remove the inactive flow, in this case, the video flow. Therefore, the AF 50 sends an AF session with QoS Update Request (step 30), including a reference to the session that is to be updated and the flow reference to be removed (flow-Video in this example).

The NEF 100 receives this message of step S30 and sends a policy update request message, e.g. an Npcf_PolicyAuthorization_Update request, in step S31 , including the Application session context ID that uniquely identifies the session to be modified, and a reference to the flow -Video to be removed..

In step S32 PCF 200 sends a policy control message e.g. an Npcf_SMPolicyControl_UpdateNotify request to the SMF 300, including a PDU session ID, and instructions for removing the PCC rule describing flow -Video, in this example.

In step S33 the SMF 300 sends a session modification request e.g. PFCP Session Modification Request to the UPF 400 including instructions for removing the Packet Detection Rules corresponding to flow -Video, in this example. Once done, the AF session with QoS initiated by the AF no longer comprises a video flow, just an audio flow.

Fig. 4 illustrates a variant, where the AF 50 need not support the feature of individual inactivity timers per Service Data Flow. Instead, upon reception of a regular AF Session with QoS Create request in step S42, the NEF 100, based on local policy for the received QoS reference, determines the appropriate or typical values of the idle timers for each of the service data flow, even if the AF did not indicate any idle timer (S43). The NEF 100 , in step S44 (which is equal to that of the Fig. 2), creates a request towards the PCF 100 including the support for the inactivity timer values for each Service Data Flow feature, as well as indicating a suggested inactivity timer. After Step S44 the method continues as described above in Fig. 2 and 3 so with steps S15 and the following.

Fig. 5 illustrates another variant, where neither the AF 50 nor the NEF 100 provide support for the inactivity timer values for each Service Data Flow feature. Accordingly the session request in step S52 from the AF just indicaes that the idle timer is supported, and the same is true for the policy authorization request of step S53. Instead, the PCF 200 , upon reception of a Npcf_PolicyAuthorization request in step S53, determines the idle timers based on local configuration. The step of determining the local timers may include retrieving them from a repository such as a UDR, as indicated in step S54.. IN step S55 the PCF evaluates policies and determines based on the request from the NEF or AF and the provisioned policies that an idle timer should be provided and should monitor each flow.

Step S56 and further steps correspond to the steps S16 onwards of Fig. 2.

Fig. 6 shows a sequence diagram according to the second variant of the invention.

The main differences with respect the first variant mentioned in Figs. 2 to 5 are described in the next paragraphs.

RECTIFIED SHEET (RULE 91) ISA/EP If the steps are not discussed in detail, it means that the corresponding steps are identical to the steps explained in connection with Fig. 2.

In step S62, the AF includes, in addition to the information present in step S12 of Fig.

2, a suggested action set such as to “Deactivate SD Flow”. This provides an indication that, should the inactivity timer fire for any of the flows, the network can immediately deactivate such flow from the session. Step S63 corresponds to step S13.

In step S64, the NEF 100 includes the suggested action “Deactivate SD Flow” in the Npcf_PolicyAuthorizaiton_Create request to the PCF in addition to the information present in step S14. Step S65 corresponds to step S15.

In step S66, the PCF includes the suggested action “Deactivate SD Flow” in the Npcf_SMPolicyControl_UpdateNotify request to the SMF. Otherwise this step corresponds to step S16.

In step S67, the SMF 300 includes the suggested action “Deactivate SD Flow” in the PCFP Session Modification Request to the UPF 400. Steps S68 to S73 correspond to steps S18 to S23 of Fig. 2

In step S74, upon detection of inactivity for one of the flows and firing its inactivity timer, the UPF 400 applies the suggested action of removing the affected flow from the session.

In steps S75 through S78, the status of the flow is set to “removed” (instead of “inactive” in the solution of Fig. 2).

Similarly to the first solution, steps S75 and S76 include the new failure code set to IDLE_FLOW_DETECTED, for indicating the reason that trigger the current status of

RECTIFIED SHEET (RULE 91) ISA/EP the flow. Similarly to the first solution, steps S77 and S78 include the event code set to IDLE_FLOW_DETECTED.

Upon reception of the step S78, the AF 50 need not take any action, since the detected inactive flow has been automatically detected and removed from the session as per suggested action.

In Fig. 3 to 6 the NEF is provided as the AF 50 may not be in the trusted domain. If the AF 50 is in the trusted domain, the NEF may not be involved and the PCF may directly communicate to with the AF or the AF may directly send the messages to the PCF instead of the NEF.

Fig. 7 summarizes some of the steps carried out by a network function entity, (network function) involved in the different solutions discussed above. The network function entity can be an exposure entity such as the NEF 100 mentioned in Figs. 2 to 6 or can be the application function 50 in case the NEF is not provided. The first step is optional and occurs in the situation when the network function entity is the NEF 100. In this step S81 , the NEF receives a reservation request for the reservation of resources for the application session, wherein the reservation request comprises an indication indicating that an idle timer is supported for the application session and the idle timer is responsive to an absence of data in the at least one data flow This was discussed above in steps S12, S30, S42, S52 and S62. In step S82 the network function, be it the NEF 100 or the application function 50, transmits an authorization request to a policy control entity 200 wherein this authorization request comprises an indication which indicates that an idle timer is supported for the application session with its corresponding data flow.

Fig. 8 summarizes some of the main steps carried out by the policy control entity 200 in the different situations discussed in connection with Figs. 2 to 6. In step S91 , the policy control entity receives from the network function entity, the NEF or the application function, the authorization request which it requests the authorization of the application session and this authorization request comprises the indication which indicates that an idle timer is supported for the application session. This step was discussed above in detail in step S14, S31 , S53 or step S64. In step S92, based on the authorization request, the policy control entity 200 determines a policy for the application session with a timer value for the idle timer. This timer value indicates how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive. This step was discussed above in detail in steps S15, S65. Furthermore, in step S93 the policy control entity 200 transmits the policy with the determined timer value to the session management entity as discussed above steps S16, or S66.

Fig. 9 summarizes some of the steps carried out by the session management entity or SMF in the situations mentioned in connection with Figs. 2 to 6. The session management entity 300 receives the policy from the policy control entity 200, wherein this policy includes the indication which indicates that an idle timer supported there is indication furthermore includes the timer value of the idle timer for the at least one data flow. The timer value indicates when a user plane entity handling the actual data flow should determine finally that the data flow is inactive when no data is received. This step S101 was discussed above in detail in steps S16 or S66. Furthermore, the session management entity, in step S102 transmits a handling request to handle the application session to the user plane entity, wherein this handling request includes the indication that the idle timer supported for the application session with its corresponding data flow and the indication further contains the timer value of the idle timer. This was discussed above in connection with steps S17 or S67.

Fig. 10 summarizes some of the main steps carried out at the user plane entity 400 in the situations mentioned in Figs. 2 to 6. The user plane entity 400 receives in step S110 the handling request from the session management entity 300 to handle the application session with the at least one data flow as discussed above in steps S17 and S67. The Handling request comprise the indication of the support of the idle timer and comprises the corresponding timer value of the idle timer for each of the data flows. In step S111 the user plane entity monitors the timer value of the idle timer and determines whether the at least one data flow is inactive based on the timer value ( see S24 or S74). It is detected that the corresponding data flow is inactive when the timer value expires and as a consequence in step S112, a session report is transmitted to the session management entity 300 by which the session management entity is informed of the fact that the at least one data flow is inactive ( see S25 and S75).

Fig. 11 shows a schematic architectural view of a network function entity which may be implemented as network exposure function, NEF, or as application function 50. In the example shown, the network function entity is implemented as network exposure entity 100. The entity 100 comprises an interface or input/output 110 which is provided for transmitting user data or control messages to other entities and which is provided for receiving user data or control messages from other entities. Entity 100 may transmit the authorization request including the indication of the idle timer and may receive from the AF 50 if implemented as NEF, the request to reserve resources for the application session which includes the indication that the idle timer is supported. Entity 100 furthermore comprises a processing unit 120 which is responsible for the operation of entity 100. The processing unit 120 comprises one or more processors and can carry out instructions stored on a memory 130, wherein the memory may be any memory such as a read-only memory, a random access memory, a mass storage, a hard disk, or the like. The memory can furthermore include suitable program code to be executed by the processing unit 120 so as to implement the above-described functionalities in which entity 100 is involved.

Fig. 12 shows another architectural view of the network function entity implemented as application function or as network exposure function. In the second case entity 500 comprises a first module configured to receive the reservation request for resources for at least one data flow including the indication that the idle timer is supported. This module 510 is not provided when entity 500 is implemented as application function 50. In both cases, entity 500 comprises a module 520 configured to transmit the authorization request to the policy control entity including the indication that the idle timer is supported. Fig. 13 shows a schematic architectural view of a policy control entity which can carry out the determination of the timer value as discussed above. The policy control entity 200 comprises an interface configured to transmit user data or control messages to other entities and configured to receive user data or control messages from other entities. Interface 210 is at least configured to receive the authorization request with the indication and configured to transmit the policy including the timer value for the corresponding data flows. The policy control entity 200 furthermore comprises a processing unit 220 which is responsible for the operation of the policy control entity 200. The processing unit 220 comprises one or more processors and can carry out instructions stored on a memory 230, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory 230 can furthermore include suitable program code to be executed by the processing unit 220 so as to implement the above-described functionalities in which the policy control entity is involved.

Fig. 14 shows another schematic architectural view of a policy control entity 600 comprising a first module 610 configured to receive the authorization request for a session with at least one data flow, this request comprising the indication that the idle timer is supported. Module 620 is configured to determine the policy for the corresponding data flow and the timer value which indicates how long the timer should tolerate the absence of any data. A module 630 is provided configured to transmit the policy and the corresponding timer value to the session management entity.

Fig. 15 shows a schematic architectural view of a session management entity 300 which can operate as discussed above in connection with Figs. 2 to 6. Session management entity 300 comprises an interface or input output 310 configured to transmit user data or control messages from other entities and configured to receive user data or control messages from other entities. The interface receives the policy for the data flow including the timer value and the interface is configured to transmit at least the request to the user plane entity to handle the data flow including the support for the timer value and the corresponding timer value. The session management entity furthermore comprises a processing unit 320 which is responsible for the operation of entity 300. The processing unit 320 comprises one or more processors and can carry out instructions stored by memory 330, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory can furthermore include suitable program code to be executed by the processing unit 320 so as to implement the above-described functionalities in which the session management entity is involved.

Fig. 16 shows a further schematic architectural view of a session management entity 700 including a first module 710 configured to receive the policy with the indication of the idle timer and the corresponding timer value. Module 720 is configured to transmit the handling request to the user plane entity including the indication of the idle timer the corresponding timer value to be used by the user plane entity.

Fig. 17 shows a schematic architectural view of a user plane entity 400 which can carry out the above discussed steps of monitoring the presence of the data flow based on the idle timer. The user plane entity 400 comprises an interface configured to transmit user data or control messages and configured to receive user data or control messages from other entities. Interface 410 receives and transmits the data packets of the data flow and receives the handling request including the indication of the idle timer and the timer value. Interface 410 is furthermore configured to transmit a session report which indicates that the data flow is inactive when the idle timer has expired. The user plane entity furthermore comprises a processing unit 420 which is responsible for the operation of the user plane entity. The processing unit 420 can comprise one or more processors and can carry out instructions stored on a memory 430, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk, or the like. The memory can furthermore include suitable program code to be executed by the processing unit 420 so as to implement the above-described functionalities in which the user plane entity is involved. From the above said some general conclusions can be drawn for the different entities.

As far as the policy control entity is concerned, the indication as received from the NEF 100 or the application function 50 can comprise a suggested action that should be carried out when the inactivity of the at least one flow is detected. The policy control entity can then determine whether the application entity such as the application entity is authorized to influence the at least one application session in the cellular network. If this is the case the suggested action may be added to the policy transmitted to the session management entity 300. As discussed in connection with Fig. 3 in step S52, the request already included the suggested action. It is then checked whether the application entity is authorized to influence the at least one application session in the cellular network and if this is the case, the suggested action is added to the policy transmitted to the session management entity.

The indication as received can already contain a proposed timer value and here, for determining the timer value the policy control entity checks whether the proposed timer value is allowed for the application session.

Furthermore, it is possible that the policy control entity accesses a subscriber database of the cellular network for a subscriber involved in the application session in order to determine the timer value for the subscriber. The situation was discussed in connection with Fig. 5.

Furthermore, the policy control entity can receive a notification from the session management entity 300 wherein the notification indicates an absence of the data in the at least one data flow and a further notification is then transmitted to the network function entity which indicates an absence of data and the at least one data flow. This was discussed in connection with steps S26 and S27.

As far as the session management entity is concerned, the session management entity can receive a session report from the user plane entity which informs the session management entity of the fact that the at least one data flow is inactive. Furthermore, an update request can be transmitted to the policy control entity wherein this update request includes as a reason for the update request that the at least one data flow is inactive. This was discussed above in steps S15 and S16 of Fig. 2.

As far as the network function entity of the cellular network is concerned, the network function entity can be the NEF 100 or can be directly the application function 50. If the application function 50 is trusted, the application function may directly communicate with the policy control entity without including the NEF. When the NEF is provided it can receive the reservation request from the application function wherein this reservation request comprises the indication which indicates that in idle timer is supported for the application session and the idle timer is responsive to an absence of data in the at least data flow. This was discussed above in connection with Fig. 2, step S12. The network function entity can also be implemented as the application entity or application function of the cellular network and the authorization request is intended to directly reserve the resources for the application session.

The application session can comprise more than one data flow and the indication for the idle timer that the idle timer supported can be provided individually for each data flow of the different data flows. Accordingly this means that the idle timer and the timer value is provided individually for each flow of the session.

Furthermore, the indication which indicates that the idle timer is supported can comprise a proposal for timer value of the idle timer wherein the timer value indicates how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive.

The network function entity can furthermore receive from the policy control entity a notification which indicates that the at least one flow in the application session is inactive. Furthermore, the application function entity can transmit in direction of the application entity a notification which indicates that the at least one flow in the application session is inactive.

The notification which indicates that the at least one flow is inactive can contain the suggested action such as the deactivation of the at least one data flow.

This proposal provides a mechanism to allow Application influence the idle flow detection, making these timers application-aware and optimizing the network resources in a dynamic and Application-oriented fashion

It allows the AF to influence the idle Service Data Flow detection based on the Service Application, which causes an more efficient release of resources in the RAN and core network.

It allows to monitor which Applications request QoS and then, at a later stage, the QoS is not useful since there is no Service Data Flow being used by the UE. This collection of KPIs ( Key performance Indicators) (based on a new event IDLE_FLOW_DETECTED received from SMF/UPF allows NEF to have some insight to negotiate SLAs ( Service Level Agreements) with Application Functions which request QoS network resources which eventually are not be used in a large percentage of users.

A possible implementation of Fig. 2 to 6 could be as follows where the information in parentheses describes a possible content of the corresponding message mentioned just before:

S12: AF Session with QoS create request

(UE IP address, Qos reference, flow 1- Audio, idle timer = x, flow 2-Video, idle timer = y, Flow idle timer supported, indication to subscribe to IDLE_FLOW_DETECTED event)

S13: Since idle timer is received, NEF checks whether the AF is authorized to influence the idle flows management. If so, NEF sends the values to PCF

S14: Npcf_PolicyAuthorization_Create Request (UE IP address, AF app id, flow 21 -Audio, NEW: Inactivity timer = x, flow 2- Video, Inactivity timer = y, Flow idle timer supported, indication to subscribe to IDLE_FLOW_DETECTED event)

S15: PCF evaluates policies, and determines, based on the request from NEF/AF, the final idle timer to be monitored per flow

S16: Npcf_SMPolicyControl_UpdateNotify Request

(PCC Rule flow 1 -Audio, NEW: Inactivity timer = x, PCCRule flow 2-Video, Inactivity timer = y, Flow idle timer supported, indication to subscribe to IDLE_FLOW_DETECTED event)

S17: PFCP Session Modification Request

(PDR flow 1 -Audio, Inactivity timer = x, PDR flow 2-Video, Inactivity timer = y, Flow idle timer supported, indication to subscribe to

IDLE_FLOW_DETECTED event)

S18: QOS flows are established. UPF will monitor the specific timer for each flow as indicated by PCF

S19: Npcf_SMPolicyAuthorization_Update Request

(successful resource allocation, Flow idle timer supported)

S20: Npcf_PolicyAuthorization_Notify Request

(Application session context, successful resource allocation, final timers determined by PCF, Flow idle timer supported)

S21 : AF session with QoS Notify Request

(Subscription ID, successful resource allocation, final timers determined by PCF, Flow idle timer supported)

S22: Video flow Idle (phone camera switched off)

S23: Video flow becomes idle since no packet is sent/received during the idle timer (y)

S24: Inactivity timer fires for an idle flow

S25: PFCP Session Report Request

(PDR flow 2-Video, status=inactive, failure code=IDLE_FLOW_DETECTED)

S26: Npcf_SMPolicyAuthorization_Update Request

(PCC Rule flow video, status=inactive,: failure code=IDLE_FLOW_DETECTED) S27: Npcf_PolicyAuthorization_Notify Request

(flow video; event=IDLE_FLOW_DETECTED, flow status = INACTIVE)

S28: AF session with QoS Notify Request

(flow video; event=IDLE_FLOW_DETECTED, flow status = INACTIVE)

S29: Decision to modify one of the flows

S30: AF session with QoS Update request

(Transaction Reference ID, remove flow 2-Video)

S31 : Npcf_PolicyAuthorization_Update Request

(Application session context id, remove flow 2-Video)

S32: Npcf_SMPolicyControl_UpdateNotify Request

(PDU Session ID, remove PCC Rule flow 2-Video)

S33: PFCP Session Modification Request

(remove PDR flow 2-Video)

S42: AF Session with QoS create request

(UE IP address, QoS reference, flow 1 -Audio, flow 2-Video, Flow idle timer supported)

S43: Based on local policy for the QoS reference received, NEF determines the idle timers for the flows received from the AF, even if the AF did not indicate any idle timer

S44: Steps 44 onwards as in Fig. 2

S52: AF Session with QoS create request

S53: Npcf_PolicyAuthorization_Request

(UE IP address, AF app Id, flow 1 -Audio, flow 2-Video, Flow idle timer supported)

S54: Subscribed idle flow timers and configured policies related to idle timers are retrieved from UDR

S55: PCF evaluates policies, and NEW: determines, based on the request from NEF/AF and the provisioned/configured policies, that an idle timer must be monitored per flow

S56: Steps S56 onwards as in Fig. 2

S62: AF Session with QoS create request

(UE IP address, QoS reference, flow 1 -Audio, NEW: idle timer = x, flow 2- Video, idle timer = y, Flow idle timer supported, suggested action (deactivate_SD_flow))

S63: Since idle timer is received, NEF checks whether the AF is authorized to influence the idle flows management. If so, NEF sends the values to PCF

S64: Npcf_PolicyAuthorization_Create Request

(UE IP address, AF app Id, flow 1 -Audio, NEW: Inactivity timer = x, flow 2- Video, Inactivity timer = y, Flow idle timer supported, suggested action (deactivate_SD_flow))

S65: PCF evaluates policies, and determines, based on the request from NEF/AF, the final idle timer to be monitored per flow

S66: Npcf_SMPolicyControl_UpdatedNotify Request

(PCC Rule flow 1 -Audio, NEW: Inactivity timer = x, PCC Rule flow 2-Video, Inactivity timer = y, Flow idle timer supported, suggested action

(deactivate_SD_flow))

S67: PFCP Session Modification Request

(PDR flow 1 -Audio, NEW: Inactivity timer = x, PDR flow 2-Video, Inactivity timer = y, Flow idle timer supported, suggested action (deactivate_SD_flow)) S68: QOS flows are established. UPF will monitor the specific timer for each flow as indicated by PCF

S69: Npcf_SMPolicyAuthorization_Update Request

(successful resource allocation, Flow idle timer supported)

S70: Npcf_PolicyAuthorization_Notify Request

S71 : AF session with QoS Notify Request

S72: Video flow idle (phone camera switched off)

S73: Video flow becomes idle

S74: Inactivity timer fires for an idle flow, UPF applies the suggested action (e.g. deactivate_SD_flow)

S75: PFCP Session Report Request

(PDR flow 2-Video, status=removed, failure code=IDLE_FLOW_DETECTED)

S76: Npcf_SMPolicyAuthorization_Update Request

(PCC Rule flow video, status= removed, failure code=IDLE_FLOW_DETECTED)

S77: Npcf_PolicyAuthorization_Notify Request

(flow video, event=IDEL_FLOW_DETECTED, flow status=removed)

S78: AF session with QoS Notify Request

(flow video NEW: event=IDEL_FLOW_DETECTED, f status=removed)

Claims

- 33 - Claims

1 . A method for handling an application session comprising at least one data flow in a cellular network, the method comprising at a policy control entity (200) of the cellular network: receiving, from a Network Function, NF, entity (100) of the cellular network, an authorization request requesting an authorization of the application session, the authorization request comprising an indication indicating that an idle timer is supported for the application session, determining, based on the authorization request, a policy of the application session with a timer value for the idle timer, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive, transmitting the policy to a session management entity of the cellular network, the policy including the timer value for the at least one data flow of the application session.

2. The method of claim 1 , wherein the indication comprises a suggested action that should be carried out when the inactivity of the at least one flow is detected, wherein it is determined whether an application entity is authorized to influence the at least one application session in the cellular network, wherein in the affirmative, the suggested action is added to the policy transmitted to the session management entity.

3. The method of claim 1 or 2, wherein the indication comprises a proposed timer value, wherein determining the timer value comprises checking whether the proposed timer value is allowed for the application session.

4. The method of any preceding claim, wherein determining the timer value comprises accessing a subscriber data base of the cellular network for a subscriber involved in the application session, in order to determine the timer value for the subscriber.

5. The method of any preceding claim, further comprising: receiving a first notification from the session management entity, the notification indicating an absence of data in the at least one data flow, - 34 - transmitting a second notification to the NF entity indicating an absence of data in the at least one data flow.

6. The method of any preceding claim, wherein the NF entity is an exposure entity (100) to allow application entities to communicate with the cellular network, or an application entity of the cellular network.

7. A method for handling an application session comprising at least one data flow in a cellular network, the method comprising at a session management entity (300) of the cellular network: receiving, from a policy control entity (200) of the cellular network, a policy of the application session, the policy including a first indication indicating that an idle timer is supported for the application session, the first indication further comprising a timer value of the idle timer for the at least one data flow, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive, transmitting, to a user plane entity handling the at least one data flow, a handling request to handle the application session with the at least one data flow, wherein the handling request comprises a second indication indicating that the idle timer is supported for the application session, the second indication further comprising the timer value of the idle timer for the at least one data flow.

8. The method of claim 7, further comprising: receiving, from the user plane entity, a session report informing the session management entity of the fact that the at least one data flow is inactive, transmitting, to the policy control entity, an update request for the policy, the update request including as reason for the update request that the at least one data flow is inactive.

9. A method for handling an application session comprising at least one data flow in a cellular network, the method comprising at a user plane entity (400) of the cellular network configured to handle the at least one data flow: receiving, from a session management entity (300) of the cellular network, a handling request to handle the application session with the at least one data flow, wherein the handling request comprises an indication indicating that an idle timer is supported for the application session, the indication further comprising a timer value of the idle timer for the at least one data flow, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive, monitoring, using the timer value of the idle timer, whether the at least one data flow is inactive, wherein, if it is detected based on the timer value, that the at least one data flow is inactive, transmitting a session report to the session management entity (300) by which the session management entity is informed of the fact that the at least one data flow is inactive.

10. A method for handling an application session comprising at least one data flow in a cellular network, the method comprising at a Network Function, NF, entity (50, 100) of the cellular network: transmitting, to a policy control entity of the cellular network, an authorization request requesting an authorization of an application session, the authorization request comprising an indication indicating that an idle timer is supported for the application session.

11 . The method of claim 10, wherein the NF entity is an exposure entity (100) to allow application entities to communicate with the cellular network, and the method further comprises: receiving, from an application entity a reservation request to reserve resources for the application session, the reservation request comprising a previous indication indicating that an idle timer is supported for the application session, the idle timer being responsive to an absence of data in the at least one data flow.

12. The method of claim 10, wherein the NF entity is an application entity of the cellular network, and the authorization request is intended to reserve resources for the application session.

13. The method of any one of claims 10 to 12, wherein any indication indicating that an idle timer is supported is provided individually per data flow for the at least one data flow.

14. The method of any one of claims 10 to 13, wherein any indication indicating that an idle timer is supported comprises a proposal for a timer value for the idle timer, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive.

15. The method of any one of claims 10 to 14, further comprising: receiving, from the policy control entity, a first notification indicating that the at least one flow in the application session is inactive.

16. The method of claims 15 and 11 , further comprising: transmitting, in direction of the application entity, a second notification indicating that the at least one flow in the application session is inactive.

17. The method of any one of claims 15 or 16, wherein any notification indicating that the at least one flow is inactive comprises a suggested action that comprises a deactivation of the at least one data flow.

18. A policy control entity configured to handling an application session comprising at least one data flow in a cellular network, the policy control entity comprising at least one processing unit and a memory, the memory containing instructions executable by the at least one processing unit, wherein the policy control entity is operative to: receive, from a Network Function, NF, entity (100) of the cellular network, an authorization request requesting an authorization of the application session, the authorization request comprising an indication indicating that an idle timer is supported for the application session, determine, based on the authorization request, a policy of the application session with a timer value for the idle timer, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive, transmit the policy to a session management entity of the cellular network, the policy including the timer value for the at least one data flow of the application session.

19. The policy control entity of claim 18, wherein the indication comprises a suggested action that should be carried out when the inactivity of the at least one flow is detected, the policy control entity being operative to determine whether an application entity is authorized to influence the at least one application session in the cellular network, and in the affirmative, to add the suggested action to the policy transmitted to the session management entity. - 37 -

20. The policy control entity of claim 18 or 19, wherein the indication comprises a proposed timer value, the policy control entity being operative, for determining the timer value, to check whether the proposed timer value is allowed for the application session.

21. The policy control entity of any of claims 18 to 20, further being operative, for determining the timer value, to access a subscriber data base of the cellular network for a subscriber involved in the application session, in order to determine the timer value for the subscriber.

22. The policy control entity of any of claims 18 to 21 , further being operative to receive a first notification from the session management entity, the notification indicating an absence of data in the at least one data flow, transmit a second notification to the NF entity indicating an absence of data in the at least one data flow.

23. The policy control entity of any of claims 18 to 22, wherein the NF entity is an exposure entity (100) to allow application entities to communicate with the cellular network, or an application entity of the cellular network.

24. A session management entity (300) configured to handle an application session comprising at least one data flow in a cellular network, the session management entity comprising at least one processing unit and a memory, the memory containing instructions executable by the at least one processing unit, wherein the session management entity is operative to: receive, from a policy control entity (200) of the cellular network, a policy of the application session, the policy including a first indication indicating that an idle timer is supported for the application session, the first indication further comprising a timer value of the idle timer for the at least one data flow, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive, transmit, to a user plane entity handling the at least one flow, a handling request to handle the application session with the at least one data flow, wherein the handling request comprises a second indication indicating that the idle timer is supported for the application session, the second indication further comprising the timer value of the idle timer for the at least one data flow. - 38 -

25. The session management entity of claim 24, further being operative to receive, from the user plane entity, a session report informing the session management entity of the fact that the at least one data flow is inactive, transmit, to the policy control entity, an update request for the policy, the update request including as reason for the update request that the at least one data flow is inactive.

26. A user plane entity (400) configured to handle an application session comprising at least one data flow in a cellular network, the user plane entity comprising at least one processing unit and a memory, the memory containing instructions executable by the at least one processing unit, wherein the user plane entity is operative to: receive, from a session management entity (300) of the cellular network, a handling request to handle the application session with the at least one data flow, wherein the handling request comprises an indication indicating that an idle timer is supported for the application session, the indication further comprising a timer value of the idle timer for the at least one data flow, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive, monitor, using the timer value of the idle timer, whether the at least one data flow is inactive, wherein, if it is detected based on the timer value, that the at least one data flow is inactive, transmit a session report to the session management entity (300) by which the session management entity is informed of the fact that the at least one data flow is inactive.

27. A network function configured to handle an application session comprising at least one data flow in a cellular network, the network function comprising at least one processing unit and a memory, the memory containing instructions executable by the at least one processing unit, wherein the network function is operative to: transmit, to a policy control entity of the cellular network, an authorization request requesting an authorization of an application session, the authorization request comprising an indication indicating that an idle timer is supported for the application session.

28. The network function of claim 27, wherein the NF entity is an exposure entity (100) to allow application entities to communicate with the cellular network, the network function being operative to receive, from an application entity a reservation request to - 39 - reserve resources for the application session, the reservation request comprising a previous indication indicating that an idle timer is supported for the application session, the idle timer being responsive to an absence of data in the at least one data flow.

29. The network function of claim 27, wherein the NF entity is an application entity of the cellular network, and the authorization request is intended to reserve resources for the application session.

30. The network function of any of claims 27 to 29, wherein any indication indicating that an idle timer is supported is provided individually per data flow for the at least one data flow.

31 . The network function of any of claims 27 to 30, wherein any indication indicating that an idle timer is supported comprises a proposal for a timer value for the idle timer, the timer value indicating how long the idle timer should tolerate the absence of data in the at least one data flow before finally deciding that the at least one data flow is inactive.

32. The network function of any of claims 27 to 30, further being operative to receive, from the policy control entity, a first notification indicating that the at least one flow in the application session is inactive.

33. The network entity of claim 32 and 28, further being operative to transmit, in direction of the application entity, a second notification indicating that the at least one flow in the application session is inactive.

34. The network entity of any of claims 27 to 33, wherein any notification indicating that the at least one flow is inactive comprises a suggested action that comprises a release of resources for the at least one data flow.

35. A system comprising at least two entities selected from the following group of entities: a policy control entity as mentioned in any of claims 18 to 23, a session management entity as mentioned in any of claims 24 and 25, a user plane entity as mentioned in claim 26, and an application function as mentioned in any of claims 27 to 34. - 40 -

36. A computer program comprising program code to be executed by at least one processing unit of a policy control entity wherein execution of the program code causes the at least one processing unit to carry out a method as mentioned in any of claims 1 to 6.

37. A computer program comprising program code to be executed by at least one processing unit of a session management entity wherein execution of the program code causes the at least one processing unit to carry out a method as mentioned in any of claims 7 to 8.

38. A computer program comprising program code to be executed by at least one processing unit of a user plane entity wherein execution of the program code causes the at least one processing unit to carry out a method as mentioned in claim 9.

39. A computer program comprising program code to be executed by at least one processing unit of an application function entity wherein execution of the program code causes the at least one processing unit to carry out a method as mentioned in any of claims 10 to 17.

40. A carrier comprising a computer program of any of claims 37 to 39, wherein the carrier is one of an electronic signal, optical signal, radio signal and computer readable storage medium.