WO2014187472A1

WO2014187472A1 - Adaptive streaming in a communication network

Info

Publication number: WO2014187472A1
Application number: PCT/EP2013/060337
Authority: WO
Inventors: Àkos KOVÁCS; Paul Schliwa-Bertling; Paul Stallard
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2013-05-20
Filing date: 2013-05-20
Publication date: 2014-11-27

Abstract

A method and apparatus for handling adaptive streaming data towards a mobile station. A mobile service proxy node receives (S4) Media Descriptor (MD) data relating to an adaptive media streaming session towards the mobile station. It adapts (S7) the MD data and sends (S8) the adapted MD data towards the mobile station. This allows adaptation of the MD by a network node, and so allows the control of streaming media to take account of factors such as network conditions.

Description

Adaptive Streaming in a Communication Network

TECHNICAL FIELD

The present invention relates to the field of adaptive media streaming in a communication network.

BACKGROUND

The use of streaming media over mobile networks is growing very rapidly, and so the amount of traffic such as video data traffic in mobile networks is growing. Video services require a high data rate, and are particularly sensitive to data losses and variations in network latency. This has a large impact on the end user's quality of experience (QoE), as lost data disrupts the video presented to the user. Most video services are currently provided as "best-effort" services. It would be beneficial for network operators to manage the increasing volume of video traffic on their networks in order to reduce the likelihood of networks becoming overloaded and the QoE for the end user reducing.

Quality of Service (QoS) techniques can be used to identify traffic flows in a communication network (either individual flows or classes of flows, such as video flows or audio flows). Policies are applied to the identified flows with the aim of improving service quality for consumers. Universal Mobile Telecommunications System (UMTS) defines a QoS architecture that is illustrated in Figure 1 . This illustrates two Mobile Stations (MS) 1 , 2, a Mobile Terminal (MT) 3, a Radio Access Network (RAN) 4, a Core Network (CN) EDGE node 5, and a CN Gateway node 6. Corresponding nodes are the Radio Base Station (RBS), Radio Network Controller (RNC) for UMTS Terrestrial Radio Access Network (UTRAN), Base Station Controller (BSC) for GSM EDGE Radio Access Network (GERAN) and a General Packet Radio Service Support Node (GSN). Te Figure shows the different bearer services corresponding to different QoS. It may be assumed the nodes in the core network have high capacity transmission links for which QoS considerations are not so important.

Figure 2 shows a network architecture in which a Serving GSN (SGSN) 7 connects to either an RNC 8 or BSC 9 over luPS and Gb interfaces, respectively. These interfaces are over a connectivity network that is referred to as the core network and may comprise high capacity links. Upon QoS setup the MS 1 initiates a PDP context negotiation for the certain traffic type it is about to use. Based on available radio resources a QoS profile is associated with the PDP context.

A Gateway GSN (GGSN) 10 is connected to the SGSN 7 over a Gn interface. For a UTRAN network it is possible that user data is tunnelled from the GGSN 10 directly to the RNC 8. The GGSN 10 is also involved into the QoS negotiation process.

The RNC 8 and BSC 9 control radio resource allocation and distribution between different packet switched data users in a given cell. Both nodes 8, 9 are part of the flow control mechanism that continuously supervises QoS. Flow control in GERAN is based on the PFM procedure (Aggregate BSS QoS Profile, ABQP, negotiation). At activation of a PDP context, the MS 1 requests a certain level of Quality of Service. The requested QoS will be checked to confirm that it complies with a subscription associated with the MS 1 . The SGSN 7 may then check and modify the requested QoS due to SGSN 7 internal QoS handling. The SGSN 7 then starts the PFM procedures by creating a Packet Flow Context (PFC) towards the Base Station Subsystem (BSS) where the ABQP is negotiated. The ABQP is then valid for all the Logical Link Control (LLC) Packet Data Units (PDU) that are transmitted for the PDP context.

Flow control in UTRAN is based on congestion avoidance and detection mechanisms run both on a Radio Base Station (RBS) 1 1 and RNC 8 on a per Radio Access Bearer basis. The basic flow control mechanism considers the flow's associated QoS profile and the actual Cell Area (CA) bitrate, and, if needed, RNC can back off with the transmission rate. Further mechanisms can also be activated, such as Active Queue Management (AQM) based congestion control and weighted flow control. In the latter case, flows corresponding to different users are handled in a different way according to their subscription level. In order to provide the negotiated QoS profile for a given flow, radio resources may be reserved and admission control may be applied.

In UTRAN the RBS 1 1 is involved in the flow control mechanism. Upon detection of bottleneck either in the transport network or over the Uu interface, Cell Area (CA) messages are issued to the RNC 8 to reduce CA bitrate for a given flow. Advanced scheduling may also be applied in the RBS 1 1 . In GERAN it is only the BSC 9 that is involved in the QoS negotiation and flow control.

The media stream is typically an adaptive bitrate stream. There is a baseline stream that consumes the least bandwidth and offers the lowest media quality. If bandwidth is available, it is possible to obtain media of a higher quality. The media received by the MS 1 may change over time depending on various factors, such as network bandwidth availability, processing power on the MS 1 , battery status, window size, etc. Two common methods for adaptive bitrate streams are scalable video coding and HTTP adaptive bitrate. With scalable video coding, the media stream consists of several layers. Each layer holds additional quality enhancement information to all those which are below it. The more layers the MS 1 receives, the higher the perceived quality. The lowest quality layer is referred to as the base layer. Layers above the base layer are enhancement layers. Each additional enhancement layer requires additional bandwidth in the network.

With HTTP adaptive bitrate, the video is encoded at multiple bitrates before being segmented into "chunks" corresponding to a defined time period (2-10 seconds is typical). For any given time segment, the client at the MS 1 can choose between multiple chunks of different size (larger chunks correspond to higher bitrate, higher quality representations), depending on the available bandwidth and other factors. The client is given a list of all the available chunks and their properties in a manifest file, as described, for example, in US 7,818,444.

The transmission mechanism of adaptive streams can be based on either Transmission Control Protocol (TCP) or on User Datagram Protocol (UDP) at the transport layer. With TCP-based methods congestion control is end-to-end and is driven by the MS 1 . However, the network can affect the client behaviour by making changes to the manifest file. UDP-based methods usually incorporate Real-time Transport Protocol (RTP)/RTP Control Protocol (RTCP) and allow congestion control and end-user adaptation within the network by transcoding the media stream, or they allow network-level interaction by for example RTP Network Abstraction Layer Unit (NALU) header extension (see RFC 3984) for H.264 SVC bitstreams. Where the streaming media is sent using a TCP-based HTTP adaptive streaming (HTTP-AS) mechanism, the network has no control over the transmission rate. Throughput is controlled by the TCP protocol and fills up all the free resources in the network. Such receiver-driven solutions are resource-intensive and, without appropriate control, can starve other competing flows. Where the streaming media is sent using UDP on the transmission layer (RTP-based solutions), without a proper controlling mechanism the stream can be starved or suffer from random packet drops which both lead to poor end-user perceived quality and long buffering. The issue in both cases arises from the end-to-end control of the streaming.

Existing congestion resolution mechanism applied in UTRAN systems can be a simple drop-scheme that discards TCP packets in order to trigger the TCP back-off mechanism which finally reduces the transmission rate of a given flow. This solution is simple and suits well to streams that use TCP (elastic traffic). For inelastic traffic, that uses UDP, such a mechanism may lead to severe loss of information from a media stream resulting unacceptable Quality of Experience (QoE) for the end-user.

SUMMARY

It is an object to provide a mechanism by which nodes under the control of a network operator can control adaptive media bitstreams and improve QoS.

According to a first aspect, there is provided a method of handling adaptive streaming data towards a mobile station. A mobile service proxy node receives Media Descriptor (MD) data relating to an adaptive media streaming session towards the mobile station. It adapts the MD data and sends the adapted MD data towards the mobile station. An advantage of this is that a network node can adapt MD data, thereby allowing network control of the streaming media to take account of factors such as network conditions.

As an option, the mobile service proxy node is associated with any of a Serving GPRS Support Node (SGSN and a Gateway GPRS Support Node (GGSN).

The adaptation of the MD data is optionally performed according to factors such as a user subscription, network conditions and Quality of Service requirements.

As an option, prior to receiving the MD data, the mobile service proxy node receives a PDP context message, the PDP context message indicating that adaptive streaming is to be used. An advantage of this is that the mobile service proxy node is warned that adaptive streaming is to be used.

The PDP context message optionally comprises either information for modifying a QoS Service profile of an existing PDP context associated with the mobile station (in the case where a PDP context exists) or information for establishing a secondary PDP context associated with the mobile station in the case where the mobile station is already associated with a primary PDP context.

In order to allow the mobile service proxy node to obtain dynamic information about network conditions, prior to adapting the MD data, the mobile service proxy node optionally sends a query to a node in a Radio Access Network (RAN) serving the mobile station and receives a response, the response including information relating to conditions in the RAN.

As an option, the mobile service proxy node determines that updated MD data is required in response to any of a change in network circumstances and a request from the mobile station, and adapts the MD data accordingly.

According to a second aspect, there is provided a mobile service proxy node for use in a communications network. The mobile service proxy node is provided with a receiver for receiving MD data relating to an adaptive media streaming session towards a mobile station. A processor is provided for adapting the MD data. A transmitter is also provided for sending the adapted MD data towards the mobile station. This advantageously allows the mobile service proxy node to adapt MD data, thereby allowing network control of the streaming media to take account of factors such as network conditions.

As an option, the mobile service proxy node is associated with any of a SGSN and a GGSN.

The processor is optionally arranged to adapt the MD data according to any of a user subscription, network conditions and Quality of Service requirements. The mobile service proxy node is optionally provided with a second receiver arranged to, prior to receiving the MD data, receive a PDP context message, the PDP context message indicating that adaptive streaming is to be used. As a further option, the mobile service proxy node is provided with a second transmitter for sending a query to a node in a RAN serving the mobile station, and a third receiver for receiving from the node in the RAN a response, the response including information relating to conditions in the RAN. This advantageously allows the mobile service proxy node to determine network conditions in the RAN, which can be taken into account when adapting the MD.

As an option, the processor is further arranged to determine that updated MD data is required in response to any of a change in network circumstances and a request from the mobile station, and adapt the MD data accordingly.

The mobile service proxy node is optionally provided with a computer readable medium in the form of a memory that is arranged to store the MD associated with the mobile station. According to a third aspect, there is provided a mobile station for use in a communications network. The mobile station is provided with a transmitter for sending to a mobile service proxy node a PDP context message. The PDP context message includes any of an indication that adaptive streaming is to be used, an instruction to modify an existing PDP context, and an instruction to establish a secondary PDP context. The PDP context message is usable by the mobile service proxy node to associate MD data with the mobile station.

According to a fourth aspect, there is provided a computer program, comprising computer readable code which, when run on a computer device causes the computer device to perform the method as described above in the first aspect.

According to a fifth aspect, there is provided a computer program, comprising computer readable code which, when run on a mobile station causes the mobile station to behave as a mobile station as described above in the third aspect. According to a sixth aspect, there is provided a computer program product comprising a non-transitory computer readable medium and a computer program as described above in the fourth or fifth aspect, wherein the computer program is stored on the computer readable medium.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates schematically a UMTS architecture and the QoS bearer services between different nodes;

Figure 2 illustrates schematically in a block diagram an exemplary network architecture;

Figure 3 is a flow diagram showing exemplary steps;

Figure 4 is a signalling diagram showing signalling for an exemplary embodiment in which a user streams media using a dedicated streaming media application;

Figure 5 is a signalling diagram showing signalling for a further exemplary embodiment in which a user streams media using a dedicated streaming media application;

Figure 6 is a signalling diagram showing signalling for another exemplary embodiment; Figure 7 is a signalling diagram showing signalling for yet another exemplary embodiment;

Figure 8 illustrates an exemplary Quality of Service element;

Figure 9 illustrates schematically in a block diagram an exemplary mobile service proxy node; and

Figure 10 illustrates schematically in a block diagram an exemplary mobile station.

DETAILED DESCRIPTION A UMTS system comprises a Mobile Station (MS) 1 , a media source, a Radio Access Network (RAN) 4, a Serving GPRS Support Node (SGSN) 7 and a Gateway GPRS Support Node (GGSN) 10. A Media Descriptor (MD) is used for media adaptation. The MD represents information about the adaptive media bitstream and is used by the network elements for enforcing QoS.

The MS 1 acts as a media receiver and is attached to the UMTS system. The UMTS system delivers the media content to the MS 1 from a Content Provider (CP) that is a media source. The media content is delivered to the MS 1 by any appropriate method that enables media adaptation, such as HTTP adaptive media streaming. The RAN 4 is part of the UMTS Bearer Service. The RAN 4 comprises a Radio Base Station (RBS) 1 1 and a controller node, which can be a Radio Network Controller (RNC) 8 in case of UTRAN or a Base Station Controller (BSC) 9 in case of GERAN. The RAN provides Quality of Service (QoS) information for media adaptation purposes to network nodes closer to the media source, such as to the SGSN 7 and the GGSN 10, either of which can be used for media adaptation. In one example, both the SGSN 7 and the GGSN 10 may perform media adaptation. In another example only the SGSN 7 performs media adaptation. In a further example, in which User Plane (UP) traffic is tunnelled in a UTRAN system between the GGSN 10 and the RNC 8, only the GGSN 10 performs media adaptation.

The SGSN 7 and/or the GGSN 10 (depending on which adaptation alternative is used) store the MD for the given media content and delivery session.

The media stream is adaptive bitrate. As described above, there is a baseline stream that consumes the least bandwidth and offers the lowest video quality but if bandwidth is available, it is possible to obtain representations of a higher quality. The representation received by the MS 1 may change over time depending on various factors such as network bandwidth availability, processing power at the MS 1 , battery status, window size, and so on.

As described above, scalable video coding and HTTP adaptive bitrate can be considered for adaptive bitrate streams.

Figure 3 is a flow diagram illustrating exemplary steps, some of which are described in more detail below. The following numbering corresponds to that of Figure 3:

S1 . A mobile service proxy node, such as a SGSN 7 or a GGSN 10, receives a PDP context activation message. The PDP context activation message indicates that adaptive streaming is to be used.

S2. In an optional embodiment, the PDP context activation message includes information for modifying a QoS profile of an existing PDP context associated with the MS 1 . S3. In an alternative embodiment, the PDP context activation message includes information for establishing a secondary PDP context associated with the MS 1 , and the MS 1 is already associated with a primary PDP context. S4. The mobile service proxy node 7, 10 receives MD data relating to an adaptive media streaming session and sent towards the mobile station.

55. The mobile service proxy node 7, 10 sends a query to a node in the RAN 4. In this example, the RAN 4 node is an RNC 8. The query is to determine conditions in the RAN 4.

56. The node in the RAN 4 responds to the mobile service proxy node 7, 10 with relating to conditions in the RAN. S7. The mobile service proxy node 7, 10 adapts the MD on the basis of the received information, such as network conditions, QoE policies, user subscription and so on.

58. The mobile service proxy node 7, 10 sends the adapted MD towards the MS 1 .

59. The MS 1 uses the adapted MD to control the sending of the media data and ensure that it complies with QoS requirements while taking into account network conditions. S10. A determination is made to see whether an update to the MD is required. This may be, for example, because of a change in network conditions or in response to a query from the MS 1 . If an update is required, then the process reverts to step S5, otherwise the process reverts to step S9. In more detail, the Media Descriptor (MD) is a data file that contains basic or extended information about the adaptive media to be delivered to the MS 1 . Expected basic information may be considered as the number of layers, their identity and their priority order within the stream. Furthermore, information may contain layer specific information, which may comprise per-layer bitrate information. Extended information allows the better call admission control and resource reservation to be provided. An exemplary MD data file for HTTP-AS is as follows, showing how segments at a given quality level are represented:

Representation id="32" bandwidth="64000">~</Representation>

</AdaptationSet>

<Viewpoint schemeldUri="urn:mpeg:DASH:viewpoint:201 1 " value="vp27> Representation id="41 " bandwidth="128000">~</Representation>

</AdaptationSet>

An example of a Media Descriptor is a manifest file (Media Presentation Description, MPD) for HTTP-AS. In the case of HTTP adaptive bitrate streaming, or cross-layer derived information signalled forward by the media source to the UMTS system, but it will be appreciated that any suitable data structure may be used. Any appropriate signalling protocol can be applied to signal the MD to the MS 1 during the streaming setup. In case of scalable media delivery (i.e. other than HTTP-AS), the signalling of the MD is required. The signalling protocol distributes the MD to all mobile service proxy nodes in the network performing adaptation, such as the SGSN 7 and the GGSN 10.

In case of HTTP-AS, adaptation is controlled by modifying the MD in mobile service proxy nodes 7, 10 in the network and in the MS 1 . This allows control of the media adaptive bitrate streaming to be controlled by the network in addition to by the endpoints (the MS 1 and the media source). Modification of the MD in the mobile service proxy nodes 7, 10 means marking of the highest available data chunk available for the end-user to fetch. Modification of MD in the MS 1 means updating the descriptor in a way that the end-user application is blocked from trying to access layers at a higher bitrate than the network allows. MD updates in the MS 1 are only applicable for services such as HTTP-AS. Adaptation of the MD may be performed on two levels. If the applied media delivery method allows, the MS 1 can perform end-to-end adaptation. That is, the MS 1 is allowed to select between different quality representations of the media at any time. This is possible, for example, in the case of HTTP-AS, where the MS 1 can fetch a lower quality segment of the media if the throughput measured by the MS 1 dictates so. In the UMTS system, dedicated adaptation points, such as the SGSN 7 and/or the GGSN 10 adapt the media stream according to current network conditions. Measurement reports for the adaptation are derived from the RAN 4 and from local measurement methods running on corresponding nodes.

The MD resides at the MS 1 , so in order for a network node such as the SGSN 7 or the GGSN 10 to perform media adaption, it must obtain the MD.

Figures 4 to 7 show exemplary signalling diagrams showing how the mobile service proxy (in these examples, the SGSN 7) obtains the MD and obtains or modifies PDP contexts.

In the example of Figure 4, the user operating the MS 1 uses a streaming media application, and so it is known by the network that streaming media is required. A primary PDP context is already active (for browsing etc), and the streaming media requires a secondary PDP context. In step S1 1 , the MS 1 sends a PDP context activation request to the SGSN 7. The message includes a QoS profile and an indication that adaptive streaming is required. The SGSN is prepared by this message to proxy HTTP messages later. In step S12, the SGSN resisters a secondary PDP context as adaptive streaming and sends (in step S13) an accept message towards the MS 1 . In step S14, the MS1 request the MD from the CP 12. The CP 12 replies to the SGSN 7 in step S15. In step S16, the SGSN 7 receives information from RAN nodes and modifies the MD if necessary. In steps S17 and S18, the SGSN 7 informs the MS 1 that the PDP context is to be modified. In step S19 it sends the modified MD to the MS 1 , which (in step S20) stores the modified MD. The modified MD is used to control the media stream S21 .

In the example of Figure 5, the user operating the MS 1 uses a streaming media application, and so it is known by the network that streaming media is required. In step S22, the user opens a streaming media application, and so the MS 1 sends a PDP context activation request to the SGSN 7. The message includes a QoS profile and an indication that adaptive streaming is required. This is accepted in step S23. The user then selects the media to be streamed. In step S24, the MS 1 sends s secondary PDP context activation request that include the QoS profile and an indicator that adaptive streaming is required. In step S25, the SGSN resisters the secondary PDP context as adaptive streaming and sends (in step S26) an accept message towards the MS 1 . In step S27, the MS1 request the MD from the CP 12. The CP 12 replies to the SGSN 7 in step S28. In step S29, the SGSN 7 receives information from RAN nodes and modifies the MD if necessary. In steps S30 and S31 , the SGSN 7 informs the MS 1 that the secondary PDP context is to be modified. In step S31 it sends the modified MD to the MS 1 , which (in step S33) stores the modified MD. The modified MD is used to control the media stream S34.

In the example of Figure 6, the MS 1 is configured with an APN for default Internet access. Media streaming uses an existing PDP context. The user attempts to access the media by clicking on or entering a URL in a web browser at the MS 1 . It is known from the URL that it relates to streaming media. Once the user has accessed the URL, in step S35, the MS 1 sends a modify PDP context request to the SGSN 7. The message includes a QoS profile and an indication that adaptive streaming is required. In step S36, the SGSN resisters the PDP context as adaptive streaming and sends (in step S37) an accept message towards the MS 1 . In step S38, the MS1 request the MD from the CP 12. The CP 12 replies to the SGSN 7 in step S39. In step S40, the SGSN 7 receives information from RAN nodes and modifies the MD if necessary. In steps S41 and S42, the SGSN 7 informs the MS 1 that the PDP context is to be modified. In step S43 the SGSN 7 sends the modified MD to the MS 1 , which (in step S44) stores the modified MD. The modified MD is used to control the media stream S45.

In the example of Figure 7, the MS 1 is configured with an APN for default Internet access. A primary PDP context is used for general browsing. Media streaming uses a secondary PDP context with a QoS profile configured for media streaming. The user attempts to access the media by clicking on or entering a URL in a web browser at the MS 1 . It is known from the URL that it relates to streaming media. Once the user has accessed the URL, in step S35, the MS 1 sends a modify PDP context request to the SGSN 7. The message includes a QoS profile and an indication that adaptive streaming is required. In step S36, the SGSN resisters the PDP context as adaptive streaming and sends (in step S37) an accept message towards the MS 1 . In step S38, the MS1 request the MD from the CP 12. The CP 12 replies to the SGSN 7 in step S39. In step S40, the SGSN 7 receives information from RAN nodes and modifies the MD if necessary. In steps S41 and S42, the SGSN 7 informs the MS 1 that the PDP context is to be modified. In step S43 the SGSN 7 sends the modified MD to the MS 1 , which (in step S44) stores the modified MD. The modified MD is used to control the media stream S45.

The above examples use modified versions of PDP context activation procedures, the originals of which can be found in ETSI TS 123 060. They may be adapted to GREAN or UTRAN.

The service "Adaptive streaming" in the messages from the MS 1 establishing a PDP context may be indicated by either in a new attribute in an existing QoS Profile for "Streaming" (traffic type is still "streaming"), or by a completely new QoS Profile created for "Adaptive Streaming" (in this case traffic type will be "Adaptive streaming"). If the MD is not yet available for the network and for the MS 1 , the QoS attributes in the profile may use default values.

Where a secondary PDP context is established opened with a new QoS Profile for streaming, for example where streaming is started from a web-browser, a default APN is already used for web-access. The "Activate secondary PDP context" message is sent by the MS 1 to establish a secondary PDP context, which informs the SGSN 7 to proxy HTTP messages later.

The SGSN in all examples above blocks forwarding of the MD to the MS 7 in the HTTP reply. Modification of the MD by the SGSN 7 is performed by the SGSN 7 calculating the required QoS with regard to each attribute present in the QoS Profile (e.g. bandwidth is calculated for each quality level). The SGSN may restrict the QoS attribute values in the profile required by the media stream for a full-quality bitstream. The restrictions may be based on a subscribed QoS profile for the MS 1 and/or local measured system and network loads. This may be found by the SGSN 7 sending a "Request QoS Report" message to the RAN 4 to obtain more input for more precise restrictions on the profile. The target node for this message in the RAN is the RNC 8 or the BSC (Controller Nodes), and the message requests information on available resources in the network to satisfy the desired QoS. The message contains the desired minimum bandwidth. Before replying to the SGSN 7, the RNC 8 initiates a new "Request QoS Report" message to the RBS 1 1 to gather further information from the network. Based on the reply from the RBS 1 1 , the RNC 8 replies to the SGSN 7 with a "Request QoS Report Reply" message that contains aggregate QoS information about RAN network conditions. This allows the SGSN 7 to further restrict (if needed) the QoS attributes requested in the given PDP context. The content of "Request QoS Report Reply" messages may contain local system/network measurement reports over time.

The SGSN 7 modifies the MD according to the actual and updated QoS negotiated attributes, stores it and associates the MD with the flow to the MS 1 . This is achieved by assigning flow descriptors of the PDP context to the MD.

The SGSN 7 sends a "Create PDP Context request" message to the GGSN 10. Where the adaptation is to be performed both in the SGSN 7 and the GGSN 10, or a direct tunnel is used between the GGSN 10 and the RNC 8, the MD may be signalled to GGSN 10 at this step. The GGSN 10 may further downgrade the QoS negotiated based on its local measurement procedures and send back an "Update PDP Context Response" to the SGSN 7 that contains the updated QoS negotiated parameters. These steps are shown as "negotiation" in Figures 4 to 7. The GGSN 10 creates a new entry in its PDP context table and generates a Charging ID for the service. The Charging ID may reflect that the given media delivery service is a differentiated service. The GGSN 10 binds the MD to the PDP context.

In some circumstances, a request for an adaptive stream is not detectable. This use case applies to browser-based launch. If it is not possible to detect that the requested URL points to a manifest file, the GSN nodes proxy all HTTP messages. For a given user, a message is detected carrying a HTTP reply with a manifest file, or a HTTP request for an HTTP-AS service, alerting the GSN nodes the media adaptation is required.

If the MS 1 supports BSS Packet Flow Procedures, the SGSN 7 can request the creation of the BSS Packet Flow Context as a result of PDP context activation. A new or pre-defined Packet Flow ID per MS 1 is assigned to the adaptive streaming service. With this procedure all adaptive streaming sessions to a MS 1 will be handled together from QoS point of view. In a Create BSS Packet Flow Context Accept message, the BSS may restrict the requested Aggregate QoS Profile based on radio and transport shortage. BSS restriction of the requested QoS Profile may be based on inputs from both from the RBS 1 1 and the BSC 9. In case the RBS 1 1 is capable of, and is involved in the procedure, Request QoS Report and Request QoS Report Reply messages may be used between the BSC 9 and the RBS 1 1 . The SGSN 7 updates the MD according to the reply from BSS. For signalling RAN 4 network capabilities to the SGSN 7 in UTRAN, a RAB Assignment Procedure may be applicable to negotiate the proper QoS Profile for a given adaptive streaming service. In the RAB Assignment Response message, the RAN 4 (based on input from either or both from the RBS 1 1 and the RNC 8) indicates if a QoS Profile is not applicable in current radio or network situations. In this case the SGSN 7 sends a new RAB Assignment Request message with a changed QoS Profile. For adaptive streaming services, however, the RAN 4 may response with explicit capabilities with regard to available bandwidth to the SGSN 7 within the RAB Assignment Response message. Request QoS Report and Request QoS Report Reply messages may be used between the RNC 8 and the RBS 1 1 if the RBS 1 1 is involved in the capability report process.

Turning now to the Media adaptation procedure, this is based on local system and network measurements and is achieved by modifying the corresponding QoS profile within the given PDP context and updating the MD in the mobile service proxy nodes. As described above, updating the QoS Profile may be triggered by an end-user application HTTP request in a streaming session for an actual manifest file, or by changes to network conditions. In the first case the mobile service proxy node proxy the HTTP reply from the CP 12, modify the MD and forward it to the MS 1 . In the second case, if the mobile service proxy nodes experience changed networking characteristics, and the existing QoS Profile for a given media stream cannot be maintained any longer, the mobile service proxy node modifies the QoS Profile for the given PDP context and sends it towards the MS 1 in a "Modify PDP Context" message. In the meantime, the mobile service proxy node updates the corresponding MD and sends it via HTTP to the MS 1 . Otherwise, the mobile service proxy node will do this at the next HTTP request for the manifest file initiated by the MS 1 .

It is also possible that instead of the technique described above, the mobile service proxy node blocks media chunks in the case of HTTP-AS, and blocks given media layers in the case of scalable streaming, referring to quality levels requiring a high bandwidth not available in the network. In the case of HTTP-AS, this requires inspection and identification of HTTP packets, and their QoS requirements. In case of a scalable media stream, the GSN is able to identify to which media layer a packet belongs to. This is achieved by checking HTTP packets, but by performing packet inspection on an RTP level or other media transport protocol level. The following exemplary messages can be used for media adaptation in a UMTS system:

SGSN 7 to MS 1 : Modify PDP Context Request is sent whenever the MD has been updated locally, an Update PDP Context Request message with an updated MD is received from the GGSN 10, or a notification is received from a RAN 4 about altered network conditions.

GGSN 10 to SGSN 7: Update PDP Context Request message is sent if the system uses a direct tunnel between the GGSN 10 and the RNC 8 (UTRAN only), or the system runs two adaptation points and the MD has been updated in the GGSN. The updated QoS parameters are signalled in this message. An updated MD may be signalled within this message.

RNC 8 to SGSN 7 (QoS Report): according to local and network statistics measurements, the RNC 8 may notify the SGSN 7 about altered network conditions. Based on such a notification, the SGSN 7 may initiate a PDP Context update and adjust the MD as well. This means that the RNC 8 notifies the SGSN 7 in additional circumstances to when the Radio Bearer has completely been lost.

BSC 9 to SGSN 7 (QoS Report): according to local and network statistics measurements, the BSC 9 may notify the SGSN 7 about altered network conditions. Based on such a notification, the SGSN 7 may initiate a PDP Context update and additionally adjust the MD.

· BSS to SGSN 7: in GERAN, if BSS Context is supported and BSS Packet Flow Context is used for streaming services, BSS may initiate at any time a modification of the BSS Packet Flow Context for adaptive streaming in order to signal RAN 4 capabilities to the SGSN 7. Triggers for the modification procedure in the network include local load measurement inputs collected from, for example, queuing statistics and network reports from the RAN 4. Besides network adaptation, in the case of HTTP-AS, the MS 1 may run its own adaptation procedure based on the continuously updated MD. The MS 1 may perform throughput measurement and adopt the perceived quality of the media according to the MD. The adaptation itself is still performed by the MS 1 based on the actual MD. However, the MD is updated by the network continuously to ensure that the MS cannot request data from the media server at a quality that is not supported by current network conditions.

Figure 7 shows a QoS Information Element (see ETSI TS 124 008). This is adapted to indicate adaptation nodes if the PDP context is set up for adaptive streaming. In order to let the network signal the MD in update messages, a new IE could be introduced. For example, in the case of HTTP-AS, subtracted information from the MPD file can be included, such as the Representation ID of the segments and their bandwidth requirements.

Figure 9 illustrates an exemplary mobile service proxy node such as an SGSN 7. The SGSN 7 is provided with a receiver 13 for receiving the MD, a processor 14 for adapting the MD as described above, and a transmitter for sending the adapted MD towards the MS 1 . A second receiver 16 may be provided for, prior to receiving the MD, receive a PDP context activation or modify message indicating that adaptive streaming is to be used. A second transmitter 17 may be provided for sending a query to a RAN 4 node serving the MS 1 , in which case a third receiver 18 is provided for receiving a response, the response including information relating to conditions in the RAN 4.

A non-transitory computer-readable medium in the form of a memory 19 may be provided. The memory 19 may be used to store an MD 20 relating to streaming media. The memory 19 may also be used to store a computer program 21 which, when executed by the processor 14, causes the SGSN 7 to behave as described above.. Note that the computer program 21 may be provided from an external computer readable medium 22, such as a flash drive.

Figure 10 illustrates an exemplary MS 1 . The MS 1 is provided with a transmitter 23 for sending a PDP context message (activation or modify) as described above. The PDP context message includes any of an indication that adaptive streaming is to be used, an instruction to modify an existing PDP context, and an instruction to establish a secondary PDP context. This allows the mobile service proxy node to associate MD data with the MS 1 . Note that in some circumstances, an adaptive media service provided by the network operator may ensure that QoS parameters and the MD may never be downgraded below a minimum level that a user subscription allows. The techniques described above enable network control of adaptive streaming to take account of, for example, network conditions. It is application in various types of network, such as GERAN and UTRAN. Furthermore, service differentiation is enabled for adaptive streaming. Where network conditions deteriorate, graceful quality degradation can be applied, and a RAN 4 can apply more precise bandwidth management, allowing more efficient use of available resources.

It will be appreciated by the person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the present invention as described in the appended claims.

The following abbreviations have been used in this specification:

ABQP Aggregate BSS QoS Profile

AQM Active Queue Management

BS Bearer Service

BSC Base Station Controller

BSS Base Station Subsystem

CA Cell Area

CP Content Provider

GERAN GSM EDGE Radio Access Network

GGSN Gateway GSN

GPRS General Packet Radio Service

GSN GPRS Support Node

HTTP-AS HTTP Adaptive Streaming

IE Information Element

LLC Logical Link Control

LTE Long Term Evolution

MD Media Descriptor

MPD Media Presentation Description

MS Mobile Station

MT Mobile Terminal PDP Packet Data Protocol

QoE Quality of Experience

QoS Quality of Service

PDU Packet Data Unit

PFC Packet Flow Context

RAN Radio Access Network

RBS Radio Base Station

RNC Radio Network Controller

RTCP RTP Control Protocol

RTP Real-time Transport Protocol

RTP NALU RTP Network Abstraction Layer Unit

SCV Scalable Video Codec

SGSN Serving GSN

TCP Transmission Control Protocol

TN Transport Network

UMTS Universal Mobile Telecommunications System

UTRAN UMTS Terrestrial Radio Access Network

UDP User Datagram Protocol

Claims

CLAIMS:

1 . A method of handling adaptive streaming data towards a mobile station, the method comprising, at a mobile service proxy node in a communications network: receiving (S4) Media Descriptor data relating to an adaptive media streaming session towards the mobile station;

adapting (S7) the Media Descriptor data; and

sending (S8) the adapted Media Descriptor data towards the mobile station.

2. The method according to claim 1 wherein the mobile service proxy node is associated with any of a Serving GPRS Support Node and a Gateway GPRS Support Node.

3. The method according to claim 1 or 2, wherein the adaptation of the Media Descriptor data is performed according to any of a user subscription, network conditions and Quality of Service requirements.

4. The method according to any one of claims 1 to 3, further comprising, prior to receiving the Media Descriptor data:

receiving (S1 ) a PDP context message, the PDP context message indicating that adaptive streaming is to be used.

5. The method according to claim 4, further comprising, wherein the PDP context message comprises information for modifying (S2) a Quality of Service profile of an existing PDP context associated with the mobile station.

6. The method according to claim 4, wherein the PDP context message comprises information for establishing (S3) a secondary PDP context associated with the mobile station, the mobile station already being associated with a primary PDP context.

7. The method according to any one of claims 1 to 6, further comprising, prior to adapting (S7) the Media Descriptor data:

sending (S5) a query to a node in a Radio Access Network serving the mobile station;

receiving (S6) from the node in the Radio Access Network a response, the response including information relating to conditions in the Radio Access Network.

8. The method according to any one of claims 1 to 7, further comprising:

determining (S10) that updated Media Descriptor data is required in response to any of a change in network circumstances and a request from the mobile station; and adapting (S7) the Media Descriptor data.

9. A mobile service proxy node (7) for use in a communications network, the mobile service proxy node (7) comprising:

a receiver (13) for receiving Media Descriptor data relating to an adaptive media streaming session towards a mobile station (1 );

a processor (14) for adapting the Media Descriptor data; and

a transmitter (15) for sending the adapted Media Descriptor data towards the mobile station.

10. The mobile service proxy node according to claim 9 wherein the mobile service proxy node is associated with any of a Serving GPRS Support Node and a Gateway GPRS Support Node.

1 1 . The mobile service proxy node according to claim 9 or 10, wherein the processor (14) is arranged to adapt the Media Descriptor data according to any of a user subscription, network conditions and Quality of Service requirements.

12. The mobile service proxy node according to any one of claims 9 to 1 1 , further comprising a second receiver (16) arranged to, prior to receiving the Media Descriptor data, receive a PDP context message, the PDP context message indicating that adaptive streaming is to be used.

13. The mobile service proxy node according to any one of claims 9 to 12, further comprising,

a second transmitter (17) for sending a query to a node in a Radio Access

Network serving the mobile station;

a third receiver (18) for receiving from the node in the Radio Access Network a response, the response including information relating to conditions in the Radio Access Network.

14. The mobile service proxy node according to any one of claims 9 to 13, wherein the processor (14) is further arranged to determine that updated Media Descriptor data is required in response to any of a change in network circumstances and a request from the mobile station, and adapt (S7) the Media Descriptor data.

15. The mobile service proxy node according to any one of claims 9 to 13, further comprising a computer readable medium in the form of a memory (19), the memory arranged to store the Media Descriptor data (20) associated with the mobile station (1 ).

16. A mobile station (1 ) for use in a communications network, the mobile station comprising a transmitter (23) for sending to a mobile service proxy node (7) a PDP context message, the PDP context message comprising any of:

an indication that adaptive streaming is to be used;

an instruction to modify an existing PDP context; and

an instruction to establish a secondary PDP context;

wherein the PDP context message is usable by the mobile service proxy node to associate Media Descriptor data with the mobile station.

17. A computer program (21 ), comprising computer readable code which, when run on a computer device (7) causes the computer device to perform the method of any one of claims 1 to 8.

18. A computer program (26), comprising computer readable code which, when run on a mobile station (1 ) causes the mobile station (1 ) to behave as a mobile station (1 ) according to claim 16.

19. A computer program product comprising a non-transitory computer readable medium (19; 22; 25; 27) and a computer program (21 ; 26) according to claim 17 or 18, wherein the computer program is stored on the computer readable medium.