WO2013017163A1

WO2013017163A1 - Method and network device for traffic flow treatment in a core network of a communication network

Info

Publication number: WO2013017163A1
Application number: PCT/EP2011/063259
Authority: WO
Inventors: Jochen Eisl; Gerhard Kuhn
Original assignee: Nokia Siemens Networks Oy
Priority date: 2011-08-02
Filing date: 2011-08-02
Publication date: 2013-02-07

Abstract

The present invention relates to networks and provides a method and network devices for traffic flow treatment in a core network of a communication network. The method comprises receiving information in relation to a streaming session of a user, analyzing the information of the streaming session in view of a quality of service policy, and controlling a traffic flow in the core network according to the analysis of the information of the streaming session.

Description

Title

Method and network device for traffic flow treatment in a core network of a communication network

Technical field

The invention relates to communication networks. Embodiments of the present invention relate generally to mobile communications and more particularly to network devices and methods in communication networks. In particular, the invention relates to a method, to network devices and a network system for traffic flow treatment in a core network of a communication network. Moreover, the present invention relates to a computer program product and to a computer-readable medium.

Background

Networks are based on architectures which may be under development. 3GPP is one group which develops networks worldwide and provides standards for communication networks and devices for networks.

3GPP provides mobile network architectures of the third generation with radio access based on UMTS and further optimizations comprising technologies of HSPA. Further evolutions of networks are introduced with 3GPP release 8 TS23.002, which comprises a new type of radio access called LTE (long term evolution). Architectural changes also have been specified for the mobile core network named EPC (evolved packet core) which may connect mobile users apart from LTE via legacy 3GPP radio access or even non- 3GPP accesses, such as WLAN.

Multimedia streaming in public land mobile networks (PLMN) may be one focus of 3GPP standardization. The evolved packet core is a part of the core network, which was introduced in 3GPP release 8 and later. However, the EPC also considers earlier 3GPP releases, for example release 4 to 7, where operator managed application is controlled by the IP multimedia subsystem (IMS). The IMS may interact with a policy control function (PCRF) to influence resource allocation for a UMTS bearer service. Examples for multimedia streaming applications are video call and IP-TV. At present the usage of smart phones and tablet PCs simulate a significant increased usage of multimedia streaming applications in PLMNs.

It is known, that applications managed within IMS may control access to resources via a PCRF. However, no mechanisms may be known for non-IMS controlled applications in order to influence resource allocation in PLMN fourth generation networks, such as EPC. From the third generation networks (GPRS) it is known in order to reserve resources for an application, that the client may request per media the setup of a secondary PDP context with the appropriate bit rate. In LTE technology the network may establish a dedicated bearer per media via application function without any involvement of the application client. The request may be mapped by the PCRF to policy rules in order to map media session information to concrete QoS parameters for the bearer service. For example, for streaming communication services like video calls, a QoS class identifier (QCI) of value "2" or of value "4" with guaranteed bit rate service (GBR) may be used. Also for IMS controlled IP-TV the QCI of value "4" may be utilized but dependent on a policy of the operator non-GBR classes could be used, for example dependent on a subscriber profile. Other alternatives are the detection of the application via traffic detection function (TDF), which may utilize deep packet inspection functionality (DPI). The TDF may inform the PCRF about detected applications, then the PCRF may update policies in the gateway and the gateway may for example trigger the establishment of a dedicated bearer.

However, the current streaming service do neither support a SIP based interface to the IMS nor act as IMS application servers supporting an Rx-interface. At the moment there is no interaction between applications and networks. In case of congestion the rate can not be adapted so far. Thus, at current, streaming services are offered via non-GBR bearers and thus can be impacted by high cell load.

There may be a need for mechanisms to manage an increased usage of multimedia streaming applications efficiently.

Summary

According to an exemplary embodiment of the present invention, a method is provided for traffic flow treatment in a core network of a communication network comprising receiving information in relation to a streaming session of a user, analyzing the information of the streaming session in view of a quality of service policy, and controlling a traffic flow in the core network according to the analysis of the information of the streaming session.

The quality of service (QoS) may be understood as a collective effect of service performance, which may determine a degree of satisfaction of a service user. The quality of service may be characterized by combined aspects of performance factors applicable to all services, such as service operability performance, service accessibility performance, service retainability performance, service integrity performance and other factors specific to each service.

The method may provide an allocation of sufficient resources for multimedia applications by controlling traffic flow. The traffic flow may be analyzed and decisions may be made in relation to multimedia applications with high priority and low priority. For examples multimedia applications with low priority may be throttled down in order to create more capacities for high priority applications, such as video streaming.

A quality of user experience (QoE) may be related to the quality of service (QoS), but may differ in that while the quality of service may attempt to objectively measure the service, the quality of user experience may be subjective. QoS for managing traffic flow in the core network may be utilized.

Information in relation to a streaming session of a user may be received by a network device installed in the core network, for example a Streaming Traffic Management Entity

(STME) and a Media Aware Streaming Entity (MASE). The method may be performed in real-time, which may be understood to perform several steps of the method within some seconds but not more than some minutes.. This real-time behavior may provide an effective method which may be utilized to react upon real-time need of running applications. Thus, a fast-reactive adaptation for streaming services to changed conditions within the network may be provided. A triggering condition for an adaptation may be a congestion in a 3GPP radio cell.

According to an exemplary embodiment of the present invention, the method may be performed for a non-IP multimedia subsystem controlled application within the streaming session.

A non-IP multimedia subsystem (IMS) controlled application may be an operator managed streaming service, such as a HTTP streaming. Those applications may not use Session Initiation Protocol (SIP) based session control. Thus, resource control for IP Multimedia Subsystem agnostic applications in Public Land Mobile Networks may be provided.

Moreover, there may be provided an information exchange specified between a media server or a streaming server without IMS control and PLMN network in case of required data adaptation. This may be especially applicable if a lower GBR could be allocated and the flow handling in case of handover is undefined.

According to an exemplary embodiment of the present invention, the method may further comprise intercepting information in relation to the streaming session in a path between the user and a streaming server.

By utilizing interception it may be possible to avoid further traffic within the core network. The intercepted information may be forwarded by the intercepting network device towards the originally destination of the information. For example a Realtime Control Protocol (RTCP) message, especially Receiver Reports, may be utilized by the intercepting network device in order to inform the streaming server about flow characteristics, such as the number of lost packets.

According to an exemplary embodiment of the present invention, the method may further comprise receiving trigger information in relation to a streaming session.

The trigger information may be delivered by an Operations Support System (OSS), by a Policy and Charging Rules Function (PCRF), by a server or by the user itself.

According to an exemplary embodiment of the present invention, the method may further comprise requesting identities of users located in a congested radio cell.

In a congested cell it may occur that a user may be impacted by an inability to make a connection or to obtain a service, because the devices utilized within the network for the connection or services are in use or overloaded. By identifying a user and his running application, further measures for controlling the traffic of the application may be performed.

According to an exemplary embodiment of the present invention, the method may further comprise deciding to change stream specific properties for a session stream. Stream specific properties may be understood as properties characterizing the streaming session, such as data amount to be sent or user identity indicating certain policies for the user.

Deciding to change stream specific properties for a single flow or a plurality of flows within a session stream may provide more flexibility when controlling traffic flow. A decision may be to stop for a predetermined time a certain flow of an application, since the application may be of low priority. A decision in relation to a flow may be provided based on a received trigger signal.

According to an exemplary embodiment of the present invention, the method may further comprise extracting media flow properties.

The performing network device may implement protocol specific recognition mechanism to extract media flow properties. For example, a network device may extract session description information, such as SDP from control messages monitored by that network device. A proxy support for Realtime Streaming Protocol (RTSP) may be utilized in order to recognize the relevant session control messages.

According to an exemplary embodiment of the present invention, the method may further comprise identifying description for streaming within an HTTP object.

Thus, the method may provide a control of a HTTP streaming, which may be a non- session based multimedia streaming. The performing network device may identify description for streaming within an HTTP object based on the URL of the HTTP object.

According to an exemplary embodiment of the present invention, the method may further comprise monitoring a throughput of the streaming session.

A reduced throughput may be an indication for a congestion in a radio cell where the user of the monitored streaming session is located.

According to an exemplary embodiment of the present invention, the method may further comprise receiving or sending application specific information or service specific information from or to a network device based on location information and protocol specific information.

Thus, the method may comprise exchanging application specific information or service specific information between network devices based on location information and protocol specific information. A location information may be an IP address or an URL address.

According to an exemplary embodiment of the present invention, the method may further comprise forwarding application specific information or service specific information to a streaming server.

By forwarding the application specific information to the streaming server, the server may perform a rate adaptation.

According to an exemplary embodiment of the present invention, the method may further comprise receiving information about user subscription from a subscriber profile database. The information in relation to the user subscription may for example be derived from the subscriber database, such as a HSS, by the STME. The subscriber profile may comprise specific information of the connected user, such as allowed services and charging information.

According to an exemplary embodiment of the present invention, a network device may be provided which may be installed in a core network. The network device may comprise a receiving entity for receiving information in relation to a streaming session of a user, an analyzing entity for analyzing the information of the streaming session in view of a quality of service policy and a sending unit for sending a trigger signal for initiating a controlling of the traffic flow in the core network according to the analysis of the information of the streaming session.

A suggested network device may be a STME or a MASE or a combination thereof. The functionality of a STME and a MASE may be combined within one single network device.

According to an exemplary embodiment of the present invention, the network device may comprise an Rx-interface.

An Rx-interface may be an interface for signaling. For example a policy and charging rules function (PCRF) may have also such an Rx-interface. Therefore the network device may be connected with a PCRF in order to exchange information.

According to a further aspect of the present invention, there may be provided a network system comprising a first network device and a second network device, wherein the first network device is a STME and the second network device is a MASE.

According to an exemplary embodiment of the present invention, there may be provided a computer program product comprising code portions for causing a network device, on which the computer program may be executed to carry out the method according to the present invention.

Moreover, there may be provided a computer-readable medium embodying the computer program product according to the present invention.

Brief description of drawings

Embodiments of the present invention are described below with reference to the accompanying drawings, which are not necessarily drawn in scale, wherein:

Fig. 1 illustrates an exemplary known network architecture;

Fig. 2 illustrates an exemplary network architecture according to exemplary ideas based on the invention;

Fig. 3 illustrates a first exemplary message flow diagram; and

Fig. 4 illustrates a second exemplary message flow diagram. Detailed description of exemplary embodiments

The illustration of the drawings is schematic. In different drawings, similar or identical elements are provided with the same reference numerals.

Fig. 1 illustrates an exemplary known network architecture of a 3GPP network 10. Within this environment a user, a subscriber or user equipment (UE) 11 is connected to the internet 33. The connection of the UE 11 with the internet 33 is provided by several parts of the network 10, especially by a radio access network (RAN) 31 , a packet core network 32 and a packet data network gateway (PDN-GW/GGSN) 14. The RAN 31 is connected with an operations support system (OSS) 14. The PDN-GW/GGSN 16 is connected with a policy and charging rules function (PCRF) 15. The PCRF 15 is connected with a subscriber profile database 18.

In Fig. 1 the UE 11 is performing a multimedia streaming session using a multimedia streaming application, which may be a video call or an IP- TV session. The UE 1 1 may be a smartphone or a tablet PC wherein the multimedia streaming application of the UE 1 1 increases the traffic within the network 10. From the perspective of the UE 11 it may be necessary that a multimedia experience is satisfactory despite the amount of traffic in the network 10. It may be therefore required to allocate sufficient resources for the multimedia application of the UE 1 1.

Fig. 2 illustrates an exemplary network architecture according to an exemplary

embodiment based on the idea of the invention. Fig. 2 shows a similar network 10 within a 3GPP environment as shown in Fig. 1 with an identical UE 11. The UE 1 1 is connected with the internet 33 and is performing a streaming application. In the network 10 of Fig. 2 further network devices are installed. One network device is a streaming traffic

management entity (STME) 21 and another network device is a media aware streaming entity (MASE) 22. The STME 21 is an application aware entity and the MASE 21 is a media aware entity, both applicable for streaming services to provide an enhanced QoE for the UE 1 1 and for enabling an optimized usage of network resources. The STME 21 and the MASE 22 in Fig. 2 are installed as two separate network devices. However, it would also be possible that the STME 21 and the MASE 22 are combined within one network device having the same interfaces as configured as two separate network devices.

In Fig. 2 the STME 21 and the MASE 22 share a common interface to each other.

Moreover, the MASE 22 is connected with the PDN-GW/GGSN 14. In Fig. 2 the MASE 22 and the PDN-GW/GGSN 14 are allocated to each other and are combined within one network device 23. Moreover, the STME 21 is connected with the OSS 14, with the PCRF 15 and with the subscriber profile DB 18, respectively.

The STME 21 may enable traffic control within a 3GPP mobile packet network for multimedia streaming applications that may be IP multimedia subsystem (IMS) controlled and/ or not controlled by IP multimedia subsystem (IMS). The STME 21 and the MASE 22 may be responsible for the control and coordination of actions impacting the QoE of one of several streaming sessions of the UE 1 1.

Moreover, the STME 21 may interact with the PLMN policy control function, for example the PCRF 15 in Fig. 2 in order to provide initial and update media flow information for the control of the network resources in behalf of the multimedia application. The media flow information may be used to initiate or modify bearer resource allocation. Furthermore, the media flow information may be exchanged between the STME 21 and the PCRF 15, wherein an Rx-interface may be utilized.

Alternatively, the PCRF 15 and the STME 21 may be co-located within one network device. The STME 21 comprises an interface to the OSS 14. Thus, the OSS 14 may inform the STME 21 about received measurement reports and the OSS 14 may send trigger signals concerning congestion detection in the radio access and/or changed cell load conditions. Moreover, the STME 21 may decide to change stream specific properties for a single or multiple flows at a time based on the received trigger from the OSS 14 by sending a request to the responsible MASE 22 or a plurality of installed MASEs 22.

Changing stream specific properties and bearer resource allocation, for example via the PCRF 15, for a stream may be jointly and consistently triggered by the STME 21.

The MASE 22 may be located in a data path of the multimedia application between the UE 11 , the media server 17 or streaming server 17. The MASE 22 may provide control of the media flow and may provide and a proxy functionality for the application layer protocols. Moreover, the MASE 22 may implement protocol specific recognition mechanism in order to extract media flow properties. Extracted information by the MASE 22 may be forwarded to the STME 21 in order to initiate or update resource allocation for the bearer via the PCRF 15. For example, the MASE 22 may extract session description information, such as SDP (session description protocol) from control messages of multimedia applications. Thus, the MASE 22 may include proxy support for RTSP protocol to recognize relevant session control messages. A further example of non-session based multimedia is HTTP streaming. The MASE 22 may identify description for streaming within a HTTP object, for example a manifest file, based on the URL and may interpret the syntax of the transferred information.

Moreover, the MASE 22 may analyze performance based on higher layer protocol information. One example is the reception of RTCP report from the UE 1 1. Another example is the analysis of TCP parameters such as window size for HTTP streaming applications. The MASE 22 may inform the STME 21 if the QoS of the streaming session may be impacted, for example by monitoring and analyzing a reduced throughput. The STME 21 may decide and may trigger the appropriate action in the MASE 22. Dependent on the request from the STME 21 , the MASE 22 may forward the information to the streaming server 17. For example the server 17 performs a rate adaptation or the MASE 22 may provide an adaptation itself, for example using transcoding, selecting suitable layer in case of Scalable Video Coding (SVC) encoded videos.

In case of changed conditions reported by the OSS 14, the STME 21 may need to prioritize between media flow in the considered radio cell of the network 10. Therefore, the STME 21 may request from the OSS 14 the identities of a plurality or all subscribers, UE 11 , etc., located in a reported radio cell. Congestion may require reducing a bit rate for one or more media flows. Additional resources may allow increasing the bit rate for one or more media flows. Prioritization may be based on user profile information and

application/service specific information for the information received by the OSS 14.

Information about user subscription and type of connected user device can be derived from a subscriber profile database by the STME 21. Application specific information and service specific information can be delivered to the STME 21 by the MASE 22 based on location information, for example IP address, URL, etc., and/or protocol specific information.

Fig. 3 illustrates a first exemplary embodiment of a message flow diagram within a 3GPP environment. The 3GPP environment is similar to the network 10 of Fig. 2. The network 10 in Fig. 3 comprises an eNB/RNC 12, a MME/SGSN, an OSS 14, an STME 21 , a PCRF 15, a PDN-GW/GGSN 14, a streaming server 17 and a MASE 22. In Fig. 3 the PDN- GW/GGSN 14 and the MASE 22 are co-located to each other within a single network device 23.

The UE 1 1 is preparing to start a multimedia session provided by the streaming server 17. Fig. 3 shows a setup of the UE 11 comprising messages 109 to 127. Then the UE 1 1 performs a streaming sessions. The streaming session comprises RTP messages and RTCP messages 130 to 137. Later on the UE 11 performs a teardown comprising messages 140 to 152.

In Fig. 3 the UE 11 sends an RTSP describe message 109 towards the streaming server 17. The MASE 22 intercepts this message 109 and forwards the request as message 110 to the streaming server 17. The streaming server 17 sends an OK response 1 11 comprising SDP describing the various media streams. The information in message 11 1 of the streaming server 17 is extracted by the MASE 22 and then forwarded as message 112 to the UE H .

With message 1 13 the MASE 22 informs the STME 21 about the new session and the characteristics of the streams, for example via SDP. Afterwards, the UE 11 sends an RTSP setup message 1 14 comprising transport information for the media streams, for example port numbers. The MASE 22 informs the STME 21 with message 117 about the IP addresses of the streams. This information may be used for the flow identification.

Moreover, the STME 21 sends session information of the new media stream(s) to the PCRF 15 in message 1 18. The PCRF 15 updates the policy in the PCRF 15, for example in the PDN-GW 14 with message 1 19.

The PDN-GW 14 triggers the establishment of a dedicated bearer with resources assigned by the policy in message 120. Moreover, the MASE 22 sends a response to the

UE 1 1 with message 126.

During the multimedia session, the MASE 22 relays the RTP packets from the streaming server 17 to the UE 11. The UE 11 sends RTCP receiver reports in message 134 to provide status information about timely delivery of streaming. This message 134 is intercepted by the MASE 22 and the MASE 22 forwards then message 134 as message 135 to the streaming server 17 unmodified.

Afterwards, the UE 1 1 may stop the streaming session by sending an RTSP teardown message 140. The MASE 22 informs the STME 21 in message 142 and the STME 21 informs the PCRF 15 about the release of the session/streams with message 144. Further messages 145 to 152 serve in order to finalize the session of the UE 1.

Fig. 4 illustrates a second exemplary message flow diagram, wherein a congestion of a radio cell is detected. The configuration in Fig. 4 is similar to the configuration of Fig. 3 comprising similar network elements and a UE 11 connected to the streaming server 17. With messages 109 to 118, box 100 and messages 125, 126 a similar setup for the UE 11 is performed as described for Fig. 3.

The exemplary embodiment of Fig. 4 shows a congestion handling. In Fig. 4 the MASE 22 receives RTCP reports from the UE 11 with message 160. The reports indicate that the delay and packet loss are increasing. Therefore, the MASE 22 informs the STME 21 with message 161 that the QoS of the stream is getting impacted. The STME 21 performs an analysis based on received information of the OSS 14 comprising media information and user profile information. The STME 21 instructs the MASE 22 to adapt the stream in message 162. The adaptation of the stream is influencing the congestion situation by controlling media flow.

Exemplary embodiments have been described for 3GPP technology. Similar solutions may be utilized in LTE technology, which is in particular a 3GPP technology, or in similar technologies.

In general, it is to be noted that respective functional elements according to above- described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps or messages may be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Furthermore, method steps and functions likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language such as e.g. Java, C++, C, and Assembler Method steps and/or devices or means likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example. Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to those skilled in the art.

The network devices or network elements and their functions described herein may be implemented by software, e.g. by a computer program product for a computer, or by hardware. In any case, for executing their respective functions, correspondingly used devices, such as an interworking node or network control element, like an MGCF of an IMS network comprise several means and components (not shown) which are required for control, processing and communication/signaling functionality. Such means may comprise, for example, a processor unit for executing instructions, programs and for processing data, memory means for storing instructions, programs and data, for serving as a work area of the processor and the like (e.g. ROM, RAM, EEPROM, and the like), input means for inputting data and instructions by software (e.g. floppy diskette, CD-ROM, EEPROM, and the like), user interface means for providing monitor and manipulation possibilities to a user (e.g. a screen, a keyboard and the like), interface means for establishing links and/or connections under the control of the processor unit (e.g. wired and wireless interface means, an antenna, etc.) and the like.

For the purpose of the present invention as described herein above, it should be noted that:

- an access technology via which signaling is transferred to and from a network element or node may be any technology by means of which a node can access an access network (e.g. via a base station or generally an access node). Any present or future technology, such as WLAN (Wireless Local Access Network), WiMAX (Worldwide Interoperability for Microwave Access), BlueTooth, Infrared, and the like may be used; although the above technologies are mostly wireless access technologies, e.g. in different radio spectra, access technology in the sense of the present invention implies also wirebound

technologies, e.g. IP based access technologies like cable networks or fixed lines but also circuit switched access technologies; access technologies may be distinguishable in at least two categories or access domains such as packet switched and circuit switched, but the existence of more than two access domains does not impede the invention being applied thereto,

- usable access networks may be any device, apparatus, unit or means by which a station, entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc.;

- a user equipment may be any device, apparatus, unit or means by which a system user or subscriber may experience services from an access network, such as a mobile phone, personal digital assistant PDA, or computer;

- method steps likely to be implemented as software code portions and being run using a processor at a network element or terminal (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefore), are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the invention in terms of the functionality implemented;

- method steps and/or devices, apparatuses, units or means likely to be implemented as hardware components at a terminal or network element, or any module(s) thereof, are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components; in addition, any method steps and/or devices, units or means likely to be implemented as software components may for example be based on any security architecture capable e.g. of authentication, authorization, keying and/or traffic protection; - devices, apparatuses, units or means can be implemented as individual devices, apparatuses, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, apparatus, unit or means is preserved,

- an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for

execution/being run on a processor;

- a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally

independently of each other but in a same device housing, for example.

Although described above mainly with respect to methods, procedures, an apparatus and modules thereof, it is to be understood that the present invention also covers a computer program products for implementing such methods or procedures and/or for operating such apparatuses or modules, as well as computer-readable (storage) media for storing such computer program products. The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses and modules described above, as long as the above- described concepts of methodology and structural arrangement are applicable.

Furthermore, the network devices or network elements and their functions described herein may be implemented by software, e.g. by a computer program product for a computer, or by hardware. In any case, for executing their respective functions, correspondingly used devices, such as an interworking node or network control element, like an MGCF of an IMS network comprise several means and components (not shown) which are required for control, processing and communication/signaling functionality. Such means may comprise, for example, a processor unit for executing instructions, programs and for processing data, memory means for storing instructions, programs and data, for serving as a work area of the processor and the like (e.g. ROM, RAM, EEPROM, and the like), input means for inputting data and instructions by software (e.g. floppy diskette, CD- ROM, EEPROM, and the like), user interface means for providing monitor and

manipulation possibilities to a user (e.g. a screen, a keyboard and the like), interface means for establishing links and/or connections under the control of the processor unit (e.g. wired and wireless interface means, an antenna, etc.) and the like.

Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Moreover, although the foregoing descriptions and the associated drawings describe example embodiments in the context of certain example combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and/or functions other than those explicitly described above are also contemplated as may be set forth in some of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

In this context, "first", "second", "third", etc. in relation to messages or devices or network devices may not be understood as hierarchy, it should be understood only to distinguish different messages or devices from each other.

List of abbreviations

DB Data base

DPI Deep Packet Inspection

GBR Guaranteed Bitrate

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

HSS Home Subscriber Server

HTTP Hypertext Transport Protocol

IMS IP Multimedia Subsystem

LTE Long Term Evolution

MASE Media Aware Streaming Entity

OSS Operations Support System

OTT Over the top (application)

PCC Policy and Charging Control

PDP Packet Data Protocol

PDN-GW Packet Data Network Gateway

PCRF Policy and Charging Rules Function

PLMN Public Land Mobile Network

QCI QoS Class Identifier

QoE Quality of User Experience

QoS Quality of Service

RAN Radio Access Network

RTCP Realtime Control Protocol

RTSP Realtime Streaming Protocol

RTP Realtime Transport Protocol

SDP Session Description Protocol

SIP Session Initiation Protocol

STME Streaming Traffic Management Entity SVC Scalable Video Coding

TCP Transmission Control Protocol

TDF Traffic Detection Function

UE User Equipment

URL Uniform Resource Locator

WLAN Wireless Local Area Network

Claims

1. Method for traffic flow treatment in a core network of a communication network (10) comprising:

- receiving information in relation to a streaming session of a user (1 1);

- analyzing the information of the streaming session in view of a Quality of Service policy; and

- controlling the traffic flow in the core network according to the analysis of the information of the streaming session.

2. Method according to claim 1 , wherein the method is performed for a non-IP multimedia subsystem controlled application within the streaming session.

3. Method according to claim 1 or claim 2, the method further comprises

- intercepting information in relation to the streaming session in a path between the user (1 1) and a streaming server (17).

4. Method according to one of the claims 1 to 3, the method further comprises

- receiving trigger information in relation to a streaming session.

5. Method according to one of the claims 1 to 4, the method further comprises

- requesting identities of users (1 1) located in a congested radio cell.

6. Method according to one of the claims 1 to 5, the method further comprises

- deciding to change stream specific properties of a single flow or of multiple flows.

7. Method according to one of the claims 1 to 6, the method further comprises

- changing stream specific properties for a session stream.

8. Method according to one of the claims 1 to 7, the method further comprises

- extracting media flow properties.

9. Method according to one of the claims 1 to 8, the method further comprises

- identifying description for streaming within an HTTP object.

10. Method according to one of the claims 1 to 9, the method further comprises

- monitoring a throughput of the streaming session.

11. Method according to one of the claims 1 to 10, the method further comprises

- receiving or sending application specific information or service specific information from or to a network device based on location information and/or protocol specific information.

12. Method according to one of the claims 1 to 11 , the method further comprises

- forwarding application specific information or the service specific information to a streaming server (17).

13. Method according to any of the claims 1 to 12, wherein the method further comprises

- receiving information about user subscription from a subscriber profile database.

14. Network device (21 , 22) installed in a core network

comprising

- a receiving entity for receiving information in relation to a streaming session of a user (1 1);

- an analyzing entity for analyzing the information of the streaming session in view of a Quality of Service policy;

- a sending unit for sending a trigger signal for initiate a controlling of the traffic flow in the core network according to the analysis of the information of the streaming session.

15. Network device (21 , 22) according to claim 14,

- wherein the network device comprises an Rx-interface.

16. Network device (21 , 22) according to claim 14 or 15, wherein the network device is a STME (21) or a MASE (22).

17. Network system comprising a first network device (21) and a second network device (22), wherein the first network is a STME (21) and the second network is a MASE (22).

18. Computer program product comprising code portions for causing a network device, on which the computer program is executed, to carry out the method according to any of the claims 1 to 13.

19. Computer-readable medium embodying the computer program product according to claim 18.