EP2845369A1 - Method for controlling media transmission - Google Patents

Method for controlling media transmission

Info

Publication number
EP2845369A1
EP2845369A1 EP12718650.0A EP12718650A EP2845369A1 EP 2845369 A1 EP2845369 A1 EP 2845369A1 EP 12718650 A EP12718650 A EP 12718650A EP 2845369 A1 EP2845369 A1 EP 2845369A1
Authority
EP
European Patent Office
Prior art keywords
response message
destination identifier
request message
network
media type
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP12718650.0A
Other languages
German (de)
French (fr)
Inventor
Daniel Rodriguez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of EP2845369A1 publication Critical patent/EP2845369A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6581—Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Definitions

  • the present invention relates to a method for controlling media transmission and an intermediate network device implementing the method.
  • HTTP proxying technology an interception and processing engine is implemented that monitors the communication between client and server, learning about the existing encodings and monitoring, and if so decided, editing the requests made by clients to servers.
  • the control protocol communicates the different encodings also known as bitrate or quality levels available at the beginning and/or during the transmission. According to a network rule or a traffic contract the accessing of bandwidth to individual users is controlled in a highly efficient manner.
  • RNC Radio Network Controller
  • Node-B Base transceiver station
  • SGSN Serving GPRS support node
  • MME Mobile Management Entity
  • GGSN Gateway GPRS support node
  • RADIUS Remote Authentication Dial-ln User Service
  • HLR Home Location Register
  • HSS Home Subscriber Server
  • LDAP Lightweight Directory Access Protocol
  • PCRF Policy and Charging Rules Function
  • PCEF Policy Control Enforcement Function
  • BAS Broadband Access Server
  • BRAS Broadband Access Radio Server
  • CMTS Cable Modem Termination System
  • HTTP Hypertext Transfer Protocol
  • XML Extended Markup Language
  • QoE Quality of Experience
  • MIP Manifest Interception Protocol
  • MSDN Microsoft® Developer Network.
  • the invention relates to a method for controlling media transmission in a communications network according to a traffic rule, comprising:
  • Intercepting only the response at the beginning of the process and only the requests thereafter
  • forwarding unmodified response, but modified requests
  • the response message of the pre-defined media type is a HTTP response message.
  • Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to identify that a SmoothStreaming exchange is about to happen (response interception and unmodified forwarding).
  • the pre-defined media type corresponds to a Manifest type, in particular to a Smooth Streaming Manifest type.
  • the response message of the pre-defined media type comprises an XML file.
  • the destination identifier comprises a Uniform Resource Locator.
  • the response message comprises available encoding levels, in particular available audio and/or video encoding levels.
  • the request message pointing to the determined destination identifier is a HTTP request message. Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to force the server to comply with the desired network bandwidth policies or quality of service requirements (request interception and modified forwarding).
  • a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type.
  • the request message pointing to the determined destination identifier comprises a requested encoding level and the modified request message pointing to the determined destination identifier comprises a modified encoding level, modified according to the traffic rule.
  • the requested encoding level comprises a requested bitrate and the modified encoding level comprises a modified bitrate.
  • the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule.
  • the modified bitrate is matched to a maximum possible bitrate according to the traffic rule.
  • the traffic rule is configured for managing quality of experience and/or bandwidth limitation in the communications network.
  • Methods according to the first aspect as such or according to implementation forms of the first aspect provide the following advantages: • Limitation of maximum encoding receivable by clients depending on the tariff subscribed with operator,
  • the invention relates to an intermediate network device for controlling media transmission in a communications network according to a traffic rule, the intermediate network device processing messages according to the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect.
  • the intermediate network device is configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-gateway or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, a PCRF network, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server or a Broadband Radio Access Server, a Cable Modem Termination System or a CMTS, a generic router placed in the network with packet/session proxying capabilities, and a generic server placed in the network with packet/session proxying capabilities.
  • a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission
  • An intermediate network device provides a dynamic adaptive live streaming management device and implements an interception and processing engine by means of HTTP proxying technology.
  • the intermediate network device monitors the communication between client and server, learns about the existing encodings and monitoring, and if so decided, edits the requests made by clients to servers, thereby providing a highly efficient bandwidth control and improved quality of experience to the user.
  • the methods described herein may be implemented as software in a Digital Signal
  • DSP DSP
  • ASIC application specific integrated circuit
  • Fig. 1 shows a simple schematic diagram of a method for controlling media transmission in a communications network according to a traffic rule according to an implementation form
  • Fig. 2 shows a listing of a request message of a "Manifest Request” media type according to an implementation form
  • Fig. 3 shows a listing of a response message of a "Manifest Response” media type according to an implementation form
  • Fig. 4 shows two listings of a request message of a "Fragment Request" media type, a first with unmodified message parameters and a second one with modified message parameters according to an implementation form;
  • Fig. 5 shows two listings of a response message of a "Fragment Response” media type, a first one upon an unmodified request message of the "Fragment Request” media type and a second one upon a modified request message of the "Fragment Request” media type according to an implementation form;
  • Fig. 6 shows a message sequence diagram of an intermediate network device intercepting a communication between a user and a server in a "Manifest Registering" phase according to an implementation form
  • Fig. 7 shows a message sequence diagram of an intermediate network device modifying a communication between a user and a server in a "Fragment Request Modifying” phase according to an implementation form
  • Fig. 8 shows a simple diagram illustrating QoE improvement in a network implementing a method according to an implementation form
  • Fig. 9 shows a simple diagram illustrating bandwidth limitation in a network implementing a method according to an implementation form.
  • Fig. 1 shows a schematic diagram of a method 100 for controlling media transmission in a communications network according to a traffic rule according to an implementation form.
  • the method 100 comprises monitoring 101 messages from servers for detecting a response message of a pre-defined media type, the response message being directed to a client; upon detection 102 of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the pre-defined media type; forwarding 103 the response message of the pre-defined media type to the client; monitoring 104 messages from clients for detecting a request message pointing to the determined destination identifier; upon detection 105 of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and forwarding 106 the modified request message pointing to the determined destination identifier.
  • the response message of the pre-defined media type is a HTTP response message.
  • the Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems as defined in RFC 2616.
  • HTTP response message is according to the RFC 2616 protocol.
  • the pre-defined media type corresponds to a "Manifest” type, in particular to a “Smooth Streaming Manifest” type.
  • the "Manifest” type is according to the [MS-SSTR] Smooth Streaming Protocol Specification, which and can be found in the Microsoft® Developer Network (MSDN).
  • the response message of the pre-defined media type comprises an XML file.
  • the XML file is according to the Extensible Markup Language as defined in the XML 1.0 Specification or in later versions thereof.
  • the destination identifier comprises a Uniform Resource Locator (URL).
  • the Uniform Resource Locator URL is a compact string representation for a resource available via the internet as defined in the RFC 1738 protocol or later versions thereof.
  • the response message comprises available encoding levels, in particular available audio and/or video encoding levels.
  • the request message pointing to the determined destination identifier is a HTTP request message.
  • a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type.
  • the request message pointing to the determined destination identifier comprises a requested encoding level and the modified request message pointing to the determined destination identifier comprises a modified encoding level, modified according to the traffic rule.
  • the requested encoding level comprises a requested bitrate and the modified encoding level comprises a modified bitrate.
  • the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule.
  • the modified bitrate is matched to a maximum possible bitrate according to the traffic rule.
  • the traffic rule is configured for managing quality of experience (QoE) and/or bandwidth limitation in the communications network.
  • the method illustrated in Fig. 1 addresses specifically the Microsoft Smooth Streaming Protocol and does the following: • It monitors HTTP Responses from servers looking for XML files and media type that corresponds to the Microsoft Smooth Streaming Manifest type
  • the processed URL will then be forwarded to the destination server as if it had been sent by the client The consequence is that the server will send back to the client the media encoding that matches the business/network rules set by the operator and not the media encoding requested by the client.
  • the method illustrated in Fig. 1 can be partitioned into two implementation steps, a manifest identification implementation step and a bandwidth control implementation step.
  • the manifest identification implementation step is performed by the monitoring for detecting 101 , the intercepting and determining 102 and the forwarding 103 steps of the method 100 illustrated in Fig. 1.
  • the bandwidth control implementation step is performed by the monitoring for detecting 104, the intercepting and modifying 105 and the forwarding 106 steps of the method 100 illustrated in Fig. 1.
  • the monitoring for detecting 101 of the manifest identification implementation step can be described in an implementation form as follows: ⁇ 1. HTTP Get Requests are monitored by a Proxy
  • the request will usually contain "Manifest” and/or the name of the media with an ".ism” extension.
  • the intercepting and determining 102 of the manifest identification implementation step can be described in an implementation form as follows:
  • the forwarding 103 of the manifest identification implementation step can be described in an implementation form as follows:
  • the monitoring for detecting 104 of the bandwidth control implementation step can be described in an implementation form as follows:
  • the intercepting and modifying 105 of the bandwidth control implementation step can be described in an implementation form as follows:
  • the client will make an initial query for the maximum quality which will help the client to identify the network conditions for subsequent requests ⁇
  • the pattern may be modified (from the 1 request and any subsequent request) to conform to the following policies:
  • Each "Get Query" may be subject to modification following the previous criteria
  • Fig. 2 shows a listing of a request message 200 of a "Manifest Request” media type according to an implementation form.
  • the request message 200 of the "Manifest Request” media type is detected by a get request identification 201 which is ".ism/Manifest".
  • the get request identification 201 is detected, the communication between user and server is "ready", i.e. available for interception.
  • Fig. 3 shows a listing of a response message 300 of a "Manifest Response” media type according to an implementation form.
  • the response message 300 may comprise a HTTP header 301 which is only expected in MS (Microsoft) implementations. In an implementation form, there is no HTTP header 301.
  • the response message 300 comprises an XML content type 303, e.g. of type "text/xml" and an XML root node identification 305, e.g. as
  • Fig. 4 shows two listings of a request message of a "Fragment Request" media type, a first request message 400 with unmodified message parameters and a second request message 402 with modified message parameters according to an implementation form.
  • the first request message 400 comprises a get query pattern 405 as identified in the manifest with bitrate 1520 kbps.
  • the second request message 402 comprises a get query pattern 407 with the requested bitrate reduced to 640 kbps. This get query pattern 407 is only seen by the receiving server and not by the issuing client.
  • Fig. 5 shows two listings of a response message of a "Fragment Response” media type, a first response message 500 upon an unmodified request message of the "Fragment Request” media type and a second response message 502 upon a modified request message of the "Fragment Request” media type according to an implementation form.
  • the server issues different bandwidths (honoring the requests) but does not notify which one is sending.
  • the bandwidth is in the data delivered after the headers (not shown due to its binary nature).
  • the client will play the video content using the information embedded in the binary data and is not using the textual information exchanged with the server.
  • Fig. 6 shows a message sequence diagram of an intermediate network device 603, also called “Platform” intercepting a communication between a user 601 and a server 605 in a "Manifest Registering” phase according to an implementation form.
  • the "Manifest" intercepts a communication between a user 601 and a server 605 in a "Manifest Registering" phase according to an implementation form.
  • the "Manifest Registering" phase corresponds to the manifest identification implementation step as described with respect to Fig. 1.
  • the "Manifest Registering” phase comprises the monitoring for detecting 101 , the intercepting and determining 102 and the forwarding 103 steps of the method 100 illustrated in Fig. 1.
  • a "GET Manifest" message 610 is sent by the user 601 to the server 605 and intercepted by the platform 603 which forwards this message 610 unmodified as "GET Manifest” message 612 to the server 605.
  • the server 605 answers with a "Manifest” message 614 which is intercepted by the platform 603 where the "Manifest” message is registered 616 and forwarded unmodified as "Manifest” message 618 to the user 601.
  • the platform 603 registers the "Manifest” message and knows that the user 601 is waiting for further messages from the server 605.
  • the Manifest is registered during the response phase from the server and quality encodings, fragment information and URL request information are recorded.
  • Fig. 7 shows a message sequence diagram of an intermediate network device 703, also called “Platform” modifying a communication between a user 701 and a server 705 in a
  • the “Fragment Request Modifying” phase corresponds to the bandwidth control implementation step as described with respect to Fig. 1.
  • the “Fragment Request Modifying” phase comprises the monitoring for detecting 104, the intercepting and modifying 105 and the forwarding 106 steps of the method 100 illustrated in Fig. 1.
  • a "Fragment QMax" message 710 is sent by the user 701 to the server 705 and intercepted by the platform 703.
  • QMax indicates a desired bandwidth which the user 701 requests.
  • the platform 703 modifies the desired bandwidth QMax into an available bandwidth QMed which may be smaller than the desired bandwidth QMax the client is requesting.
  • the platform 703 forwards the received fragment message 710 with a modified bandwidth parameter QMed instead of QMax as "Fragment QMed" message 714 to the server 705.
  • the server 705 answers with a "Fragment QMed” message 716 which is intercepted by the platform 703 where the "Fragment QMed” message is forwarded unmodified as "Fragment QMed” message 718 to the user 701.
  • the platform 703 modifies the requested bandwidth according to a network rule or a bandwidth policy which may consider the whole network, i.e. the demands of all users of the network for a high quality of experience or according to their traffic contract.
  • the Fragment request is modified to match the decision made using network information and user information.
  • the platform 703 depicted in Fig. 7 and/or the platform 603 as depicted in Fig. 6 is configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-GW or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, and a PCRF network node, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server (or BRAS), a Cable Modem Termination System (or CMTS), a generic router placed in the network with packet/session proxying capabilities and a generic server placed in the network with packet/session proxying capabilities.
  • a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission
  • the platform 703 is an element belonging to a mobile network. In an implementation form, the platform 703 is an element belonging to a fixed network like ADSL or Cable.
  • Fig. 8 shows a diagram illustrating QoE improvement in a network implementing a method according to an implementation form.
  • the first graph 801 depicts the normal protocol not implementing the method according to implementation forms of the invention.
  • the normal client is slow to react to changing TCP/IP conditions, stalling happens.
  • the second graph 802 depicts a MIP (Manifest identification protocol) protocol implementing the method according to implementation forms of the invention.
  • the Manifest identification protocol 802 according to implementation forms of the invention reacts faster and thus selects the appropriate quality level faster.
  • the maximum quality level Q Ma x is illustrated by the third graph 803.
  • this faster reaction ensures that the client always receives the best possible encoding.
  • RAN information radio network aware information
  • Reaction with Radio/Network Aware Information to changing network conditions and adaptation of the protocol improves the overall performance of the protocol. The protocol adaptability is improved, less stalling happens, the playback is smoother and the QoE is improved.
  • Fig. 9 shows a diagram illustrating bandwidth limitation in a network implementing a method according to an implementation form.
  • the first graph 901 depicts the normal protocol not implementing the method according to implementation forms of the invention.
  • the normal client always requests the maximum quality level QMax 903 if possible.
  • the requested quality depends on TCP/IP conditions.
  • the second graph 902 illustrates the Manifest identification protocol implementing the method according to implementation forms of the invention.
  • the Manifest identification protocol 902 according to implementation forms of the invention limits the quality the client may receive to a limited quality Q Limi t 904.
  • the quality the client may receive is a network bandwidth which is available for him according to a network rule or a traffic contract.
  • the Manifest identification protocol 902 is Network/User information based and provides faster playback startup times, smoother playback due to reduced stalling probability, an overall QoE increase, fair use policies and therefore allows more users being served with existing bandwidth.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

A method (100) for controlling media transmission in a communications network according to a traffic rule, comprises: monitoring (101) messages from a server for detecting a response message of a pre-defined media type, the response message being directed to a client; upon detection (102) of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the predefined media type; forwarding (103) the response message of the pre-defined media type to the client; monitoring (104) messages from a client for detecting a request message pointing to the determined destination identifier; upon detection (105) of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and forwarding (106) the modified request message pointing to the determined destination identifier.

Description

DESCRIPTION
Method for controlling media transmission TECHNICAL FIELD
The present invention relates to a method for controlling media transmission and an intermediate network device implementing the method. BACKGROUND OF THE INVENTION
Major players in communication networks have made proposals for protocols to replace HTTP Progressive Download. In HTTP Progressive Download a single request is made for the retrieval of a media file/stream. These protocols have been developed in the last 2 years and find themselves still in RFC if sent to the IETF or in a similar phase, although they are already commercially used by some media streaming companies. The new protocols proposed are generically named "Adaptive Bit Rate" or "Adaptive Streaming" because a control protocol to do the encoding selection has been implemented. This protocol allows to dynamically change the quality and therefore always retrieve the highest possible quality allowed by the network conditions. This can have the side effect of increasing the load of networks and decrease the available bandwidth for other users.
SUMMARY OF THE INVENTION It is the object of the invention to provide a bandwidth-efficient control protocol for media transmission in a communications network.
This object is achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.
By means of HTTP proxying technology, an interception and processing engine is implemented that monitors the communication between client and server, learning about the existing encodings and monitoring, and if so decided, editing the requests made by clients to servers. Thus, the control protocol communicates the different encodings also known as bitrate or quality levels available at the beginning and/or during the transmission. According to a network rule or a traffic contract the accessing of bandwidth to individual users is controlled in a highly efficient manner.
In order to describe the invention in detail, the following terms, abbreviations and notations will be used:
HTTP: Hypertext,
RNC: Radio Network Controller,
Node-B: Base transceiver station,
SGSN: Serving GPRS support node, MME: Mobile Management Entity,
GGSN: Gateway GPRS support node,
Serial-Parallel Gateway,
RADIUS: Remote Authentication Dial-ln User Service,
HLR: Home Location Register, HSS: Home Subscriber Server,
LDAP: Lightweight Directory Access Protocol,
PCRF: Policy and Charging Rules Function,
PCEF: Policy Control Enforcement Function,
BAS: Broadband Access Server, BRAS: Broadband Access Radio Server, CMTS: Cable Modem Termination System,
HTTP: Hypertext Transfer Protocol, XML: Extended Markup Language,
URL: Uniform Resource Locator,
URI: Uniform Resource Identifier,
URN: Uniform Resource Name,
QoE: Quality of Experience, MIP: Manifest Interception Protocol,
MS-SSTR: Smooth Streaming Protocol Specification
MSDN: Microsoft® Developer Network.
According to a first aspect, the invention relates to a method for controlling media transmission in a communications network according to a traffic rule, comprising:
monitoring messages from a server for detecting a response message of a pre-defined media type, the response message being directed to a client; upon detection of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the pre-defined media type; forwarding the response message of the pre-defined media type to the client; monitoring messages from a client for detecting a request message pointing to the determined destination identifier; upon detection of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and forwarding the modified request message pointing to the determined destination identifier. In an implementation form of the method according to the first aspect, Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to
1. Identify that a SmoothStreaming exchange is about to happen (response interception and unmodified forwarding)
2. Force the server to comply with the desired network bandwidth policies or quality of service requirements (request interception and modified forwarding).
In a first possible implementation form of the method according to the first aspect, the response message of the pre-defined media type is a HTTP response message.
Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to identify that a SmoothStreaming exchange is about to happen (response interception and unmodified forwarding).
In a second possible implementation form of the method according to the first aspect as such or according to the first implementation form of the first aspect, the pre-defined media type corresponds to a Manifest type, in particular to a Smooth Streaming Manifest type.
In a third possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the response message of the pre-defined media type comprises an XML file. In a fourth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the destination identifier comprises a Uniform Resource Locator.
In a fifth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the response message comprises available encoding levels, in particular available audio and/or video encoding levels.
In a sixth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the request message pointing to the determined destination identifier is a HTTP request message. Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to force the server to comply with the desired network bandwidth policies or quality of service requirements (request interception and modified forwarding).
In a seventh possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type.
In an eighth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the request message pointing to the determined destination identifier comprises a requested encoding level and the modified request message pointing to the determined destination identifier comprises a modified encoding level, modified according to the traffic rule.
In a ninth possible implementation form of the method according to the eighth
implementation form of the first aspect, the requested encoding level comprises a requested bitrate and the modified encoding level comprises a modified bitrate.
In a tenth possible implementation form of the method according to the ninth implementation form of the first aspect, the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule.
In an eleventh possible implementation form of the method according to the ninth implementation form of the first aspect, the modified bitrate is matched to a maximum possible bitrate according to the traffic rule. In a twelfth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the traffic rule is configured for managing quality of experience and/or bandwidth limitation in the communications network.
Methods according to the first aspect as such or according to implementation forms of the first aspect provide the following advantages: • Limitation of maximum encoding receivable by clients depending on the tariff subscribed with operator,
• Limitation of maximum encoding that may be sent by providers depending on framework contract with operator, and
• Usage of network aware information to perform fast encoding switching to ensure the highest potential quality playback with no stalling.
According to a second aspect, the invention relates to an intermediate network device for controlling media transmission in a communications network according to a traffic rule, the intermediate network device processing messages according to the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect. In a first possible implementation form of the intermediate network device according to the second aspect, the intermediate network device is configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-gateway or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, a PCRF network, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server or a Broadband Radio Access Server, a Cable Modem Termination System or a CMTS, a generic router placed in the network with packet/session proxying capabilities, and a generic server placed in the network with packet/session proxying capabilities.
An intermediate network device according to the second aspect or according to the first implementation form of the second aspect provides a dynamic adaptive live streaming management device and implements an interception and processing engine by means of HTTP proxying technology. The intermediate network device monitors the communication between client and server, learns about the existing encodings and monitoring, and if so decided, edits the requests made by clients to servers, thereby providing a highly efficient bandwidth control and improved quality of experience to the user. The methods described herein may be implemented as software in a Digital Signal
Processor (DSP), in a micro-controller or in any other side-processor or as hardware circuit within an application specific integrated circuit (ASIC). The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof.
BRIEF DESCRIPTION OF THE DRAWINGS
Further embodiments of the invention will be described with respect to the following figures, in which:
Fig. 1 shows a simple schematic diagram of a method for controlling media transmission in a communications network according to a traffic rule according to an implementation form;
Fig. 2 shows a listing of a request message of a "Manifest Request" media type according to an implementation form; Fig. 3 shows a listing of a response message of a "Manifest Response" media type according to an implementation form;
Fig. 4 shows two listings of a request message of a "Fragment Request" media type, a first with unmodified message parameters and a second one with modified message parameters according to an implementation form;
Fig. 5 shows two listings of a response message of a "Fragment Response" media type, a first one upon an unmodified request message of the "Fragment Request" media type and a second one upon a modified request message of the "Fragment Request" media type according to an implementation form;
Fig. 6 shows a message sequence diagram of an intermediate network device intercepting a communication between a user and a server in a "Manifest Registering" phase according to an implementation form; Fig. 7 shows a message sequence diagram of an intermediate network device modifying a communication between a user and a server in a "Fragment Request Modifying" phase according to an implementation form; Fig. 8 shows a simple diagram illustrating QoE improvement in a network implementing a method according to an implementation form; and
Fig. 9 shows a simple diagram illustrating bandwidth limitation in a network implementing a method according to an implementation form.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
Fig. 1 shows a schematic diagram of a method 100 for controlling media transmission in a communications network according to a traffic rule according to an implementation form. The method 100 comprises monitoring 101 messages from servers for detecting a response message of a pre-defined media type, the response message being directed to a client; upon detection 102 of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the pre-defined media type; forwarding 103 the response message of the pre-defined media type to the client; monitoring 104 messages from clients for detecting a request message pointing to the determined destination identifier; upon detection 105 of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and forwarding 106 the modified request message pointing to the determined destination identifier.
In an implementation form, the response message of the pre-defined media type is a HTTP response message. The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems as defined in RFC 2616. In an implementation form, the HTTP response message is according to the RFC 2616 protocol.
In an implementation form, the pre-defined media type corresponds to a "Manifest" type, in particular to a "Smooth Streaming Manifest" type. In an implementation form, the "Manifest" type is according to the [MS-SSTR] Smooth Streaming Protocol Specification, which and can be found in the Microsoft® Developer Network (MSDN).
In an implementation form, the response message of the pre-defined media type comprises an XML file. In an implementation form, the XML file is according to the Extensible Markup Language as defined in the XML 1.0 Specification or in later versions thereof.
In an implementation form, the destination identifier comprises a Uniform Resource Locator (URL). In an implementation form, the Uniform Resource Locator URL is a compact string representation for a resource available via the internet as defined in the RFC 1738 protocol or later versions thereof.
In an implementation form, the response message comprises available encoding levels, in particular available audio and/or video encoding levels. In an implementation form, the request message pointing to the determined destination identifier is a HTTP request message. In an implementation form, a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type. In an implementation form, the request message pointing to the determined destination identifier comprises a requested encoding level and the modified request message pointing to the determined destination identifier comprises a modified encoding level, modified according to the traffic rule. In an implementation form, the requested encoding level comprises a requested bitrate and the modified encoding level comprises a modified bitrate. In an implementation form, the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule. In an implementation form, the modified bitrate is matched to a maximum possible bitrate according to the traffic rule. In an implementation form, the traffic rule is configured for managing quality of experience (QoE) and/or bandwidth limitation in the communications network.
In an implementation form, the method illustrated in Fig. 1 addresses specifically the Microsoft Smooth Streaming Protocol and does the following: • It monitors HTTP Responses from servers looking for XML files and media type that corresponds to the Microsoft Smooth Streaming Manifest type
• If a Manifest is detected, the HTTP Response is intercepted.
• The manifest is saved and analyzed to learn about the different media encodings available (audio and video) and the destination URL that will be used to retrieve the media
• The HTTP Response is forwarded to the client as if it had been sent by the server
• The engine then monitors HTTP Requests that point to the URL recorded above.
• Upon detection of the URL the HTTP Request will be intercepted
· Business logic/network rules available to the engine will dictate if the HTTP Request has to be modified (the bandwidth parameter part of the URL request)
• The processed URL will then be forwarded to the destination server as if it had been sent by the client The consequence is that the server will send back to the client the media encoding that matches the business/network rules set by the operator and not the media encoding requested by the client.
In an implementation form, the method illustrated in Fig. 1 can be partitioned into two implementation steps, a manifest identification implementation step and a bandwidth control implementation step. The manifest identification implementation step is performed by the monitoring for detecting 101 , the intercepting and determining 102 and the forwarding 103 steps of the method 100 illustrated in Fig. 1. The bandwidth control implementation step is performed by the monitoring for detecting 104, the intercepting and modifying 105 and the forwarding 106 steps of the method 100 illustrated in Fig. 1.
According to this partitioning, the monitoring for detecting 101 of the manifest identification implementation step can be described in an implementation form as follows: ♦ 1. HTTP Get Requests are monitored by a Proxy
♦ The request will usually contain "Manifest" and/or the name of the media with an ".ism" extension.
♦ This may not be the case and therefore also HTTP responses have to be monitored
♦ If "Manifest" and the ".ism" extensions are seen in the Get query, it may be assumed that a Smooth Stream media has been requested. ♦ In any case the monitorization of the response is the key.
The intercepting and determining 102 of the manifest identification implementation step can be described in an implementation form as follows:
♦ 2. HTTP Get Responses are monitored by a Proxy
♦ A Manifest will be of type: "text/xml"
♦ Although Microsoft servers will contain a HTTP header of the type: "Pragma:
I ISMS/4.0, 1 IS Media Services by Microsoft" this is not expected to be true by non-Microsoft implementations
♦ The root node of XML content has to be named "SmoothStreamingMedia".
This is the key to identify the Manifest file
The forwarding 103 of the manifest identification implementation step can be described in an implementation form as follows:
♦ 3. Manifest has been identified
♦ The Manifest will be saved and analyzed according to the Smooth Streaming Standard
♦ Encodings for media will be recorded
♦ The "get" query string for media fragments will be recorded for identification
According to this partitioning, the monitoring for detecting 104 of the bandwidth control implementation step can be described in an implementation form as follows:
♦ 1. HTTP Get Requests are monitored by a Proxy
♦ The request query will be matched against the "get query pattern" identified in the manifest
♦ Because the media is broken into fragments, each "get" has to be monitored
The intercepting and modifying 105 of the bandwidth control implementation step can be described in an implementation form as follows:
♦ 2. "Get Query Pattern" is identified
♦ The client will make an initial query for the maximum quality which will help the client to identify the network conditions for subsequent requests ♦ The pattern may be modified (from the 1 request and any subsequent request) to conform to the following policies:
♦ Maximum bandwidth on a per user basis (individual tariff) that may include location, time, handset information, already used data quota and other factors
♦ Maximum bandwidth on a network-condition-basis. Network condition will be identified by other elements and this information will be available The forwarding 106 of the bandwidth control implementation step can be described in an implementation form as follows:
♦ 3. Each "Get Query" may be subject to modification following the previous criteria
Fig. 2 shows a listing of a request message 200 of a "Manifest Request" media type according to an implementation form. The request message 200 of the "Manifest Request" media type is detected by a get request identification 201 which is ".ism/Manifest". When the get request identification 201 is detected, the communication between user and server is "ready", i.e. available for interception.
Fig. 3 shows a listing of a response message 300 of a "Manifest Response" media type according to an implementation form. The response message 300 may comprise a HTTP header 301 which is only expected in MS (Microsoft) implementations. In an implementation form, there is no HTTP header 301. The response message 300 comprises an XML content type 303, e.g. of type "text/xml" and an XML root node identification 305, e.g. as
"SmoothStreamingMedia" identifier. The response message 300 further comprises a get query pattern 307 and encoding levels available for media 309, e.g. the two encoding levels "QualityLevelBitrate=2750000" and "QualityLevelBitrate=2040000".
Fig. 4 shows two listings of a request message of a "Fragment Request" media type, a first request message 400 with unmodified message parameters and a second request message 402 with modified message parameters according to an implementation form. The first request message 400 comprises a get query pattern 405 as identified in the manifest with bitrate 1520 kbps. The second request message 402 comprises a get query pattern 407 with the requested bitrate reduced to 640 kbps. This get query pattern 407 is only seen by the receiving server and not by the issuing client.
Fig. 5 shows two listings of a response message of a "Fragment Response" media type, a first response message 500 upon an unmodified request message of the "Fragment Request" media type and a second response message 502 upon a modified request message of the "Fragment Request" media type according to an implementation form. There is no difference in the answers. The server issues different bandwidths (honoring the requests) but does not notify which one is sending. The bandwidth is in the data delivered after the headers (not shown due to its binary nature). The client will play the video content using the information embedded in the binary data and is not using the textual information exchanged with the server.
Fig. 6 shows a message sequence diagram of an intermediate network device 603, also called "Platform" intercepting a communication between a user 601 and a server 605 in a "Manifest Registering" phase according to an implementation form. The "Manifest
Registering" phase corresponds to the manifest identification implementation step as described with respect to Fig. 1. The "Manifest Registering" phase comprises the monitoring for detecting 101 , the intercepting and determining 102 and the forwarding 103 steps of the method 100 illustrated in Fig. 1.
A "GET Manifest" message 610 is sent by the user 601 to the server 605 and intercepted by the platform 603 which forwards this message 610 unmodified as "GET Manifest" message 612 to the server 605. The server 605 answers with a "Manifest" message 614 which is intercepted by the platform 603 where the "Manifest" message is registered 616 and forwarded unmodified as "Manifest" message 618 to the user 601. During the "Manifest Registering" phase the platform 603 registers the "Manifest" message and knows that the user 601 is waiting for further messages from the server 605. In the Manifest/Playlist registration process the Manifest is registered during the response phase from the server and quality encodings, fragment information and URL request information are recorded.
Fig. 7 shows a message sequence diagram of an intermediate network device 703, also called "Platform" modifying a communication between a user 701 and a server 705 in a
"Fragment Request Modifying" phase according to an implementation form. The "Fragment Request Modifying" phase corresponds to the bandwidth control implementation step as described with respect to Fig. 1. The "Fragment Request Modifying" phase comprises the monitoring for detecting 104, the intercepting and modifying 105 and the forwarding 106 steps of the method 100 illustrated in Fig. 1.
A "Fragment QMax" message 710 is sent by the user 701 to the server 705 and intercepted by the platform 703. QMax indicates a desired bandwidth which the user 701 requests. According to a bandwidth policy or a network rule, the platform 703 modifies the desired bandwidth QMax into an available bandwidth QMed which may be smaller than the desired bandwidth QMax the client is requesting. The platform 703 forwards the received fragment message 710 with a modified bandwidth parameter QMed instead of QMax as "Fragment QMed" message 714 to the server 705. The server 705 answers with a "Fragment QMed" message 716 which is intercepted by the platform 703 where the "Fragment QMed" message is forwarded unmodified as "Fragment QMed" message 718 to the user 701.
During the "Fragment Request Modifying" phase the platform 703 modifies the requested bandwidth according to a network rule or a bandwidth policy which may consider the whole network, i.e. the demands of all users of the network for a high quality of experience or according to their traffic contract.
In the Fragment modification process the Fragment request is modified to match the decision made using network information and user information.
In an implementation form, the platform 703 depicted in Fig. 7 and/or the platform 603 as depicted in Fig. 6 is configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-GW or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, and a PCRF network node, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server (or BRAS), a Cable Modem Termination System (or CMTS), a generic router placed in the network with packet/session proxying capabilities and a generic server placed in the network with packet/session proxying capabilities. In an implementation form, the platform 703 is an element belonging to a mobile network. In an implementation form, the platform 703 is an element belonging to a fixed network like ADSL or Cable. Fig. 8 shows a diagram illustrating QoE improvement in a network implementing a method according to an implementation form. The first graph 801 depicts the normal protocol not implementing the method according to implementation forms of the invention. The normal client is slow to react to changing TCP/IP conditions, stalling happens. The second graph 802 depicts a MIP (Manifest identification protocol) protocol implementing the method according to implementation forms of the invention. The Manifest identification protocol 802 according to implementation forms of the invention reacts faster and thus selects the appropriate quality level faster. The maximum quality level QMax is illustrated by the third graph 803. In response to better network conditions, this faster reaction ensures that the client always receives the best possible encoding. In an implementation form, RAN information (radio network aware information) is exploited for improving the reaction times. Reaction with Radio/Network Aware Information to changing network conditions and adaptation of the protocol improves the overall performance of the protocol. The protocol adaptability is improved, less stalling happens, the playback is smoother and the QoE is improved.
Fig. 9 shows a diagram illustrating bandwidth limitation in a network implementing a method according to an implementation form.
The first graph 901 depicts the normal protocol not implementing the method according to implementation forms of the invention. The normal client always requests the maximum quality level QMax 903 if possible. The requested quality depends on TCP/IP conditions. The second graph 902 illustrates the Manifest identification protocol implementing the method according to implementation forms of the invention. The Manifest identification protocol 902 according to implementation forms of the invention limits the quality the client may receive to a limited quality QLimit 904. In an implementation form, the quality the client may receive is a network bandwidth which is available for him according to a network rule or a traffic contract. Thus, the Manifest identification protocol 902 according to implementation forms of the invention is Network/User information based and provides faster playback startup times, smoother playback due to reduced stalling probability, an overall QoE increase, fair use policies and therefore allows more users being served with existing bandwidth.

Claims

CLAIMS:
1. A method (100) for controlling media transmission in a communication network according to a traffic rule, comprising: - monitoring (101 ) messages from a server for detecting a response message of a predefined media type, the response message being directed to a client;
- upon detection (102) of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the pre- defined media type;
- forwarding (103) the response message of the pre-defined media type to the client;
- monitoring (104) messages from a client for detecting a request message pointing to the determined destination identifier;
- upon detection (105) of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and
- forwarding (106) the modified request message pointing to the determined destination identifier.
2. The method (100) according to claim 1 , wherein the response message of the predefined media type is a HTTP response message (300).
3. The method (100) according to claim 1 or claim 2, wherein the pre-defined media type corresponds to a Manifest type (201 ), in particular to a Smooth Streaming Manifest type.
4. The method (100) according to one of the preceding claims, wherein the response message of the pre-defined media type comprises an XML file.
5. The method (100) according to one of the preceding claims, wherein the destination identifier comprises a Uniform Resource Locator.
6. The method (100) according to one of the preceding claims, wherein the response message comprises available encoding levels (309), in particular available audio and/or video encoding levels.
7. The method (100) according to one of the preceding claims, wherein the request message pointing to the determined destination identifier is a HTTP request message.
8. The method (100) according to one of the preceding claims, wherein a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type.
9. The method (100) according to one of the preceding claims, wherein the request message pointing to the determined destination identifier comprises a requested encoding level (405) and the modified request message pointing to the determined destination identifier comprises a modified encoding level (407), modified according to the traffic rule.
10. The method (100) according to claim 9, wherein the requested encoding level (405) comprises a requested bitrate and the modified encoding level (407) comprises a modified bitrate.
1 1. The method (100) according to claim 10, wherein the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule.
12. The method (100) according to claim 10, wherein the modified bitrate is matched to a maximum possible bitrate (803) according to the traffic rule.
13. The method (100) according to one of the preceding claims, wherein the traffic rule is configured for managing quality of experience and/or bandwidth limitation in the
communications network.
14. Intermediate network device (603, 703) for controlling media transmission in a communications network according to a traffic rule, the intermediate network device (603, 703) processing messages according to the method (100) of one of the claims 1 to 13.
15. The intermediate network device (603, 703) of claim 14, being configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-gateway or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, a PCRF network, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server or a Broadband Radio Access Server, a Cable Modem Termination System or a CMTS, a generic router placed in the network with packet/session proxying capabilities, and a generic server placed in the network with packet/session proxying capabilities.
EP12718650.0A 2012-05-02 2012-05-02 Method for controlling media transmission Withdrawn EP2845369A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2012/057974 WO2013164017A1 (en) 2012-05-02 2012-05-02 Method for controlling media transmission

Publications (1)

Publication Number Publication Date
EP2845369A1 true EP2845369A1 (en) 2015-03-11

Family

ID=46026810

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12718650.0A Withdrawn EP2845369A1 (en) 2012-05-02 2012-05-02 Method for controlling media transmission

Country Status (2)

Country Link
EP (1) EP2845369A1 (en)
WO (1) WO2013164017A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2552943A (en) * 2016-08-09 2018-02-21 V-Nova Ltd Adaptive video consumption

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105556922B (en) * 2013-09-17 2019-06-28 瑞典爱立信有限公司 DASH in network indicates adaptive
WO2017054844A1 (en) * 2015-09-29 2017-04-06 Telefonaktiebolaget Lm Ericsson (Publ) Pcc control of http adaptive bit rate video streaming protocols

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011139305A1 (en) * 2010-05-04 2011-11-10 Azuki Systems, Inc. Method and apparatus for carrier controlled dynamic rate adaptation and client playout rate reduction
HUE036108T2 (en) * 2010-08-10 2018-06-28 Ericsson Telefon Ab L M A method in a media client, a media client, a control entity and a method in a control entity

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2013164017A1 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2552943A (en) * 2016-08-09 2018-02-21 V-Nova Ltd Adaptive video consumption
US10841625B2 (en) 2016-08-09 2020-11-17 V-Nova International Limited Adaptive video consumption
US11877019B2 (en) 2016-08-09 2024-01-16 V-Nova International Limited Adaptive video consumption

Also Published As

Publication number Publication date
WO2013164017A1 (en) 2013-11-07

Similar Documents

Publication Publication Date Title
US9967348B2 (en) Methods and apparatus for providing session policy during a registration of a device
JP4801204B2 (en) Applying policies to manage service flows
CA2444720C (en) Communications network
US8982893B2 (en) System and method of quality of service enablement for over the top applications in a telecommunications system
US9071505B2 (en) Method and system for dynamically allocating services for subscribers data traffic
US20120303796A1 (en) Mapping accounting avps to monitoring keys for wireline subscriber management
CA2489125A1 (en) Applying session services based on packet flows
US20150207872A1 (en) Method and system for performing mobile cdn request routing
US20180048514A1 (en) Mechanism to support operator assisted parental control
JP2008518538A (en) Method for intercepting HTTP redirect requests, and system and server device for executing said method
US10631145B1 (en) Dynamic provision of application related sponsored data connectivity
EP2264992A1 (en) Communication system and communication method
WO2013164017A1 (en) Method for controlling media transmission
CN104038951A (en) Method And Apparatus For Processing Media Traffic In Mobile Communication System
EP2732588B1 (en) Policy tokens in communication networks
US20140379933A1 (en) Handling of auxiliary nas
EP3636006A1 (en) Network assistance in dash using dns
EP4413703A1 (en) Charging functions and methods for updating charging resources
WO2014179954A1 (en) Processing method, device and system for content proxy
US9723499B2 (en) Optimizer selection in wireless networks

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20141202

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20181016

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200616