WO2016056967A1 - Method and arrangements for prioritization of traffic flows in a telecommunication network - Google Patents

Method and arrangements for prioritization of traffic flows in a telecommunication network Download PDF

Info

Publication number
WO2016056967A1
WO2016056967A1 PCT/SE2014/051204 SE2014051204W WO2016056967A1 WO 2016056967 A1 WO2016056967 A1 WO 2016056967A1 SE 2014051204 W SE2014051204 W SE 2014051204W WO 2016056967 A1 WO2016056967 A1 WO 2016056967A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
priorities
requested
request
network node
Prior art date
Application number
PCT/SE2014/051204
Other languages
French (fr)
Inventor
Ankur DAUNERIA
Piyush Maheshwari
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Priority to PCT/SE2014/051204 priority Critical patent/WO2016056967A1/en
Publication of WO2016056967A1 publication Critical patent/WO2016056967A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1063Application servers providing network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/752Media network packet handling adapting media to network capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS

Definitions

  • the present disclosure relates to a method for an Application Server to request application specific priorities of traffic flows from a Policy, Charging and Control (PCC) system, a method for handling such a request at a PCC, and an application server and PCC capable of executing the respective methods.
  • PCC Policy, Charging and Control
  • Over-the-top content refers to delivery of video, audio and other media over the Internet without a multiple system operator being involved in the control or distribution of the content.
  • OTT in particular refers to content that arrives from a third party, such as NowTV, Netflix, WhereverTV, NetD, Hulu, Crackle, WE Network, RPI TV or myTV, and is delivered to an end user device, leaving the Internet Service Provider (ISP) responsible only for transporting IP packets, and, thus, making them available to potential consumers.
  • ISP Internet Service Provider
  • An online video distributor is defined as "any entity that offers video content by means of the Internet or other Internet Protocol (IP)-based transmission path provided by a person or entity other than the OVD".
  • Over-the-top messaging refers to a similar idea, where a third party provides instant messaging services as an alternative to text messaging services provided by a mobile network operator.
  • Consumers can access OTT content through internet-connected devices such as e.g. desktop and laptop computers, tablets, smartphones, including iPhones and Android phones, set-top boxes, such as e.g. the Roku and Google TV smart TVs and gaming consoles, such as e.g. the Wii, PlayStation 3 and Xbox 360. Consumers can access apps in most app stores.
  • LTE Long Term Evolution
  • OTT over-the-top
  • Video content providers such as e.g. Netflix, Hulu, Apple, and others have converged on protocols classified as adaptive bit rate (ABR) streaming for premium content.
  • ABR adaptive bit rate
  • ABR Adaptive Bit Rate
  • LTE Long Term Evolution
  • Cloud applications and services such as e.g. Netflix, YouTube, Pandora, and Spotify allow mobile users to overcome the memory capacity and processing power limitations of mobile devices.
  • Video Commerce is the practice of using video content to promote, sell and support commercial products or services on the Internet.
  • the video can be downloaded and played or streamed to the viewer.
  • a typical video commerce application would involve a video which contains a number of clickable objects so that the viewer can click on any of those objects for further information or to purchase them.
  • the clickable object may not always be within the video itself, but part of the Flash or HTML5 player used to play back the video.
  • Video commerce can take place over any Internet-enabled communications device, such as e.g. a Personal Computer, a laptop, a PDA, a mobile phone, or a smart phone.
  • One possible use case involving use of a video related application is where a video frame of a running video shows a hotspot near a specific item which can be clicked.
  • an advertisement appears, which can also include one or more of video, image, audio, pdf etc., in the same video application window and no redirection on some webpage or creation of another tab in web browser happen, thereby allowing the user to complete a purchase.
  • video is continuing to stream/buffer, and thus consume resources, irrespective of whether or not this is of any further use to the user.
  • In-video tagging can lead to associating different type of data streams, such as e.g. image, website, and video from respective servers dedicated to keep that kind of data.
  • data streams such as e.g. image, website, and video from respective servers dedicated to keep that kind of data.
  • the mentioned services give rise to excessive amounts of traffic of different types, which are commonly distributed in parallel. As a consequence, new problems of how to handle this traffic arise.
  • the tariffs applied by the operator or carrier can be grouped broadly into one of the following categories:
  • Quota-based - Subscribers purchase a monthly quota of data volume, beyond which access to the network is throttled until the beginning of the next billing period. A breach of quota typically results in the application of special charges.
  • Speed-based - Subscribers are offered different levels of network speed, from which they can purchase according to a monthly plan based on their selection. A quota may or may not be built into the plan. Some speed-based plans enforce fair use policies for the top percentile of subscribers.
  • EP 2525550 is a patent application which refers to Controlling QoS provided to over the top applications in a telecommunication system.
  • the disclosed method involves receiving a registration request from the OTT application, and configuring an application programming interface (API) at a service delivery platform to have dependent rules that provision a QoS level for the OTT application responsive to registration request.
  • the QoS is controlled through the network provided for a communication session between the user equipment (UE) and OTT application responsive to the QoS level provisioned for the OTT application.
  • US 201 10219431 discloses a method which involves sending a request having subscriber identification from an OTT application server to a telecommunications network with QoS requirement for an Internet Protocol (IP) based application session and determining an appropriate QoS level for subscriber by a network policy node. The determined QoS level is then enforced for the IP-based application session with the OTT service provider, by a network gateway.
  • IP Internet Protocol
  • US 20130329550 discloses a method which involves receiving a connection request that includes information identifying a particular application, from a user device.
  • the particular application associated with the group of classes of traffic is identified.
  • a group of bearer channels that are associated with the group of classes of traffic and the group of different levels of quality of service (QoS) are established.
  • QoS quality of service
  • the two traffic classes associated with the user devices and particular applications are then processed through two different bearer channels, according to two different levels of QoS respectively.
  • All documents cited above do however provide very limited mechanisms for how to impact on how to best make use of available resources when executing an application, and particularly an OTT application.
  • a method to be executed in an application server providing an application, involving a plurality of traffic flows, to a user device comprises: identifying an event triggering the application to determine application specific priorities of the traffic flows involved with the application, where the identifying is based on application specific rules; determining the application specific priorities of the traffic flows involved with the application, where also the determining is based on application specific rules; generating a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and transmitting the request to the network node.
  • the application is a video application involving at least one video related traffic flow.
  • the event triggering the application may according to one embodiment be an event initiated by the application, i.e. an automatically initiated event, while according to another embodiment it may be an event initiated by the user of the user device, i.e. a manually initiated event. Thereby, a decision on how to prioritize traffic flows may be taken with or without influence of the end user.
  • the suggested method may comprise a further step of receiving a response to the request from the network node, where the response is indicating to the application whether the requested priorities will be complied with or not by the network node. Thereby the application will be able determine how to proceed in response to such a response.
  • a denial of a request may e.g. result in a new, alternative request.
  • the request mentioned above may comprise different data, in order to enable for the network node receiving the request to consider more or less in-data when processing a request.
  • user device identifier identifying the user device for which a traffic flow has been set up
  • application identifier identifying the application
  • traffic class identifier identifying type of traffic flow
  • application specific priorities for traffic flows involved in the application user identifier, identifying the registered user of the communication device
  • device identifier identifying the communication device
  • QoS indicating a respective requested QoS for a prioritized traffic flow, and time interval, identifying a time interval during which a requested priorities are requested.
  • a method to be executed in a network node capable of managing policy control of an application provided to a user device by an application server comprises: receiving a request from the application server, where the request comprise application specific priorities, and where the request requests how to prioritize a plurality of traffic flows associated with the application; applying operator specific rules on the requested prioritizations, and enforcing or denying the requested prioritizations based on the operator specific rules.
  • the network node forms part of a 3GPP Policy Charging and Control (PCC) architecture and the operator specific rules are Policy Control and Charging (PCC) rules, but any type of network node which is capable of managing policy control and of handling the suggested requests as suggested herein may be applicable.
  • the suggested enforcing may be arranged so that it comprises: applying the requested priorities in case the requested priorities are compatible with the operator specific rules, or ignoring the requested priorities in case the requested priorities are incompatible with the operator specific rules.
  • the step of applying operator specific rules on the received request comprises: comparing, for each traffic flow included in the request, a respective QoS demanded by the application with resources available for the application, and applying the requested priorities and QoS in case the QoS requests meet with the available resources, or ignoring the requested priorities and QoS in case the QoS requests do not meet with the available resources.
  • the method according to this alternative embodiment comprises either transmitting a response to the request to the application, informing the application that the requested priorities will be complied with in case the requested priorities are compatible with the operator specific rules, or transmitting a response to the request to the application, informing the application that the requested priorities will not be complied with in case the requested priorities are incompatible with the operator specific rules.
  • an application server capable of providing an application, involving a plurality of traffic flows, to a user device.
  • Such an application server is adapted to: identify an event triggering the application to determine application specific priorities of the traffic flows involved with the application, where the identifying is based on application specific rules; determine the application specific priorities of the traffic flows involved with the application, where also the determining is based on application specific rules; generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the network node.
  • the application server may, according to one embodiment be adapted to handle an event triggering the application, where the event is initiated by the
  • the application server is adapted to handle an event triggering the application, where the event is initiated by the user of the user device.
  • the application server is further adapted to receive a response to the request from the network node, where the response is indicating to the application whether the requested priorities will be complied with or not by the network node.
  • the application server may be configured to provide different data into a request, such that the request comprise at least one of: user device identifier, identifying the user device for which a traffic flow has been set up; application identifier, identifying the application; traffic class identifier, identifying type of traffic flow; application specific priorities for traffic flows involved in the application; user identifier, identifying the registered user of the communication device; device identifier, identifying the request.
  • QoS indicating a respective requested QoS for a prioritized traffic flow, and time interval, identifying a time interval during which a requested priorities are requested.
  • an application server capable of providing an application, involving a plurality of traffic flows, to a user device, where the application server comprise a processor and a memory, the memory comprising instructions executable by the processor, whereby the application server is operative to: identify, based on application specific rules, an event triggering the application to determine application specific priorities of the traffic flows involved with the application; determine, based on application specific rules, the application specific priorities of the traffic flows involved with the application; generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the network node via a communication unit.
  • a computer program is suggested where the computer program is executable on an application server capable of providing an application, involving a plurality of traffic flows, to a user device.
  • the computer program is comprising instructions which, when run on the application server, causes the application server to: identify an event triggering the application to determine
  • a computer program product comprising a computer program, such as the one suggested above, and a computer readable means on which the computer program is stored, is suggested.
  • a network node capable of managing policy control of an application provided to a user device by an application server.
  • This network node is adapted to: receive a request comprising application specific priorities, from the application server, where the request is requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or denying the requested prioritizations, based on the operator specific rules.
  • the network node may be any type of network node which is capable of managing policy control and of handling the suggested request
  • the network node may according to one embodiment form part of a 3GPP Policy Charging and Control (PCC) architecture, while the operator specific rules are Policy Control and Charging (PCC) rules.
  • PCC Policy Charging and Control
  • the network node is adapted to enforce or deny the requested prioritizations by applying the requested priorities in case the requested priorities are compatible with the operator specific rules, or ignoring the requested priorities in case the requested priorities are incompatible with the operator specific rules.
  • the network node is adapted to apply operator specific rules on the received request by comparing, for each traffic flow included in the request, a respective QoS demanded by the application with resources available for the application, and by applying the requested priorities and QoS in case the QoS requests meet with the available resources, or ignoring the requested priorities and QoS in case the QoS requests do not meet with the available resources.
  • the network node is further adapted to: transmit a response to the request to the application, informing the application that the requested priorities will be complied with in case the requested priorities are compatible with the operator specific rules, or transmit a response to the request, to the application, informing the application that the requested priorities will not be complied with in case the requested priorities are incompatible with the operator specific rules.
  • a network node capable of managing policy control of an application provided to a user device by an application server, where the network node comprise a processor and a memory, the memory comprising instructions executable by the processor, whereby the network node (1 100) is operative to: receive a request comprising application specific priorities from the application server, where the request is requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
  • a computer program executable on a network node capable of managing policy control of an application provided to a user device by an application server comprising instructions which, when run on the network node causes the network node to: receive a request comprising application specific priorities from the application server,, where the request is requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
  • Fig. 1 is an overview of a system according to prior art comprising an application server, capable of providing services in the form of executable applications to user devices via an operator domain, where servers are providing the service to the user devices in the form of traffic flows.
  • Fig. 2 is a block scheme, illustrating how an application server can interact with a PCC according to prior art.
  • Fig. 3 is an illustration of a possible scenario, where a video based application is engaging a plurality of servers, each of which is capable of providing different types of user content.
  • Fig. 4 is a block scheme, illustrating how an application server can extend the interaction with a PCC, according to one embodiment.
  • Fig. 5 is a signalling scheme illustrating a mechanism for enabling an application to request priorities for associated traffic flows from a PCC.
  • Fig. 6 is a flow chart, illustrating a method for identifying a requirement for requesting priorities of traffic flows from a PCC, and for transmitting such a request.
  • Fig. 7 is another flow chart, illustrating a method for recognising and processing a request for prioritization of traffic flows received from an application server.
  • Fig. 8 is a block scheme illustrating an application server according to a first
  • FIG. 9 is another block scheme illustrating a an application server according to a second embodiment, configured to execute the method, such as the one suggested herein with reference to Fig. 6.
  • Fig. 10 is yet another block scheme illustrating a network node according to a first embodiment, configured to execute a method, such as the one suggested herein with reference to Fig. 7
  • Fig. 1 1 is another block scheme illustrating a network node according to a second embodiment, configured to execute a method, such as the one suggested herein with reference to Fig. 7
  • a method for enabling an application, involving a plurality of traffic flows, to request an arrangement capable of applying policy control how to prioritize the respective traffic flows during the policy control, thereby effecting decisions which up to date has been taken corresponding arrangements only based on the operators preferences.
  • a method is also suggested for handling such a request by arrangement.
  • the mentioned policy control functionality will be provided in a 3GPP Policy Charging and Control (PCC) architecture, according to ETSI TS 123 203, v10.8.0 (2012-1 1 ), but any type of architecture, capable of applying policy control on an application may be applicable.
  • PCC Policy Charging and Control
  • FIG. 1 An overview of a context in which the suggested mechanism can be executed is described in Fig. 1 , where and Application Server (AS) 1 10 of a network 100 is capable of servicing a plurality of user devices, here represented by user device 1 -3, 120a, 120b, 120c, with applications which, when executed at one of the user devices, are presented on the user devices in a plurality of different traffic streams, typically comprising a Video traffic stream and at least one additional traffic stream, which may be another video traffic stream or any other type of traffic stream.
  • Traffic streams belonging the same traffic class such as e.g. video streams, are typically provided from a specific server from a plurality of different available servers, here represented by server! -3, 130a, 130b, 130c.
  • the AS 1 10 has access to an operator domain 140, comprising various network nodes, including e.g. PCC, which are controlled and managed by the operator of a telecommunication network which the AS is using for providing the mentioned services/traffic flows to the user devices 120a, 120b, 120c.
  • various network nodes including e.g. PCC, which are controlled and managed by the operator of a telecommunication network which the AS is using for providing the mentioned services/traffic flows to the user devices 120a, 120b, 120c.
  • FIG. 2 is an illustration of a known PCC of an operator domain 140, where an AS, such as AS 1 10 of Fig. 1 , has access to the operator domain 140, and specifically the PCC 210 so that user traffic that is to be provided to various user devices 120a, 120b, 120c via the operator can be used by the PCC 210 in order to provide more efficient handling and managing of the various traffic flows.
  • AS such as AS 1 10 of Fig. 1
  • PCC 210 so that user traffic that is to be provided to various user devices 120a, 120b, 120c via the operator can be used by the PCC 210 in order to provide more efficient handling and managing of the various traffic flows.
  • user traffic can be provided in the described direction for processing by the PCC 210, but the user cannot influence the policy decisions made by the PCC related to various traffic flows.
  • PCC 210 comprise a Policy Controller 220, which is configured to make various policy decisions on the basis of various types of data, such as e.g. network data, which may include e.g. network performance information and/ or network event information; application data, which may e.g. include data on executed sessions and/or application specific information; subscriber data, which may e.g.
  • network data which may include e.g. network performance information and/ or network event information
  • application data which may e.g. include data on executed sessions and/or application specific information
  • subscriber data which may e.g.
  • a policy decision is then provided to a Decision Enforcer 240, which may in the present context be referred to as a Policy Control Enforcement Function (PCEF), which enforce or deny a decision e.g. on a Packet Data Network Gateway (PDN GW), or another corresponding network node, which is involved in the distribution of the mentioned traffic flows.
  • PCEF Policy Control Enforcement Function
  • - Service category such as e.g. web, file download, video.
  • Subscription such as e.g. Gold, Silver, Bronze.
  • Header fields such as e.g. according to a range of IP addresses or port numbers.
  • - Usage policies such as e.g. heavy users, light users
  • the PCC may be used by the operator for developing rules on how to prioritize, and for applying those rules.
  • the described PCC 210 only executes decisions on initiative from the operator side, without giving the application any opportunity to influence the policy decisions e.g. when it comes to how to prioritize the different traffic flows associated with execution of a specific application.
  • the application side was able to influence how prioritizations between traffic flows associated with a respective application and a respective user device was to be executed. Therefore a method and arrangement for allowing also the application to effect the policy decision in real-time by providing input on required prioritizations is suggested.
  • FIG. 3 is illustrating a typical scenario, where the new mechanism described herein may be applied in an advantageous way. More specifically, figure 3 is illustrating a video based application 300, which is typically provided to users via an AS (not shown), allowing the users to access content from various servers. As indicated in Fig. 3, different servers may provide data content of different specific classes. In the present example, there are two Media servers, 310, 320, which may typically provide different video content; two Advertisement servers, 330, 340, which are typically providing different advertisements at different occasions; One Video comments server, 350, which is typically providing comments on a rendered video, and a Video comments
  • FIG. 4 is a schematic illustration of how signalling between network nodes of a telecommunication system, based e.g.
  • Fig. 4 only comprise network nodes which are of relevant importance for the understanding of the concept described herein, and, thus, any other network nodes which typically appear in telecommunication networks have been omitted for simplicity reasons.
  • the signalling scheme comprise an operator domain 400, which has been amended as suggested above, i.e.
  • a Priority Analyzer (PA) 450 via which a request, herein referred to as a Traffic Priority Message (TPM), received from an AS 460, is forwarded to the PCC 410 for further processing by the PCC.
  • TPM Traffic Priority Message
  • the PA 450 may also be capable of decoding an adapting the TPM accordingly.
  • Fig. 4 is illustrating one way signalling, i.e.
  • the PCC 410 may optionally also be configured to apply two way communication with the AS via the PA by indicating to the AS whether the request will be complied with or not.
  • PA 450 is shown as an entity which is separated from the PCC, and the PA 450 may e.g. be integrated in a Media Delivery Network (MDN) node.
  • MDN Media Delivery Network
  • the described PA functionality may be arranged as an integrated part of a PCC. In any event, the functionality first receiving a request from AS 460 to PCC 410 must be capable of interpreting the request so that it can be provided to and processed by PCC 410 accordingly.
  • a traffic flow is referred to as a connection of a certain traffic class between a server, or content source, capable of providing some data traffic to a user device, and the user device, via an AS.
  • Example 1 In-video commerce
  • An in-video commerce based video application i.e. an application where a commerce is displayed while a user is watching a video, or a video and a commerce being presented in the same video player instance, detects at a point in time that a user has selected 'Add to Cart' while the product video is already streaming from a media server. User decides to complete the payment transaction by connecting to a payment server from the video application itself while video is already streaming from the media server.
  • the video application which may be an OTT application, can decide to send a request to its Telecom Operator in real time for this connected user, carrying multiple priorities for various active traffic flows relating to the video application and this user device, to provide higher priority in QoS towards a particular traffic flow of application, between user device and payment server rather than user device and the media server as user now has decided to buy the item and is currently trying to complete the payment transaction.
  • the original priorities for various traffic flows (belonging to same class, between different classes) between the video application and user device can be retained.
  • the first example highlights a prioritization scenario involving different traffic flows active in a video application.
  • each traffic flow belongs to a separate traffic class, i.e. traffic flows of different traffic classes are prioritized differently.
  • Example 2 Prioritizing an advertisement during buffering of a main video
  • Advertisements carry business significance for YouTube and similar applications since a user who is not watching a main video (which is paused and is buffering), instead watches an advertisement which is typically not skippable. So, requesting better QoS for video advertisement streaming for a time duration of the advertisement can be applied by a video application for its connected users at any appropriate point in time.
  • the second example is a second prioritization scenario between various traffic flows active in a video application. In this scenario, all traffic flows belong to a same traffic class, i.e. prioritization for traffic flows of one and the same traffic class is suggested.
  • Example 3 Video sharing site providing in-video comments, advertisements on in-video comments.
  • the application in a multiple streaming scenario where a user is connected to a video application, streaming multiple items belonging to a specific traffic class (here, for example, a video) at a point in time, the application, as per user activities in video application, can decide to provide a request to the telecom operator in real time for this connected user, with a list of priorities among the various traffic flows currently streaming between various servers (all belonging to a video traffic class but performing different tasks, such as e.g. video streaming, video advertisement streaming, in-video comment streaming and video advertisements on in-video comments streaming) associated with the video application and user device at this time instance.
  • a specific traffic class here, for example, a video
  • the application can decide to provide a request to the telecom operator in real time for this connected user, with a list of priorities among the various traffic flows currently streaming between various servers (all belonging to a video traffic class but performing different tasks, such as e.g. video streaming, video advertisement streaming, in-video comment streaming and video advertisements on in-video comments streaming) associated with the video application and user
  • the suggested priority list would be used by the operator to provide QoS demanded by the application for a particular traffic flow among a set of several flows currently active in the application in relation to this user device at this point in time for an already connected user.
  • the application can use various types of business or commercial significant input to decide on priority. By way of example, different priorities can be determined for traffic flows of one and a same traffic class, such that a required QoS for a certain traffic flow (determined based on server of origin of the flow) takes priority over other traffic flows. 1.
  • Example 3 demonstrates nested traffic in a futuristic video application instance having a main video, multiple video comments, video advertisements on the main video and video advertisements on the video comments.
  • the process briefly described above can be illustrated in more detail by the flow chart of Fig 5, where a user device 120 has requested an application from an AS 360.
  • the AS 360 is fetching relevant data on the requested application from the user device 120, as indicated in step 5: 1.
  • the AS 460 establishes connection with server 1 , 130a, server 2, 130b, and server 3, 130c, respectively, as well as establishing respective traffic flows between the user device 120 and the respective server.
  • the application involves three different traffic flows at the given time instance as indicated by the figure.
  • one of the traffic flows is a video traffic flow.
  • one of the flows may e.g. be a film provided from a media server, video comments may be provided from another server, typically referred to as a video comment server, while another stream is an advertisement provided from yet another server, which may be referred to as an advertisement server.
  • a prioritization trigger is recognized during execution of the application by the AS 460, as indicated in step 5:5.
  • Such a trigger is typically event based, and depends on application defined logic, such that when a certain pre-defined event is discovered by the application during application execution, a request for application of specific priorities of the presently active traffic flows is initiated.
  • Such an event may be automatically initiated by the application, without requiring any action from the user, such that e.g. an injection of a pre-defined video advertisement in between a main video rendering by the application may trigger a request for prioritization.
  • a trigger may be initiated by the application, recognising a user input, such that e.g. once a purchase is initiated by a user watching a video, the application may request a traffic flow executing the purchase to be prioritized higher than the rendering of the main video.
  • the application In response to a trigger, the application generates a TPM according to a predetermined prioritization scheme, relevant for the executed event, as indicated in step 5:6.
  • the TPM is then transmitted to a PCC via an interface, here referred to as PA, capable of recognising and decoding the TPM.
  • the PA may be arranged as a standalone device, as indicated in Fig. 5, or as an integrated part of the PCC.
  • the transmission is indicated in step 5:7 and forwarding from the PA to the PCC in step 5:8.
  • the PCC will then be able to treat the content of the TPM as in-data, process the data by considering available policies, and, depending on the outcome of the processing, determine whether to enforce the decision or not.
  • Execution of an application may include traffic flows provided from multiple traffic sources or servers of a certain traffic class, such as e.g. multiple videos streaming traffic to a user device within a single video application window of the display of the user device. Alternatively it can include multiple classes of traffic flows activated from different servers within the same video application window.
  • the request, or TPM is provided as a list, comprising data relevant for the respective application and traffic flows for which priorities are to be considered by the PCC.
  • Multiple lists may be prepared, used, stored, and re-used, such that priorities may be increased or decreased based on events happening during execution of the application.
  • Such a list comprise at least an application identifier, identifying the executing application; a user device identifier, identifying the user device executing the application and the application specific priorities which are to be requested from the PCC.
  • the list may also comprise a plurality of device identifiers.
  • the list may comprise additional data, such as e.g. one or more of traffic class identifier, identifying the traffic class or traffic classes of the active traffic flows; user identifier, identifying the user, or users in case a group of user devices of different users are considered in the request, QoS, indicating a requested QoS which the application requests to be applied for the prioritized traffic flows.
  • the list may also comprise a present time stamp and a time interval, indicating a time interval during which the requested priorities are requested and/or indicating the duration of respective applications.
  • the current traffic flow state e.g. streaming or buffering, volume or size of user data provided from a respective server may also be provided in the list.
  • What is contained in a list will typically depend on how the operator specific rules, or policies, are configured at the operator side. In other words, all parameters and data which is/are to be considered when evaluating the operator specific rules on the operator side will be relevant to put into a list, thereby forming a respective request.
  • a specific server will belong to a certain traffic class and any type of user device which is capable of executing an application comprising a plurality of traffic flows, such as e.g. a smartphone, a tablet, a desktop or a laptop, may be involved in execution of the suggested process.
  • FIG. 6 is a flow chart illustrating a method for applying the mechanism suggested above, where the method is executed in an AS.
  • the method is executed in an AS.
  • at least one user device is executing an application which is running on the AS, where the application comprises at least two active traffic flows, set up between a respective server and the user device, via the AS.
  • a first step 6: 1 logic of the AS is identifying an event, which triggers a priority request.
  • the application is determining which priorities that are to be applied in a request associated with the present trigger. This can be done by executing pre-defined logic, and may according to one embodiment include selection of a list from already stored lists, comprising event specific priorities, while according to another embodiment, further evaluations, other than only determining that a certain event has occurred, may have to be executed before relevant priorities can be determined accordingly. As a result, an already existing list may be determined and selected or a new list, relevant for the identified event may have to be provided.
  • a request is generated in another step 6:3 and in a next step 6:4, the request is sent to a PCC.
  • the method as suggested above describe a process automatically executed by the application whenever a trigger occurs.
  • the application sets up a dialogue with the user where the user is requested to accept a prioritization request determined and suggested by the application, prior to generating and transmitting a request to PCC.
  • the suggested prioritization is denied by the user, the described process is terminated and the execution of the application is continued in a conventional manner, without making any request for prioritization.
  • FIG. 7 is another flow chart, illustrating a method as executed in network node of the operator, or more specifically in an arrangement forming part of a 3GPP PCC architecture or a corresponding architecture.
  • a request may initially be received by a specific entity, capable of interpreting, decoding the request, and forwarding it to the PCC, or such functionality may be integrated with the PCC.
  • a request is received by the PCC in a format recognizable by the PCC.
  • the PCC or more specifically a Policy and Charging Rules Function (PCRF) of the PCC is applying operator specific rules, which may typically be Policy Control and Charging (PCC) rules, or any other rules which are adaptable to apply together with content of the received request, on the request.
  • PCC Policy Control and Charging
  • the available upload or download bandwidth may be limited to a maximum or minimum bits per second rates.
  • an application may get restricted access to available resources if a requested priority would lead to bandwidth use which exceeds allotted monthly bandwidth use.
  • the PCC will determine if and how to enforce or deny the request, as indicated with step 7:3.
  • the result of the previous step i.e. acceptance or denial of the request, may be provided to the application, as indicated in optional step 7:4.
  • the communication between AS and PCC is a two-way communication rather than a one-way
  • an AS and an arrangement capable of applying policy control need to be adapted accordingly.
  • an AS which is capable of providing an application involving a plurality of traffic flows to a user device, where the AS comprise means adapted to: Identify, on the basis of application specific rules, an event triggering the application to determine application specific priorities of the traffic flows involved with the application, i.e. how to prioritize the active traffic flows associated with the application when executed by the user device; determining, based on application specific rules, the application specific priorities of the traffic flows involved with the application; generating a request for an arrangement capable of applying policy control to apply the determined priorities during policy control of the application, i.e. each active traffic flow of the executed application when executed by the user device, and transmitting, the request , to the arrangement.
  • An AS capable of executing the method as described above with reference to Fig.
  • an AS capable of providing an application, involving a plurality of traffic flows, to a user device, is adapted to: identify an event triggering the application to determine application specific priorities of the traffic flows involved with the application, on the basis of application specific rules; determine the application specific priorities of the traffic flows involved with the application, on the basis of application specific rules;
  • the AS 800 of Fig. 8 comprises Identifying means, here represented by an identifying unit 810, adapted to identify an event triggering a priority request. As already mentioned above, this is typically achieved by logic recognising the occurrence of a predefined event, or a number of events, which may be application initiated, user initiated or a combination of both. In case the AS 800 is adapted to request approval of a request from the user, the identifying means may also be adapted to initiate such a dialogue with the user.
  • the AS 800 also comprises Determining means, here represented by a determining unit 820, adapted to determine application specific priorities to be applied in response to the identified trigger.
  • a trigger may indicate a specific pre-determined and stored priority, set up to be applied for the relevant traffic flows.
  • the determining unit 820 may be configured to determine required priorities after
  • Generating means here represented by a generating unit 830 is configured to generate a request in a suitable format which comprises the determined priorities.
  • Generating a request will include assembling a list of suitable in-data for the policy control functionality.
  • the amount of in-data in the list for the policy control functionality to consider may differ, dependent e.g. on one or more of:
  • Communicating means here referred to as a communication unit 840 is configured to transmit the request to policy control functionality, either directly, or via any intermediate functionality capable of adapting the request accordingly, as described herein.
  • the communicating unit 840 is also configured to receive such a response, for further processing via appropriate functionality.
  • the determining unit 820 may e.g. be adapted to process such a response, which may e.g. result in the generating of another request.
  • the communicating unit 840 may also be configured to communicate such a dialogue with the user, or, alternatively, separate communication means may be configured for such a purpose. Any type of communication means capable of establishing wireless or wireline communication between the AS and the policy control functionality may be used for this purpose.
  • the AS 800 also comprise memory 850 e.g. for storing priority lists to be used for generating requests, as suggested above.
  • the memory 850 can be any combination of read and write memory (RAM) and read only memory (ROM).
  • the AS suggested above may be configured as comprising hardware, software or a combination of both, and may comprise one or more processors, such as e.g. one or more Central Processing Units (CPU) or Application Special Integrated Circuits (ASIC), controlling a plurality of interacting units or modules, arranged such that functionality of each unit or module correspond to the functionality of respective means as described above. Therefore, any of the units suggested above, may be replaced by software related modules, executing corresponding functionality.
  • processors such as e.g. one or more Central Processing Units (CPU) or Application Special Integrated Circuits (ASIC)
  • an AS 900 is configured as illustrated in Fig. 9, where the AS 900 comprise a processor 910, and a memory 920, where the memory 920 comprise instructions executable by the processor 910, whereby the AS 900 is operative to: identify an event triggering the application to determine application specific priorities of the traffic flows involved with the application, on the basis of application specific rules; determine the application specific priorities of the traffic flows involved with the application, on the basis of application specific rules; generate a request for an arrangement capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the arrangement.
  • a computer program which when run on an AS 900 causes the AS 900 to execute the method steps as suggested above.
  • Such a computer program may be provided as a computer program product 950, comprising the computer program and a computer readable means, such as e.g. a DVD, on which the computer program is stored.
  • the AS 900 as suggested above may also comprise executable instruction arranged so that the AS 900 is operative to execute any of the functionality suggested above, with reference to the units of Fig. 8.
  • a network node capable of providing policy control functionality corresponding to what can e.g. be provided from a 3GPP PCC environment, which is capable of executing the method as describe above, with reference to Fig. 7. is adapted to: receive a request from the application server, where the request comprise application specific priorities, request how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
  • the network node mentioned above can be described as indicated below with reference to Fig. 10.
  • the network node 1000 comprises Communicating means, here referred to as a communication unit 1010, capable of receiving a request originating from an AS, as described above, where the communication unit 1010 may be configured to decode and adapt the request so that it can be further processed by the network node 1000 or, alternatively, it can be adapted to receive a request via a PA, as described above, or any corresponding entity.
  • a PA may forward a request to the network node over a standard interface, such as e.g. the Gx interface.
  • any type of communication means capable of establishing wireless or wireline communication between the AS and the policy control functionality may be used for this purpose.
  • the communication unit 1010 or another communication unit may be further adapted to group or categorize received TPMs in real time, based on some characteristics or commonality before sending them to the PCC.
  • grouping or categorizing may be based on pre-defined process logic rules. Accordingly TPMs may be arranged into application specific request queues, where the content of the different queues are handled in a certain pre-defined order. The mentioned feature for grouping or categorizing may be particularly useful if a large amount of TPMs, received from a range of heterogeneous applications need to be handled.
  • TPMs having similar priorities for similar types of traffic flows may be grouped together.
  • the PA is configured as a standalone unit, corresponding functionality may be provided also on such a unit.
  • the network node 1000 also comprises Policy controlling means, here referred to as a policy controlling unit 1020, which corresponds to the Policy Controller 220 of fig. 3, configured to apply operator specific rules on the received request. Since in-data is provided in a request provided from an AS, further considerations need to be taken, when considering also multiple event triggered traffic flow priorities, compared to conventional Policy control functionality provided from a 3GPP PCC environment.
  • Policy controlling means here referred to as a policy controlling unit 1020, which corresponds to the Policy Controller 220 of fig. 3, configured to apply operator specific rules on the received request. Since in-data is provided in a request provided from an AS, further considerations need to be taken, when considering also multiple event triggered traffic flow priorities, compared to conventional Policy control functionality provided from a 3GPP PCC environment.
  • Enforcing means here represented by an enforcing unit 1030, which corresponds to the Decision Enforcer 440 of Fig 3, or a PCEF of a 3GPP PCC environment, is here configured to enforce or deny the request.
  • the enforcing unit 1030 is also configured to generate such a response and to transmit the response to the AS via the communication unit 1010.
  • the network node 1000 also comprise memory 1040 e.g. for storing profiles to be used, as suggested above.
  • the memory 1040 can be any combination of read and write memory (RAM) and read only memory (ROM).
  • the network node described above may be configured as comprising hardware , software, or a combination thereof, and may comprise one or more processors, such as e.g. one or more Central Processing Units (CPU) or Application Special Integrated Circuits (ASIC), controlling a plurality of interacting units or modules, arranged such that functionality of each unit or module correspond to the functionality of respective means as described above. Consequently, one or more units described above, may be replaced by a corresponding software based module, capable of providing corresponding functionality.
  • CPU Central Processing Units
  • ASIC Application Special Integrated Circuits
  • a network node capable of operating as suggested above is configured as illustrated in Fig. 1 1 , where the network node 1 100 comprise a processor 1 1 10, and a memory 1 120, where the memory 1 120 comprise instructions executable by the processor 1 1 10, whereby the AS 1 100 is operative to: receive a request from the application server, comprising application specific priorities, requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
  • a computer program which when run on a network node 1 100, as suggested above, causes the network node 1 100 to execute the method steps as suggested above.
  • a computer program may be provided as a computer program product 1 150, comprising the computer program and a computer readable means, such as e.g. a DVD, on which the computer program is stored.
  • the network node 1 100 as suggested above may also comprise executable instruction arranged so that the network node 1 100 is operative to execute any of the functionality suggested above, with reference to the units of Fig. 10.
  • executable instruction arranged so that the network node 1 100 is operative to execute any of the functionality suggested above, with reference to the units of Fig. 10.
  • the choice of names for the interacting units, as well as the naming of the units within this disclosure are only for exemplifying purpose, and nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested procedure actions.
  • the units described in this disclosure can be regarded as logical entities and not with necessity as separate physical entities.

Abstract

A method is suggested for providing an application, involving a plurality of traffic flows, to a user device, which can be executed in an application server. The method comprise: identifying, on the basis of, application specific rules, an event triggering the application to determine application specific priorities of the traffic flows involved with the application; determining, based on application specific rules, the application specific priorities of the traffic flows involved with the application; generating a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application; transmitting the request to the network node.

Description

Method and arrangements for prioritization of traffic flows in a telecommunication network
Technical field
[0001 ] The present disclosure relates to a method for an Application Server to request application specific priorities of traffic flows from a Policy, Charging and Control (PCC) system, a method for handling such a request at a PCC, and an application server and PCC capable of executing the respective methods.
Background
[0002] Over-the-top content (OTT) refers to delivery of video, audio and other media over the Internet without a multiple system operator being involved in the control or distribution of the content. OTT in particular refers to content that arrives from a third party, such as NowTV, Netflix, WhereverTV, NetD, Hulu, Crackle, WWE Network, RPI TV or myTV, and is delivered to an end user device, leaving the Internet Service Provider (ISP) responsible only for transporting IP packets, and, thus, making them available to potential consumers. [0003] An online video distributor (OVD) is defined as "any entity that offers video content by means of the Internet or other Internet Protocol (IP)-based transmission path provided by a person or entity other than the OVD". Over-the-top messaging refers to a similar idea, where a third party provides instant messaging services as an alternative to text messaging services provided by a mobile network operator. [0004] Consumers can access OTT content through internet-connected devices such as e.g. desktop and laptop computers, tablets, smartphones, including iPhones and Android phones, set-top boxes, such as e.g. the Roku and Google TV smart TVs and gaming consoles, such as e.g. the Wii, PlayStation 3 and Xbox 360. Consumers can access apps in most app stores.
[0005] As mobile operators launch Long Term Evolution (LTE) and other 4G networks, they can take advantage of the growing popularity of over-the-top (OTT) video and the new mobile devices that support it. Industry research analysts, systems vendors and network planners all see evidence that mobile data volume will grow dramatically in the coming years - up to seven times from the end of 201 1 to 2018 and thus become a critical driver of traffic growth.
[0006] As the average video download bit rate increase due to network speed and bandwidth availability, the respective percentages of both video traffic and subscribers that view video will grow precipitously. As a consequence, a relatively small increase in the percentage of subscribers watching video can have a dramatic impact on total traffic volume.
[0007] The faster the network, the higher adoption of video. Video content providers, such as e.g. Netflix, Hulu, Apple, and others have converged on protocols classified as adaptive bit rate (ABR) streaming for premium content. There exist several
implementations of these protocols from Adobe, Apple, and Microsoft, and they all share a common approach. Effectively, they adapt in real time to network throughput and device CPU capabilities by dynamically increasing or decreasing the resolution of the video. Different versions of the same video are stored on content servers according to resolution levels and encoding types. For example, a movie or a TV news report would normally have at least five versions based on e.g. bit rate - two low-definition, one standard-definition, and two high-definition (HD) videos - 720p and 1080p.
[0008] As network conditions change, the content server switches among the different bit-rate versions to deliver the highest bit rate version that the available bandwidth will accommodate. A key behavior of Adaptive Bit Rate (ABR) streaming protocols is that they attempt to consume as much of the available network capacity as the content server can utilize and deliver the highest quality that the current network connection can support. For example, if the network can support throughput of 3.5 Mbps, then a High Definition (HD) video stream is sent to the subscriber - regardless of other, competing demands on the available bandwidth.
[0009] As operators roll out Long Term Evolution (LTE) and other very fast 4G networks:
• Premium content videos using ABR streaming protocols will consume a sizable portion of the available channel to the subscriber - regardless of device capabilities or policies related to the subscriber's data plan.
• As a result, where 3G networks support video resolutions that are predominantly in the low-definition to standard-definition range, 4G/LTE networks regularly stream HD videos requiring 3.5 Mbps per stream.
[00010] With subscriber behavior shifting to premium content in 4G/LTE networks, and streaming protocols sending the highest-quality video across a link, video traffic expands to fill the network capacity available for it. Mobile operators expecting the capacity of their 4G/LTE networks to exceed the growth requirements of video may soon discover that their pipes are loaded with HD content.
[0001 1 ] Because many Internet video applications can be categorized as cloud applications, mobile cloud traffic follows a curve similar to video. Mobile devices have memory and speed limitations that might prevent them from acting as media
consumption devices, were it not for cloud applications and services. Cloud applications and services, such as e.g. Netflix, YouTube, Pandora, and Spotify allow mobile users to overcome the memory capacity and processing power limitations of mobile devices.
[00012] Video Commerce, Video e-Commerce is the practice of using video content to promote, sell and support commercial products or services on the Internet. The video can be downloaded and played or streamed to the viewer. A typical video commerce application would involve a video which contains a number of clickable objects so that the viewer can click on any of those objects for further information or to purchase them. However, the clickable object may not always be within the video itself, but part of the Flash or HTML5 player used to play back the video. Video commerce can take place over any Internet-enabled communications device, such as e.g. a Personal Computer, a laptop, a PDA, a mobile phone, or a smart phone. [00013] One possible use case involving use of a video related application is where a video frame of a running video shows a hotspot near a specific item which can be clicked. When a user chooses to click it, an advertisement appears, which can also include one or more of video, image, audio, pdf etc., in the same video application window and no redirection on some webpage or creation of another tab in web browser happen, thereby allowing the user to complete a purchase. In the meantime video is continuing to stream/buffer, and thus consume resources, irrespective of whether or not this is of any further use to the user.
[00014] In another use case which may e.g. be applicable to video comments on YouTube, a video sharing site receives millions of views from visitors who many times provide thousands of textual user comments. Consider a use case of video comments streamed directly by visitors and saving on timeline or similar way. These thousands of video comments for a single video upload would create high traffic scenarios which current videos are not getting. A single video can be associated with a large number of video comments streamed by users all across the world from their smartphone, Laptops, desktop and/or tablets.
[00015] According to yet another scenario, a university professor live broadcasts a video on YouTube, or any other video distributing provider and students accessing the video remotely are asking questions which are directly streamed via their webcam or smartphone front camera and saved on the timeline so as to help other students who access the broadcast video with in-video comments available on the timeline in future date.
[00016] According to another scenario it is possible to distribute video advertisements on popular in-video video comments on timeline of a video uploaded on YouTube. As video uploads grow in popularity, so are the many of its video comments provided (or streamed from user devices and is now saved on server) by visitors of video.
[00017] In another scenario it is possible to download a pdf file (or some file) from a server within a streaming video in a video application by clicking a tag (displayed on a video frame) carrying a server link to the pdf file, would trigger another stream of traffic between a server associated with the application and a user device while an original video is continuing to buffer/stream. A small window can appear inside a video application window displaying the pdf or the pdf gets loaded into the video application window itself having a size about the same as video application window size. [00018] According to yet another scenario, in-video tagging can lead to another whole lot of new media streams traffic and thereby increasing traffic, to a significantly larger extent than what we experience today. In-video tagging can lead to associating different type of data streams, such as e.g. image, website, and video from respective servers dedicated to keep that kind of data. [00019] What is common to all scenarios mentioned above is that, while services previously used commonly were basically based on one type of streamed class or type of traffic, the mentioned services give rise to excessive amounts of traffic of different types, which are commonly distributed in parallel. As a consequence, new problems of how to handle this traffic arise. [00020] Currently, when looking at the operator or carrier end, the tariffs applied by the operator or carrier can be grouped broadly into one of the following categories:
• Quota-based - Subscribers purchase a monthly quota of data volume, beyond which access to the network is throttled until the beginning of the next billing period. A breach of quota typically results in the application of special charges.
• Speed-based - Subscribers are offered different levels of network speed, from which they can purchase according to a monthly plan based on their selection. A quota may or may not be built into the plan. Some speed-based plans enforce fair use policies for the top percentile of subscribers.
• Unlimited with fair use policy - Subscribers are offered unlimited data volume with unspecified bandwidth. The operator targets heavy users - say, the top 2% by volume - for the application of fair use policies. When subscribers reach the fair use threshold, their access to the network is throttled down to a low but functional bit rate. For some networks, this bit rate provides sufficient bandwidth for web browsing but impacts the performance of standard-definition videos. · Unlimited without fair use policy - The operator provides an unlimited data plan but does not impose a fair use parameter. Instead, network performance for all subscribers is capped at an upper bit rate, such as e.g. 1 Mbps.
• New models (e.g., application-based) - These plans are emerging in different forms, with operators targeting specific subscriber demographics with bundled services providing access to certain applications. Obviously, there are new challenges for how to best make use of the available bandwidth by different types or classes of traffic.
[00021 ] EP 2525550 is a patent application which refers to Controlling QoS provided to over the top applications in a telecommunication system.
[00022] The disclosed method involves receiving a registration request from the OTT application, and configuring an application programming interface (API) at a service delivery platform to have dependent rules that provision a QoS level for the OTT application responsive to registration request. The QoS is controlled through the network provided for a communication session between the user equipment (UE) and OTT application responsive to the QoS level provisioned for the OTT application. [00023] US 201 10219431 discloses a method which involves sending a request having subscriber identification from an OTT application server to a telecommunications network with QoS requirement for an Internet Protocol (IP) based application session and determining an appropriate QoS level for subscriber by a network policy node. The determined QoS level is then enforced for the IP-based application session with the OTT service provider, by a network gateway.
[00024] US 20130329550 discloses a method which involves receiving a connection request that includes information identifying a particular application, from a user device. The particular application associated with the group of classes of traffic is identified. A group of bearer channels that are associated with the group of classes of traffic and the group of different levels of quality of service (QoS) are established. The two traffic classes associated with the user devices and particular applications are then processed through two different bearer channels, according to two different levels of QoS respectively. [00025] All documents cited above do however provide very limited mechanisms for how to impact on how to best make use of available resources when executing an application, and particularly an OTT application.
Summary
[00026] It is an objective of the present document to address, or at least alleviate, at least some of the problems described above.
[00027] According to one aspect, a method to be executed in an application server providing an application, involving a plurality of traffic flows, to a user device, is suggested. The method comprise: identifying an event triggering the application to determine application specific priorities of the traffic flows involved with the application, where the identifying is based on application specific rules; determining the application specific priorities of the traffic flows involved with the application, where also the determining is based on application specific rules; generating a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and transmitting the request to the network node. An advantage of the suggested method is that instead of allowing only the network side to determine how to prioritize different traffic flows also the application side will be able to participate in such a decision.
[00028] In a typical scenario, the application is a video application involving at least one video related traffic flow. [00029] The event triggering the application may according to one embodiment be an event initiated by the application, i.e. an automatically initiated event, while according to another embodiment it may be an event initiated by the user of the user device, i.e. a manually initiated event. Thereby, a decision on how to prioritize traffic flows may be taken with or without influence of the end user. [00030] According to one alternative embodiment, the suggested method may comprise a further step of receiving a response to the request from the network node, where the response is indicating to the application whether the requested priorities will be complied with or not by the network node. Thereby the application will be able determine how to proceed in response to such a response. A denial of a request may e.g. result in a new, alternative request.
[00031 ] The request mentioned above may comprise different data, in order to enable for the network node receiving the request to consider more or less in-data when processing a request. In its simplest case at least one of the following is included: user device identifier, identifying the user device for which a traffic flow has been set up; application identifier, identifying the application; traffic class identifier, identifying type of traffic flow; application specific priorities for traffic flows involved in the application; user identifier, identifying the registered user of the communication device; device identifier, identifying the communication device; QoS, indicating a respective requested QoS for a prioritized traffic flow, and time interval, identifying a time interval during which a requested priorities are requested.
[00032] According to another aspect, a method to be executed in a network node capable of managing policy control of an application provided to a user device by an application server is suggested. This method comprise: receiving a request from the application server, where the request comprise application specific priorities, and where the request requests how to prioritize a plurality of traffic flows associated with the application; applying operator specific rules on the requested prioritizations, and enforcing or denying the requested prioritizations based on the operator specific rules. [00033] According to one embodiment the network node forms part of a 3GPP Policy Charging and Control (PCC) architecture and the operator specific rules are Policy Control and Charging (PCC) rules, but any type of network node which is capable of managing policy control and of handling the suggested requests as suggested herein may be applicable. [00034] The suggested enforcing may be arranged so that it comprises: applying the requested priorities in case the requested priorities are compatible with the operator specific rules, or ignoring the requested priorities in case the requested priorities are incompatible with the operator specific rules.
[00035] According to one embodiment, where QoS is one parameter included in a request, the step of applying operator specific rules on the received request comprises: comparing, for each traffic flow included in the request, a respective QoS demanded by the application with resources available for the application, and applying the requested priorities and QoS in case the QoS requests meet with the available resources, or ignoring the requested priorities and QoS in case the QoS requests do not meet with the available resources.
[00036] According to one alternative embodiment is determined, how to handle the request and the result of such a determination is provided to the application. More specifically the method according to this alternative embodiment comprises either transmitting a response to the request to the application, informing the application that the requested priorities will be complied with in case the requested priorities are compatible with the operator specific rules, or transmitting a response to the request to the application, informing the application that the requested priorities will not be complied with in case the requested priorities are incompatible with the operator specific rules.
[00037] According to yet another aspect an application server capable of providing an application, involving a plurality of traffic flows, to a user device, is suggested. Such an application server is adapted to: identify an event triggering the application to determine application specific priorities of the traffic flows involved with the application, where the identifying is based on application specific rules; determine the application specific priorities of the traffic flows involved with the application, where also the determining is based on application specific rules; generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the network node.
[00038] The application server may, according to one embodiment be adapted to handle an event triggering the application, where the event is initiated by the
application, while, according to another embodiment, the application server is adapted to handle an event triggering the application, where the event is initiated by the user of the user device.
[00039] According to one embodiment the application server is further adapted to receive a response to the request from the network node, where the response is indicating to the application whether the requested priorities will be complied with or not by the network node.
[00040] The application server may be configured to provide different data into a request, such that the request comprise at least one of: user device identifier, identifying the user device for which a traffic flow has been set up; application identifier, identifying the application; traffic class identifier, identifying type of traffic flow; application specific priorities for traffic flows involved in the application; user identifier, identifying the registered user of the communication device; device identifier, identifying the
communication device; QoS, indicating a respective requested QoS for a prioritized traffic flow, and time interval, identifying a time interval during which a requested priorities are requested.
[00041 ] According to another aspect an application server capable of providing an application, involving a plurality of traffic flows, to a user device, is suggested, where the application server comprise a processor and a memory, the memory comprising instructions executable by the processor, whereby the application server is operative to: identify, based on application specific rules, an event triggering the application to determine application specific priorities of the traffic flows involved with the application; determine, based on application specific rules, the application specific priorities of the traffic flows involved with the application; generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the network node via a communication unit.
[00042] According to yet another aspect a computer program is suggested where the computer program is executable on an application server capable of providing an application, involving a plurality of traffic flows, to a user device. The computer program is comprising instructions which, when run on the application server, causes the application server to: identify an event triggering the application to determine
application specific priorities of the traffic flows involved with the application, where the identifying is based on application specific rules; determine, application specific priorities of the traffic flows involved with the application, where also the determining is based on application specific rules; generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the network node via a communication unit. [00043] According to yet another aspect a computer program product, comprising a computer program, such as the one suggested above, and a computer readable means on which the computer program is stored, is suggested.
[00044] According to another aspect a network node capable of managing policy control of an application provided to a user device by an application server is suggested. This network node is adapted to: receive a request comprising application specific priorities, from the application server, where the request is requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or denying the requested prioritizations, based on the operator specific rules.
[00045] Even though the network node may be any type of network node which is capable of managing policy control and of handling the suggested request, the network node may according to one embodiment form part of a 3GPP Policy Charging and Control (PCC) architecture, while the operator specific rules are Policy Control and Charging (PCC) rules.
[00046] According to one embodiment the network node is adapted to enforce or deny the requested prioritizations by applying the requested priorities in case the requested priorities are compatible with the operator specific rules, or ignoring the requested priorities in case the requested priorities are incompatible with the operator specific rules.
[00047] According to one embodiment, which is applicable in case the request comprise requested QoS, the network node is adapted to apply operator specific rules on the received request by comparing, for each traffic flow included in the request, a respective QoS demanded by the application with resources available for the application, and by applying the requested priorities and QoS in case the QoS requests meet with the available resources, or ignoring the requested priorities and QoS in case the QoS requests do not meet with the available resources. [00048] According to one embodiment, enabling the network node to determine how to handle a request and to inform the application of the decision, the network node is further adapted to: transmit a response to the request to the application, informing the application that the requested priorities will be complied with in case the requested priorities are compatible with the operator specific rules, or transmit a response to the request, to the application, informing the application that the requested priorities will not be complied with in case the requested priorities are incompatible with the operator specific rules.
[00049] According to another aspect a network node capable of managing policy control of an application provided to a user device by an application server, is suggested, where the network node comprise a processor and a memory, the memory comprising instructions executable by the processor, whereby the network node (1 100) is operative to: receive a request comprising application specific priorities from the application server, where the request is requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
[00050] According to another aspect, a computer program executable on a network node capable of managing policy control of an application provided to a user device by an application server is suggested, where the computer program comprise instructions which, when run on the network node causes the network node to: receive a request comprising application specific priorities from the application server,, where the request is requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
[00051 ] According to another aspect a computer program product , comprising a computer program, such as the one described above, and a computer readable means on which the computer program is stored, is suggested. Brief description of drawings
[00052] Embodiments will now be described in more detail in relation to the
accompanying drawings, in which:
Fig. 1 is an overview of a system according to prior art comprising an application server, capable of providing services in the form of executable applications to user devices via an operator domain, where servers are providing the service to the user devices in the form of traffic flows.
Fig. 2 is a block scheme, illustrating how an application server can interact with a PCC according to prior art. Fig. 3 is an illustration of a possible scenario, where a video based application is engaging a plurality of servers, each of which is capable of providing different types of user content.
Fig. 4 is a block scheme, illustrating how an application server can extend the interaction with a PCC, according to one embodiment. Fig. 5 is a signalling scheme illustrating a mechanism for enabling an application to request priorities for associated traffic flows from a PCC.
Fig. 6 is a flow chart, illustrating a method for identifying a requirement for requesting priorities of traffic flows from a PCC, and for transmitting such a request.
Fig. 7 is another flow chart, illustrating a method for recognising and processing a request for prioritization of traffic flows received from an application server.
Fig. 8 is a block scheme illustrating an application server according to a first
embodiment, configured to execute the method suggested herein with reference to Fig. 6. Fig. 9 is another block scheme illustrating a an application server according to a second embodiment, configured to execute the method, such as the one suggested herein with reference to Fig. 6.
Fig. 10 is yet another block scheme illustrating a network node according to a first embodiment, configured to execute a method, such as the one suggested herein with reference to Fig. 7
Fig. 1 1 is another block scheme illustrating a network node according to a second embodiment, configured to execute a method, such as the one suggested herein with reference to Fig. 7
Detailed description
[00053] As will be described in more detail below, with reference to various examples, a method is suggested for enabling an application, involving a plurality of traffic flows, to request an arrangement capable of applying policy control how to prioritize the respective traffic flows during the policy control, thereby effecting decisions which up to date has been taken corresponding arrangements only based on the operators preferences. A method is also suggested for handling such a request by arrangement. In the present document the mentioned policy control functionality will be provided in a 3GPP Policy Charging and Control (PCC) architecture, according to ETSI TS 123 203, v10.8.0 (2012-1 1 ), but any type of architecture, capable of applying policy control on an application may be applicable.
[00054] An overview of a context in which the suggested mechanism can be executed is described in Fig. 1 , where and Application Server (AS) 1 10 of a network 100 is capable of servicing a plurality of user devices, here represented by user device 1 -3, 120a, 120b, 120c, with applications which, when executed at one of the user devices, are presented on the user devices in a plurality of different traffic streams, typically comprising a Video traffic stream and at least one additional traffic stream, which may be another video traffic stream or any other type of traffic stream. Traffic streams belonging the same traffic class, such as e.g. video streams, are typically provided from a specific server from a plurality of different available servers, here represented by server! -3, 130a, 130b, 130c. The AS 1 10 has access to an operator domain 140, comprising various network nodes, including e.g. PCC, which are controlled and managed by the operator of a telecommunication network which the AS is using for providing the mentioned services/traffic flows to the user devices 120a, 120b, 120c.
[00055] Looking more specifically at PCC functionality according to the prior art, Fig. 2 is an illustration of a known PCC of an operator domain 140, where an AS, such as AS 1 10 of Fig. 1 , has access to the operator domain 140, and specifically the PCC 210 so that user traffic that is to be provided to various user devices 120a, 120b, 120c via the operator can be used by the PCC 210 in order to provide more efficient handling and managing of the various traffic flows. It is here to be understood that according to known applications, user traffic can be provided in the described direction for processing by the PCC 210, but the user cannot influence the policy decisions made by the PCC related to various traffic flows.
[00056] As illustrated in Fig. 2, PCC 210 comprise a Policy Controller 220, which is configured to make various policy decisions on the basis of various types of data, such as e.g. network data, which may include e.g. network performance information and/ or network event information; application data, which may e.g. include data on executed sessions and/or application specific information; subscriber data, which may e.g.
comprise account details, and charging data, which may e.g. comprise profile counters. The data provided to the policy controller 220 as in-data is compared to policy profiles, such as e.g. QoS and/or bandwidth policies created and provided to policy controller 220 by a Policy Designer Interface 230. Based on the outcome of the described process executed by the policy controller 220, a policy decision is then provided to a Decision Enforcer 240, which may in the present context be referred to as a Policy Control Enforcement Function (PCEF), which enforce or deny a decision e.g. on a Packet Data Network Gateway (PDN GW), or another corresponding network node, which is involved in the distribution of the mentioned traffic flows.
[00057] Today the operator can make prioritizations when managing a service based on different aspects, such as e.g. based one or more of: - Service category, such as e.g. web, file download, video.
Application, such as e.g. YouTube, Skype.
Subscription, such as e.g. Gold, Silver, Bronze.
Header fields, such as e.g. according to a range of IP addresses or port numbers. - Usage policies, such as e.g. heavy users, light users
[00058] For each of the above aspects the PCC may be used by the operator for developing rules on how to prioritize, and for applying those rules. However, the described PCC 210 only executes decisions on initiative from the operator side, without giving the application any opportunity to influence the policy decisions e.g. when it comes to how to prioritize the different traffic flows associated with execution of a specific application. With the increasing use of applications that involve a plurality of concurrently executed traffic flows, often involving one or more video traffic flows, it would in many occasions be advantageous if also the application side was able to influence how prioritizations between traffic flows associated with a respective application and a respective user device was to be executed. Therefore a method and arrangement for allowing also the application to effect the policy decision in real-time by providing input on required prioritizations is suggested.
[00059] Fig. 3 is illustrating a typical scenario, where the new mechanism described herein may be applied in an advantageous way. More specifically, figure 3 is illustrating a video based application 300, which is typically provided to users via an AS (not shown), allowing the users to access content from various servers. As indicated in Fig. 3, different servers may provide data content of different specific classes. In the present example, there are two Media servers, 310, 320, which may typically provide different video content; two Advertisement servers, 330, 340, which are typically providing different advertisements at different occasions; One Video comments server, 350, which is typically providing comments on a rendered video, and a Video comments
advertisement server 360, which is typically providing advertisements in association with providing comments. A video based application engaging one or more of the described servers will give rise to a traffic flow between that server and a user via the AS from which the application is provided. Since each of the mentioned servers will typically provide content to an application and user device on different time instances, where also a plurality of servers may provide content concurrently, it is obvious that a possibility for the video based application to determine how to prioritise different traffic streams originating from these servers at different time instances will allow the application to influence the overall user experience. [00060] Fig. 4 is a schematic illustration of how signalling between network nodes of a telecommunication system, based e.g. on a Long Term Evolution (LTE) network, or any other type of wireless or wireline telecommunication network where policy control is applied can allow an application to request how it prefers various traffic flows associated with execution of the application to be prioritized at the operator side. Fig. 4 only comprise network nodes which are of relevant importance for the understanding of the concept described herein, and, thus, any other network nodes which typically appear in telecommunication networks have been omitted for simplicity reasons. The signalling scheme comprise an operator domain 400, which has been amended as suggested above, i.e. so that it can receive and process requests from an AS 460 as suggested above, where the operator domain 400 has been provided with an interface, here referred to as a Priority Analyzer (PA) 450, via which a request, herein referred to as a Traffic Priority Message (TPM), received from an AS 460, is forwarded to the PCC 410 for further processing by the PCC. In case the TPM is not already from the beginning adapted for the PCC, the PA 450 may also be capable of decoding an adapting the TPM accordingly. Although Fig. 4 is illustrating one way signalling, i.e. a way for the application to influence the prioritization of traffic flows associated with a specific application and user device, the PCC 410 may optionally also be configured to apply two way communication with the AS via the PA by indicating to the AS whether the request will be complied with or not. PA 450 is shown as an entity which is separated from the PCC, and the PA 450 may e.g. be integrated in a Media Delivery Network (MDN) node. However, alternatively, the described PA functionality may be arranged as an integrated part of a PCC. In any event, the functionality first receiving a request from AS 460 to PCC 410 must be capable of interpreting the request so that it can be provided to and processed by PCC 410 accordingly. [00061 ] Below are three different use cases where a next generation video application might want to request its operator for better QoS as per the priorities shared by the application among various traffic flows currently active between the video application and current one or more user equipments/devices as per user activities or application activities in the video application online. In the present context a traffic flow is referred to as a connection of a certain traffic class between a server, or content source, capable of providing some data traffic to a user device, and the user device, via an AS.
Example 1 : In-video commerce
[00062] An in-video commerce based video application, i.e. an application where a commerce is displayed while a user is watching a video, or a video and a commerce being presented in the same video player instance, detects at a point in time that a user has selected 'Add to Cart' while the product video is already streaming from a media server. User decides to complete the payment transaction by connecting to a payment server from the video application itself while video is already streaming from the media server. [00063] At this point in time, the video application, which may be an OTT application, can decide to send a request to its Telecom Operator in real time for this connected user, carrying multiple priorities for various active traffic flows relating to the video application and this user device, to provide higher priority in QoS towards a particular traffic flow of application, between user device and payment server rather than user device and the media server as user now has decided to buy the item and is currently trying to complete the payment transaction. After the payment transaction is completed from inside video application window, the original priorities for various traffic flows (belonging to same class, between different classes) between the video application and user device can be retained.
[00064] The first example, suggested above, highlights a prioritization scenario involving different traffic flows active in a video application. Here each traffic flow belongs to a separate traffic class, i.e. traffic flows of different traffic classes are prioritized differently.
Example 2: Prioritizing an advertisement during buffering of a main video
[00065] Many times a user pauses a YouTube video he is looking at. During the paused state, video buffers the video. It is quite possible that YouTube can display a video advertisement streamed from its advertisement server once the user is back and try to resume the playing of the video. While the main video is buffering and the video advertisement is streaming, YouTube might request the telecom operator to provide a better QoS for the video advertisement specific traffic flow than for the main video which is buffering until the end of the video advertisement and then resumes the original QoS to the main video again.
[00066] Advertisements carry business significance for YouTube and similar applications since a user who is not watching a main video (which is paused and is buffering), instead watches an advertisement which is typically not skippable. So, requesting better QoS for video advertisement streaming for a time duration of the advertisement can be applied by a video application for its connected users at any appropriate point in time. The second example, mentioned above, is a second prioritization scenario between various traffic flows active in a video application. In this scenario, all traffic flows belong to a same traffic class, i.e. prioritization for traffic flows of one and the same traffic class is suggested. Example 3: Video sharing site providing in-video comments, advertisements on in-video comments.
[00067] Consider a video application, such as e.g., YouTube with a main video, having multiple video advertisements and multiple video comments on its timeline or similar multiple video advertisements on popular video comments, links to another video source presented via tags, objects, etc. and a video advertisement on another video source is provided via a link. All this is happening in the same video application window, and no separate links to webpages are used to direct to another webpages.
[00068] In a multiple streaming scenario where a user is connected to a video application, streaming multiple items belonging to a specific traffic class (here, for example, a video) at a point in time, the application, as per user activities in video application, can decide to provide a request to the telecom operator in real time for this connected user, with a list of priorities among the various traffic flows currently streaming between various servers (all belonging to a video traffic class but performing different tasks, such as e.g. video streaming, video advertisement streaming, in-video comment streaming and video advertisements on in-video comments streaming) associated with the video application and user device at this time instance. The suggested priority list would be used by the operator to provide QoS demanded by the application for a particular traffic flow among a set of several flows currently active in the application in relation to this user device at this point in time for an already connected user. The application can use various types of business or commercial significant input to decide on priority. By way of example, different priorities can be determined for traffic flows of one and a same traffic class, such that a required QoS for a certain traffic flow (determined based on server of origin of the flow) takes priority over other traffic flows. 1. QoS for a video advertisement from a video advertisement server
(Advertisement Server 1 ).
2. QoS for a main video streamed from a media server (Media Server 1 ). 3. QoS for video comments streamed from some other server (Video Comment Server 1 ).
4. QoS for an advertisement on popular video comments from another video advertisement server (Video Comments Advertisement Server 1 ).
5. QoS for another video link or tags (Media Server 2) started streaming in a small window inside the video application
6. QoS for a video advertisement on another video streamed (Advertisement Server 2) in a small box, i.e. a pop-up window appearing within a video player application instance.
[00069] Example 3 demonstrates nested traffic in a futuristic video application instance having a main video, multiple video comments, video advertisements on the main video and video advertisements on the video comments. [00070] The process briefly described above can be illustrated in more detail by the flow chart of Fig 5, where a user device 120 has requested an application from an AS 360. In response the AS 360 is fetching relevant data on the requested application from the user device 120, as indicated in step 5: 1. In following steps 5:2, 5:3 and 5:4 the AS 460 establishes connection with server 1 , 130a, server 2, 130b, and server 3, 130c, respectively, as well as establishing respective traffic flows between the user device 120 and the respective server. In the present example the application involves three different traffic flows at the given time instance as indicated by the figure. The steps mentioned so far are all prerequisites for execution of the described prioritization mechanism. In a typical scenario at least one of the traffic flows is a video traffic flow. [00071 ] According to one example, one of the flows may e.g. be a film provided from a media server, video comments may be provided from another server, typically referred to as a video comment server, while another stream is an advertisement provided from yet another server, which may be referred to as an advertisement server. At some time instance, during consumption of the application involving the three traffic flows mentioned above, a prioritization trigger is recognized during execution of the application by the AS 460, as indicated in step 5:5. Such a trigger is typically event based, and depends on application defined logic, such that when a certain pre-defined event is discovered by the application during application execution, a request for application of specific priorities of the presently active traffic flows is initiated. Such an event may be automatically initiated by the application, without requiring any action from the user, such that e.g. an injection of a pre-defined video advertisement in between a main video rendering by the application may trigger a request for prioritization.
Alternatively a trigger may be initiated by the application, recognising a user input, such that e.g. once a purchase is initiated by a user watching a video, the application may request a traffic flow executing the purchase to be prioritized higher than the rendering of the main video. In response to a trigger, the application generates a TPM according to a predetermined prioritization scheme, relevant for the executed event, as indicated in step 5:6. The TPM is then transmitted to a PCC via an interface, here referred to as PA, capable of recognising and decoding the TPM. The PA may be arranged as a standalone device, as indicated in Fig. 5, or as an integrated part of the PCC. The transmission is indicated in step 5:7 and forwarding from the PA to the PCC in step 5:8. The PCC will then be able to treat the content of the TPM as in-data, process the data by considering available policies, and, depending on the outcome of the processing, determine whether to enforce the decision or not.
[00072] The process described above may be executed at any time during the lifetime of the execution of an application by a user, or a group of users, in case the trigger is not relevant for only one single user. Execution of an application may include traffic flows provided from multiple traffic sources or servers of a certain traffic class, such as e.g. multiple videos streaming traffic to a user device within a single video application window of the display of the user device. Alternatively it can include multiple classes of traffic flows activated from different servers within the same video application window. [00073] The request, or TPM, is provided as a list, comprising data relevant for the respective application and traffic flows for which priorities are to be considered by the PCC. Multiple lists may be prepared, used, stored, and re-used, such that priorities may be increased or decreased based on events happening during execution of the application. Such a list comprise at least an application identifier, identifying the executing application; a user device identifier, identifying the user device executing the application and the application specific priorities which are to be requested from the PCC. In case a group of user devices are to be considered, the list may also comprise a plurality of device identifiers.
[00074] In addition, the list may comprise additional data, such as e.g. one or more of traffic class identifier, identifying the traffic class or traffic classes of the active traffic flows; user identifier, identifying the user, or users in case a group of user devices of different users are considered in the request, QoS, indicating a requested QoS which the application requests to be applied for the prioritized traffic flows. The list may also comprise a present time stamp and a time interval, indicating a time interval during which the requested priorities are requested and/or indicating the duration of respective applications. The current traffic flow state, e.g. streaming or buffering, volume or size of user data provided from a respective server may also be provided in the list. What is contained in a list will typically depend on how the operator specific rules, or policies, are configured at the operator side. In other words, all parameters and data which is/are to be considered when evaluating the operator specific rules on the operator side will be relevant to put into a list, thereby forming a respective request.
[00075] Typically a specific server will belong to a certain traffic class and any type of user device which is capable of executing an application comprising a plurality of traffic flows, such as e.g. a smartphone, a tablet, a desktop or a laptop, may be involved in execution of the suggested process.
[00076] By applying the suggested mechanism a specific application will be able to request specific mutual priorities, with or without an associated QoS, among various applied traffic flows. [00077] Fig. 6 is a flow chart illustrating a method for applying the mechanism suggested above, where the method is executed in an AS. As a prerequisite, at least one user device is executing an application which is running on the AS, where the application comprises at least two active traffic flows, set up between a respective server and the user device, via the AS.
[00078] In a first step 6: 1 , logic of the AS is identifying an event, which triggers a priority request.
[00079] In a next step 6:2, the application is determining which priorities that are to be applied in a request associated with the present trigger. This can be done by executing pre-defined logic, and may according to one embodiment include selection of a list from already stored lists, comprising event specific priorities, while according to another embodiment, further evaluations, other than only determining that a certain event has occurred, may have to be executed before relevant priorities can be determined accordingly. As a result, an already existing list may be determined and selected or a new list, relevant for the identified event may have to be provided.
[00080] Based on the determination in step 6:2 a request is generated in another step 6:3 and in a next step 6:4, the request is sent to a PCC. The method as suggested above, describe a process automatically executed by the application whenever a trigger occurs. Alternatively, typically following step 6:2, the application sets up a dialogue with the user where the user is requested to accept a prioritization request determined and suggested by the application, prior to generating and transmitting a request to PCC. In case the suggested prioritization is denied by the user, the described process is terminated and the execution of the application is continued in a conventional manner, without making any request for prioritization. [00081 ] Fig. 7 is another flow chart, illustrating a method as executed in network node of the operator, or more specifically in an arrangement forming part of a 3GPP PCC architecture or a corresponding architecture. As already mentioned, a request may initially be received by a specific entity, capable of interpreting, decoding the request, and forwarding it to the PCC, or such functionality may be integrated with the PCC.
[00082] In a first step 7: 1 a request is received by the PCC in a format recognizable by the PCC. In a next step 7:2 the PCC, or more specifically a Policy and Charging Rules Function (PCRF) of the PCC is applying operator specific rules, which may typically be Policy Control and Charging (PCC) rules, or any other rules which are adaptable to apply together with content of the received request, on the request.
[00083] By way of example, the available upload or download bandwidth may be limited to a maximum or minimum bits per second rates. Alternatively, an application may get restricted access to available resources if a requested priority would lead to bandwidth use which exceeds allotted monthly bandwidth use.
[00084] As a result from the previous step, the PCC will determine if and how to enforce or deny the request, as indicated with step 7:3. Alternatively, the result of the previous step, i.e. acceptance or denial of the request, may be provided to the application, as indicated in optional step 7:4. In the latter case, the communication between AS and PCC is a two-way communication rather than a one-way
communication, and the application of AS will be made aware of the outcome of its request and can take further actions in response, e.g. by initiating a new process, making another, alternative request to the PCC. Acceptance or denial of a request may rely on present performance of the network, by present user subscription, such as e.g. a gold, silver or bronze subscription giving various advantages to the user. As a general rule, the PCC will typically first consider the prioritizations made by the operator and if policies allow also to apply the priorities made by the application, these requests can be accepted. [00085] In order to be able to execute any of the methods suggested above, an AS and an arrangement capable of applying policy control need to be adapted accordingly. Therefore an AS is suggested which is capable of providing an application involving a plurality of traffic flows to a user device, where the AS comprise means adapted to: Identify, on the basis of application specific rules, an event triggering the application to determine application specific priorities of the traffic flows involved with the application, i.e. how to prioritize the active traffic flows associated with the application when executed by the user device; determining, based on application specific rules, the application specific priorities of the traffic flows involved with the application; generating a request for an arrangement capable of applying policy control to apply the determined priorities during policy control of the application, i.e. each active traffic flow of the executed application when executed by the user device, and transmitting, the request , to the arrangement. [00086] An AS capable of executing the method as described above with reference to Fig. 6, i.e. an AS capable of providing an application, involving a plurality of traffic flows, to a user device, is adapted to: identify an event triggering the application to determine application specific priorities of the traffic flows involved with the application, on the basis of application specific rules; determine the application specific priorities of the traffic flows involved with the application, on the basis of application specific rules;
generate a request for an arrangement capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the arrangement.
[00087] An AS, according to one embodiment, comprising a plurality of interacting units will now be described with reference to the block scheme of Fig. 8. It is to be understood that the AS, as described below, is a simplified configuration and that a conventional AS typically comprise additional functionality. However, any functionality not needed for the understanding of the mechanism as described with reference to Fig. 6 has been omitted in Fig. 8. [00088] The AS 800 of Fig. 8 comprises Identifying means, here represented by an identifying unit 810, adapted to identify an event triggering a priority request. As already mentioned above, this is typically achieved by logic recognising the occurrence of a predefined event, or a number of events, which may be application initiated, user initiated or a combination of both. In case the AS 800 is adapted to request approval of a request from the user, the identifying means may also be adapted to initiate such a dialogue with the user.
[00089] The AS 800 also comprises Determining means, here represented by a determining unit 820, adapted to determine application specific priorities to be applied in response to the identified trigger. A trigger may indicate a specific pre-determined and stored priority, set up to be applied for the relevant traffic flows. Alternatively, the determining unit 820 may be configured to determine required priorities after
considering some data relevant for the application, such as e.g. number of users presently executing the application, indications of relative priorities of different users, specifications of paid and free application related content, thereby forming a specific user group, or user device capabilities. Priorities of users of the application.
[00090] Generating means, here represented by a generating unit 830 is configured to generate a request in a suitable format which comprises the determined priorities.
Generating a request will include assembling a list of suitable in-data for the policy control functionality. As mentioned above, the amount of in-data in the list for the policy control functionality to consider may differ, dependent e.g. on one or more of:
application, time, user device, user profile, subscription profile, content, triggering event.
[00091 ] Communicating means, here referred to as a communication unit 840 is configured to transmit the request to policy control functionality, either directly, or via any intermediate functionality capable of adapting the request accordingly, as described herein. In case the policy control functionality is configured to provide a response of the request, the communicating unit 840 is also configured to receive such a response, for further processing via appropriate functionality. The determining unit 820 may e.g. be adapted to process such a response, which may e.g. result in the generating of another request. Furthermore, in case the AS 800 is configured to request approval of a request from the user, the communicating unit 840 may also be configured to communicate such a dialogue with the user, or, alternatively, separate communication means may be configured for such a purpose. Any type of communication means capable of establishing wireless or wireline communication between the AS and the policy control functionality may be used for this purpose.
[00092] The AS 800 also comprise memory 850 e.g. for storing priority lists to be used for generating requests, as suggested above. The memory 850 can be any combination of read and write memory (RAM) and read only memory (ROM).
[00093] The AS suggested above may be configured as comprising hardware, software or a combination of both, and may comprise one or more processors, such as e.g. one or more Central Processing Units (CPU) or Application Special Integrated Circuits (ASIC), controlling a plurality of interacting units or modules, arranged such that functionality of each unit or module correspond to the functionality of respective means as described above. Therefore, any of the units suggested above, may be replaced by software related modules, executing corresponding functionality.
[00094] According to another embodiment, an AS 900 is configured as illustrated in Fig. 9, where the AS 900 comprise a processor 910, and a memory 920, where the memory 920 comprise instructions executable by the processor 910, whereby the AS 900 is operative to: identify an event triggering the application to determine application specific priorities of the traffic flows involved with the application, on the basis of application specific rules; determine the application specific priorities of the traffic flows involved with the application, on the basis of application specific rules; generate a request for an arrangement capable of applying policy control to apply the determined priorities during policy control of the application, and transmit the request to the arrangement.
[00095] Accordingly a computer program is also suggested which when run on an AS 900 causes the AS 900 to execute the method steps as suggested above. Such a computer program may be provided as a computer program product 950, comprising the computer program and a computer readable means, such as e.g. a DVD, on which the computer program is stored. [00096] The AS 900 as suggested above may also comprise executable instruction arranged so that the AS 900 is operative to execute any of the functionality suggested above, with reference to the units of Fig. 8.
[00097] A network node capable of providing policy control functionality, corresponding to what can e.g. be provided from a 3GPP PCC environment, which is capable of executing the method as describe above, with reference to Fig. 7. is adapted to: receive a request from the application server, where the request comprise application specific priorities, request how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
[00098] According to one embodiment, the network node mentioned above can be described as indicated below with reference to Fig. 10.
[00099] The network node 1000 comprises Communicating means, here referred to as a communication unit 1010, capable of receiving a request originating from an AS, as described above, where the communication unit 1010 may be configured to decode and adapt the request so that it can be further processed by the network node 1000 or, alternatively, it can be adapted to receive a request via a PA, as described above, or any corresponding entity. In the latter case, a PA may forward a request to the network node over a standard interface, such as e.g. the Gx interface. Also in this case any type of communication means capable of establishing wireless or wireline communication between the AS and the policy control functionality may be used for this purpose. In case the PA form part of the described network node, the communication unit 1010 or another communication unit may be further adapted to group or categorize received TPMs in real time, based on some characteristics or commonality before sending them to the PCC. Such grouping or categorizing may be based on pre-defined process logic rules. Accordingly TPMs may be arranged into application specific request queues, where the content of the different queues are handled in a certain pre-defined order. The mentioned feature for grouping or categorizing may be particularly useful if a large amount of TPMs, received from a range of heterogeneous applications need to be handled. By way of example, TPMs having similar priorities for similar types of traffic flows may be grouped together. In case the PA is configured as a standalone unit, corresponding functionality may be provided also on such a unit.
[000100] The network node 1000 also comprises Policy controlling means, here referred to as a policy controlling unit 1020, which corresponds to the Policy Controller 220 of fig. 3, configured to apply operator specific rules on the received request. Since in-data is provided in a request provided from an AS, further considerations need to be taken, when considering also multiple event triggered traffic flow priorities, compared to conventional Policy control functionality provided from a 3GPP PCC environment.
Applying operator specific rules here implies applying pre-defined profiles on content of requests in order to determine if the requested priorities can be applied with, and in case the request can indeed be complied with, how to enforce the request. Enforcing means, here represented by an enforcing unit 1030, which corresponds to the Decision Enforcer 440 of Fig 3, or a PCEF of a 3GPP PCC environment, is here configured to enforce or deny the request. In case the PCC is configured to also provide a response to the request the AS, the enforcing unit 1030 is also configured to generate such a response and to transmit the response to the AS via the communication unit 1010.
[000101 ] The network node 1000 also comprise memory 1040 e.g. for storing profiles to be used, as suggested above. The memory 1040 can be any combination of read and write memory (RAM) and read only memory (ROM). The network node described above may be configured as comprising hardware , software, or a combination thereof, and may comprise one or more processors, such as e.g. one or more Central Processing Units (CPU) or Application Special Integrated Circuits (ASIC), controlling a plurality of interacting units or modules, arranged such that functionality of each unit or module correspond to the functionality of respective means as described above. Consequently, one or more units described above, may be replaced by a corresponding software based module, capable of providing corresponding functionality.
[000102] According to another embodiment, a network node, capable of operating as suggested above is configured as illustrated in Fig. 1 1 , where the network node 1 100 comprise a processor 1 1 10, and a memory 1 120, where the memory 1 120 comprise instructions executable by the processor 1 1 10, whereby the AS 1 100 is operative to: receive a request from the application server, comprising application specific priorities, requesting how to prioritize a plurality of traffic flows associated with the application; apply operator specific rules on the requested prioritizations, and enforce or deny the requested prioritizations based on the operator specific rules.
[000103] Accordingly a computer program is also suggested which when run on a network node 1 100, as suggested above, causes the network node 1 100 to execute the method steps as suggested above. Such a computer program may be provided as a computer program product 1 150, comprising the computer program and a computer readable means, such as e.g. a DVD, on which the computer program is stored.
[000104] The network node 1 100 as suggested above may also comprise executable instruction arranged so that the network node 1 100 is operative to execute any of the functionality suggested above, with reference to the units of Fig. 10. [000105] It is to be understood that the choice of names for the interacting units, as well as the naming of the units within this disclosure are only for exemplifying purpose, and nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested procedure actions. [000106] It should also be noted that the units described in this disclosure can be regarded as logical entities and not with necessity as separate physical entities.

Claims

Claims
1. A method executed in an application server providing an application, involving a plurality of traffic flows, to a user device, the method comprising:
- identifying (6:1 ) , based on application specific rules, an event triggering the application to determine application specific priorities of the traffic flows involved with the application;
- determining (6:2), based on application specific rules, the application specific priorities of the traffic flows involved with the application;
- generating (6:3) a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and
- transmitting (6:4) the request to the network node.
2. The method according to claims 1 , wherein the application is a video application involving at least one video related traffic flow.
3. The method according to any of claims 1 or 2, wherein the event triggering the application is an event initiated by the application.
4. The method according to any of claims 1 or 2, wherein the event triggering the application is an event initiated by the user of the user device.
5. The method according to any of claims 1 -4, comprising the further step of: - receiving, from the network node, a response to the request, indicating to the application whether the requested priorities will be complied with or not by the network node.
The method according to any of claims 1 -5, wherein the request comprise at least one of:
- user device identifier, identifying the user device for which a traffic flow has been set up;
- application identifier, identifying the application;
- traffic class identifier, identifying type of traffic flow;
- application specific priorities for traffic flows involved in the application;
- user identifier, identifying the registered user of the communication device;
- device identifier, identifying the communication device;
- QoS, indicating a respective requested QoS for a prioritized traffic flow, and
- time interval, identifying a time interval during which a requested priorities are requested.
A method executed in a network node capable of managing policy control of an application provided to a user device by an application server, the method comprising:
- receiving (7:1 ) , from the application server, a request comprising application specific priorities, requesting how to prioritize a plurality of traffic flows associated with the application;
- applying (7:2) operator specific rules on the requested prioritizations, and - enforcing or denying (7:3) the requested prioritizations based on the operator specific rules.
8. The method according to claim 7, wherein the network node forms part of a
3GPP Policy Charging and Control (PCC) architecture and the operator specific rules are Policy Control and Charging (PCC) rules.
9. The method according to claims 7 or 8, wherein the enforcing comprises: applying the requested priorities in case the requested priorities are compatible with the operator specific rules, or
- ignoring the requested priorities in case the requested priorities are
incompatible with the operator specific rules.
10. The method according to claim 9 wherein applying operator specific rules on the received request comprises comparing, for each traffic flow included in the request, a respective QoS demanded by the application with resources available for the application, and'
- applying the requested priorities and QoS in case the QoS requests meet with the available resources, or
- ignoring the requested priorities and QoS in case the QoS requests do not meet with the available resources.
1 1 . The method according to claim 10, comprising the further step of: - transmitting, to the application, a response to the request, informing the application that the requested priorities will be complied with in case the requested priorities are compatible with the operator specific rules, or
- transmitting, to the application, a response to the request, informing the
application that the requested priorities will not be complied with in case the requested priorities are incompatible with the operator specific rules.
12. An application server (800,900) capable of providing an application, involving a plurality of traffic flows, to a user device, the application server (800,900) being adapted to:
- identify, based on application specific rules, an event triggering the
application to determine application specific priorities of the traffic flows involved with the application;
- determine, based on application specific rules, the application specific
priorities of the traffic flows involved with the application;
- generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and
- transmit the request to the network node.
13. The application server (800,900) according to claims 12, wherein the application is a video application involving at least one-video related traffic flow.
14. The application server (800,900) according to any of claims 12 or 13, wherein the application server (800,900) is adapted to handle an event triggering the application, which event is initiated by the application.
15. The application server (800,900) according to any of claims 12 or 13, wherein the application server (800,900) is adapted to handle an event triggering the application, which event is initiated by the user of the user device.
16. The application server (800,900) according to any of claims 12-15, wherein the application server (800,900) is further adapted to:
- receive, from the network node, a response to the request, indicating to the application whether the requested priorities will be complied with or not by the network node.
17. The application server (800,900) according to any of claims 12-16, wherein the application server (800,900) is adapted to generate a request comprising at least one of:
- user device identifier, identifying the user device for which a traffic flow has been set up;
- application identifier, identifying the application;
- traffic class identifier, identifying type of traffic flow;
- application specific priorities for traffic flows involved in the application;
- user identifier, identifying the registered user of the communication device;
- device identifier, identifying the communication device;
- QoS, indicating a respective requested QoS for a prioritized traffic flow, and
- time interval, identifying a time interval during which a requested priorities are requested.
18. An application server (900) capable of providing an application, involving a plurality of traffic flows, to a user device, the application server (800,900) comprising a processor (910) and a memory (920), the memory (920) comprising instructions executable by the processor (910), whereby the application server (900) is operative to:
- identify, based on application specific rules, an event triggering the
application to determine application specific priorities of the traffic flows involved with the application;
- determine, based on application specific rules, the application specific
priorities of the traffic flows involved with the application;
- generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and
- transmit the request to the network node via a communication unit (930).
19. A computer program executable on an application server (900) capable of
providing an application, involving a plurality of traffic flows, to a user device, the computer program comprising instructions (940) which, when run on the application server (900) causes the application server (900) to:
- identify, based on application specific rules, an event triggering the
application to determine application specific priorities of the traffic flows involved with the application;
- determine, based on application specific rules, the application specific
priorities of the traffic flows involved with the application;
- generate a request for a network node capable of applying policy control to apply the determined priorities during policy control of the application, and - transmit the request to the network node via a communication unit (930).
20. A computer program product (950), comprising a computer program according to claim 19 and a computer readable means on which the computer program is stored.
21 . A network node (1000, 1 100) capable of managing policy control of an application provided to a user device by an application server, the network node being adapted to:
- receive, from the application server, a request comprising application specific priorities, requesting how to prioritize a plurality of traffic flows associated with the application;
- apply operator specific rules on the requested prioritizations, and
- enforce or denying the requested prioritizations based on the operator
specific rules.
22. The network node (1000,1 100) according to claim 21 , wherein the network node (1000, 1 100) forms part of a 3GPP Policy Charging and Control (PCC)
architecture and the operator specific rules are Policy Control and Charging (PCC) rules.
23. The network node (1000,1 100) according to claims 21 or 22, wherein the network node (1000, 1 100) is adapted to enforce or deny the requested prioritizations by: applying the requested priorities in case the requested priorities are compatible with the operator specific rules, or - ignoring the requested priorities in case the requested priorities are
incompatible with the operator specific rules.
24. The network node (1000,1 100) according to claim 23 wherein the network node (1000, 1 100) is adapted to apply operator specific rules on the received request by comparing, for each traffic flow included in the request, a respective QoS demanded by the application with resources available for the application, and by:
- applying the requested priorities and QoS in case the QoS requests meet with the available resources, or
- ignoring the requested priorities and QoS in case the QoS requests do not meet with the available resources.
25. The network node (1000,1 100) according to claim 24, further adapted to:
- transmit, to the application, a response to the request, informing the
application that the requested priorities will be complied with in case the requested priorities are compatible with the operator specific rules, or
- transmit, to the application, a response to the request, informing the
application that the requested priorities will not be complied with in case the requested priorities are incompatible with the operator specific rules.
26. A network node (1000, 1 100) capable of managing policy control of an application provided to a user device by an application server, the network node (1 100) comprising a processor (1 1 10) and a memory (1 120), the memory (1 120) comprising instructions executable by the processor (1 1 10), whereby the network node (1 100) is operative to: - receive, from the application server, a request comprising application specific priorities, requesting how to prioritize a plurality of traffic flows associated with the application;
- apply operator specific rules on the requested prioritizations, and
- enforce or deny the requested prioritizations based on the operator specific rules.
27. A computer program executable on a network node (1 100) capable of
managing policy control of an application provided to a user device by an application server, the computer program comprising instructions (1 140) which, when run on the network node (1000) causes the network node (1 100) to:
- receive, from the application server, a request comprising application specific priorities, requesting how to prioritize a plurality of traffic flows associated with the application;
- apply operator specific rules on the requested prioritizations, and
- enforce or deny the requested prioritizations based on the operator specific rules.
28. A computer program product (1 150), comprising a computer program according to claim 27 and a computer readable means on which the computer program is stored.
PCT/SE2014/051204 2014-10-10 2014-10-10 Method and arrangements for prioritization of traffic flows in a telecommunication network WO2016056967A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/051204 WO2016056967A1 (en) 2014-10-10 2014-10-10 Method and arrangements for prioritization of traffic flows in a telecommunication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/051204 WO2016056967A1 (en) 2014-10-10 2014-10-10 Method and arrangements for prioritization of traffic flows in a telecommunication network

Publications (1)

Publication Number Publication Date
WO2016056967A1 true WO2016056967A1 (en) 2016-04-14

Family

ID=51871262

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2014/051204 WO2016056967A1 (en) 2014-10-10 2014-10-10 Method and arrangements for prioritization of traffic flows in a telecommunication network

Country Status (1)

Country Link
WO (1) WO2016056967A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114024917A (en) * 2020-07-15 2022-02-08 中国移动通信集团终端有限公司 Method, device, equipment and storage medium for guaranteeing internet service bandwidth

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110145319A1 (en) * 2009-12-15 2011-06-16 Dolan Michael F Group session management and admission control of multiple internet protocol flows
US20110219431A1 (en) 2010-03-04 2011-09-08 Haseeb Akhtar System and method of quality of service enablement for over the top applications in a telecommunications system
US20110317558A1 (en) * 2010-06-28 2011-12-29 Alcatel-Lucent Canada, Inc. Method and system for generating pcc rules based on service requests
EP2525550A1 (en) 2011-05-20 2012-11-21 Telefonaktiebolaget L M Ericsson (publ) Controlling quality of service provided to over the top applications in a telecommunications system
US20130329550A1 (en) 2012-06-07 2013-12-12 Verizon Patent And Licensing, Inc. Quality of service treatement for applications with multiple traffic classes

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110145319A1 (en) * 2009-12-15 2011-06-16 Dolan Michael F Group session management and admission control of multiple internet protocol flows
US20110219431A1 (en) 2010-03-04 2011-09-08 Haseeb Akhtar System and method of quality of service enablement for over the top applications in a telecommunications system
US20110317558A1 (en) * 2010-06-28 2011-12-29 Alcatel-Lucent Canada, Inc. Method and system for generating pcc rules based on service requests
EP2525550A1 (en) 2011-05-20 2012-11-21 Telefonaktiebolaget L M Ericsson (publ) Controlling quality of service provided to over the top applications in a telecommunications system
US20130329550A1 (en) 2012-06-07 2013-12-12 Verizon Patent And Licensing, Inc. Quality of service treatement for applications with multiple traffic classes

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114024917A (en) * 2020-07-15 2022-02-08 中国移动通信集团终端有限公司 Method, device, equipment and storage medium for guaranteeing internet service bandwidth

Similar Documents

Publication Publication Date Title
US11405310B2 (en) Method and apparatus for selecting processing paths in a software defined network
US10887470B2 (en) Method and apparatus for managing resources in a software defined network
US10805837B2 (en) Context aware and adaptive QOS/QOE target definition in 5G
US10511724B2 (en) Method and apparatus for adaptive charging and performance in a software defined network
KR102059867B1 (en) Methods and apparatus for managing network resources used by multimedia streams in a virtual pipe
US9350624B2 (en) Dynamic assignment of connection priorities for applications operating on a client device
Kleinrouweler et al. Delivering stable high-quality video: An SDN architecture with DASH assisting network elements
EP3103278B1 (en) System, method and software product for content delivery
US9549010B2 (en) Method and apparatus for media session identification, tracking, and analysis
US8881212B2 (en) Home network management
US20140149562A1 (en) Method and system for providing user-based bandwidth management
US20140244792A1 (en) Distributing intelligence across networks
TWI680662B (en) Method for distributing available bandwidth of a network amongst ongoing traffic sessions run by devices of the network, corresponding device
US9197559B1 (en) Adaptive streaming using non-local information
US9621607B2 (en) Systems and languages for media policy decision and control and methods for use therewith
US20130311667A1 (en) Methods and systems for dynamic policy evaluation
Szabó et al. Media QoE enhancement with QUIC
US20180270160A1 (en) Pcc control of http adaptive bit rate video streaming protocols
EP2884717A1 (en) Systems for media policy decision and control and methods for use therewith
EP3669506B1 (en) Stream control system for use in a network
WO2016056967A1 (en) Method and arrangements for prioritization of traffic flows in a telecommunication network
EP3017585B1 (en) Bandwith policy management in a self-corrected content delivery network
US8788656B2 (en) System and method for video caching based on available resources
US11863465B1 (en) Local network traffic prioritization for improved quality of service
US20230412479A1 (en) Local management of quality of experience in a home network

Legal Events

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

Ref document number: 14796309

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14796309

Country of ref document: EP

Kind code of ref document: A1