Resource management concept

Resource management such as network radio resource management in wireless networks, is described in connection with different aspects.

BACKGROUND OF THE INVENTION

The present invention is concerned with resource management such as network radio resource management in wireless networks.

In recent years multimedia delivery over the Internet has sharply increased becoming the main bandwidth consumer within the network. Parallel to this increase, significant improvements in mobile networks have led to the apparition of high speed access networks such as 3GPP's High Speed Downlink Packet Access (HSDPA) and the emerging Long Term Evolution (LTE) networks.

With the improvements in mobile networks IP services are expected to be a ubiquitous fact of the daily life. Recent studies expect that consumption of multimedia content, especially video streaming, is going to continue increasing [1], which may also be a result of the advances in mobile networks. In fact, in [2] it has been reported that about the 50% of the data traffic in mobile networks is video data and it is expected that two-thirds of the world's mobile data traffic will be video by 2015.

HTTP streaming is one of the promising multimedia applications that has emerged in the last years and has had an incredible acceptance by the market, which is evident by the standardization activities on adaptive HTTP streaming carried out by different standardization bodies, such as MPEG [3] and 3GPP [4] or proprietary solutions such as IIS Smooth Streaming [5] and HTTP Live Streaming [6].

Although media streaming has been associated previously with RTP/UDP due to its lower latency, relying on HTTP/TCP for media delivery has shown to be a very valuable solution for scenarios where extremely stringent delay constraints are not considered, since traversal problems within NAT and Firewalls, typical with RTP/UDP, are not present.

Dynamic Adaptive Streaming over HTTP (DASH) [3] is an emerging MPEG standard, which defines a format for multimedia delivery over HTTP. It basically consists of two elements: the format of the media to be downloaded and the description of the media to be downloaded. Existing proprietary solutions are based on a similar approach.

The media format is basically structured in typically small time intervals of video, called segments, which if continuously downloaded allow for a continuous representation of the media. Furthermore, usually different representations, e.g. encodings, of the media at different bitrates are available at the server allowing for a user-driven adaptation, where users select representations based on the observed network throughput. Download of segments of different representations for different time intervals is allowed resulting in a perfectly playable media, if all switching constraints presented in the Media Presentation Description (MPD), described below, are followed.

In DASH, the description of the format is given by the MPD. The MPD is an XML document, which describes the data and especially the segments available at the server. Using the MPD the clients have the information necessitated to make the requests which fit their network throughput or their requirements.

In DASH the clients are responsible for performing adaptation. Based on the interests of the users, equipment capabilities and current status of the network, DASH clients have to select the representation(s) described in the MPD, which match best the necessities/capabilities of the clients. An example of DASH architecture is shown inFIG. 1.

As is visible fromFIG. 1, the participating entities in a DASH environment are: the DASH server10which receives its media content to be distributed to respective DASH clients12from some DASH content preparation stage14, the DASH client12itself and the network interconnecting the DASH server10and the DASH client12with the network16being denoted as “HTTP Cache”. As depicted inFIG. 3, the DASH client may run on a suitable user terminal such as a television device or a computer or the like, when the DASH client receives from the DASH server10the media presentation description MPD18which, in turn, has been generated along with the versions of the media content by the DASH content preparation stage14so as to describe the various versions of the media content available at the DASH server10.

FIG. 2shows the state of the art of the deployment architecture of DASH in LTE networks which uses entities from the DASH standard [ISO/IEC 23009-1]. The white boxes specify the DASH system, while the shaded boxes specify the LTE system. To be more precise, in transferring the DASH infrastructure to LTE networks, the DASH client12is shown to be connected to the HTTP CASH16via a concatenation of an LTE base station20, a radio channel22and a user entity24, wherein a radio resource manager26is shown to be comprised by the base station20and the user entity24may be a mobile terminal such as a mobile phone or the like at which the DASH client12is operating in form of, for example, a software running on the user entity's processor. It is assumed that the DASH client12as well as the LTE eNB20have access to the media presentation description (MPD18). The MPD18provides sufficient information about the video representation at server10to provide a streaming service to the user12by the user requesting segments from the HTTP server10using TCP/IP as transport protocol. Initially, the dash client12transmits a HTTP get request to the HTTP server10. After HTTP handshake a TCP tunnel between server10and client12is established. This TCP tunnel is transparent for the underlying physical transport layer. Depending on the information provided by the MPD18, the DASH client12has enough information for demultiplexing, decoding and rendering the included media data appropriately.

The problem involved with the scenario depicted inFIG. 2is the usual behavior of the DASH client12according to which each DASH client12seeks to provide its user with the version of the media content residing on the respective server10having the highest quality and/or information content possible at the currently assigned communication resources, assigned by the radio resource manager26to the user entity24of the respective DASH client12. The “highest possible” quality/information content could then one having maximum spatial resolution, maximum number of views, maximum width depth and the like, thereby necessitating the highest bandwidth. This, in turn, means that each DASH client12maximally strains the available radio resources of the base station26and the base station and the radio resource manager26, respectively, has to cope with steadily requesting an increase of assigned communication resources in order to obtain one of the available higher level versions of the media content which the respective DASH client of the respective user entity wishes to obtain. Naturally, this leads to a suboptimal distribution of the radio communication resources to the user entities which distribution or scheduling is performed based on a current channel situation and user profiles assigned to the individual user entities24.

Accordingly, it is an object of the present invention to provide a resource management concept which enables a more efficient use of the available communication resources in order to, for example, maximize the number of satisfied users.

SUMMARY

According to an embodiment, a radio resource manager may be configured to assign communication resources of at least one base station to user entities depending on a media presentation description relating to a media content transferred within a data traffic from a server to a client with one of the server and the client operating at one of the user entities.

Another embodiment may have a user entity for communicating with a radio resource base station, on which a client or server is operative, wherein the user entity is configured to survey a data traffic to/from the client or server so as to derive a media presentation description describing versions of differing bandwidths of a media content, and forward, at least partially, the media presentation description to a radio resource manager responsible for assigning the communication resources of the radio resource base station to user entities to which the user entity belongs.

Another embodiment may have a user entity for communicating with a radio resource base station, on which a client is operative, wherein the user entity is configured to determine a received media content throughput or buffer state of a media content retrieved by the client from a server and inform a radio resource manager responsible for assigning the communication resources of the radio resource base station to the user entity, on the determined media content throughput or buffer state.

Another embodiment may have a client for being operative on a user entity for communication with a radio resource base station, the client being configured to retrieve from a server a media presentation description and a media content, the media presentation description describing versions of differing bandwidths of the media content, the client being configured to be switchable from a normal mode to a slave mode by means of a signalization from a radio resource manager responsible for assigning the communication resources of the base station to the user entity, wherein the client is configured to, in the normal mode, request the media content from the server in a version determined by the client based on the communication resources assigned to the user entity, and, in the slave mode, request the media content from the server in a version determined by the client irrespective of the communication resources assigned to the user entity.

Another embodiment may have a resource manager configured to inspect a media presentation description describing versions of a media content of differing bandwidths, within a data traffic from a server to a client operating at a user entity; inspect a media request from the client to the server, requesting a wanted version of the media content; and decide, depending on a current resource situation information and the media presentation description, to forward the media request to the server, or, alternatively, to cause that the media request does not lead to the wanted version of the media content being sent to the client.

Another embodiment may have a resource manager configured to inspect a media presentation description describing versions of a media content of differing bandwidths, within a data traffic from a server to a client operating at a user entity; inspect a media request from the client to the server, requesting a wanted version of the media content; obtain an user entity's buffering state for the client by simulating same based on channel quality feedback from the user entity to the base station or a monitoring of a media content buffer positioned on the other side of the base station or within the base station, or extracting the user entity's buffering state from an explicit signalization within a data traffic from the client to the server; and decide, depending on the user entity's buffering state and the media presentation description, to forward the media request to the server, or, alternatively, to cause that the media request does not lead to the wanted version of the media content being sent to the client.

Another embodiment may have a resource manager configured to inspect a media presentation description request from a client operating at a user entity to a server, the media presentation description request requesting a media presentation description from the server, the media presentation description describing versions of a media content of differing bandwidths; inspect the media presentation description within a data traffic from the server to the client; decide, based on a current resource situation information and the media presentation description, to forward the media presentation description to the client as an answer to the media presentation description request, or to intercept the media presentation description, and modify the media presentation description.

Another embodiment may have a radio resource manager configured to assign communication resources of a base station to user entities depending on media buffering state information of a client operating at one of the user entities.

Another embodiment may have a radio resource manager configured to survey data traffic between clients operating at user entities, and one or several servers; check as to whether there are media presentation descriptions within the data traffic from the one or several servers to different ones of the clients, which relate to a common media content, wherein the radio resource manager is configured to, depending on the check, offer to the clients a multicast version of the common media content, besides unicast versions of the media content; or the radio resource manager is configured to, depending on the check, cause a change of a protocol for clients downloading the common media content from a unicast protocol to a multicast protocol.

Another embodiment may have a radio resource manager configured to assign communication resources of at least one base station to user entities, wherein the radio resource manager is configured to survey a data traffic to a server or a client operating at one of the user entities to or control information from another radio resource manager so as to obtain information on guaranteed communication resources currently assigned to an external user entity which the other of the server and the client operates on, or a buffer state of the other of the server and the client, and perform the assignment depending on the information obtained.

According to another embodiment, a method for radio resource managing may have the step of: assigning communication resources of at least one base station to user entities depending on a media presentation description relating to a media content transferred within a data traffic from a server to a client with one of the server and the client operating at one of the user entities.

According to another embodiment, a method for being performed on a user entity on which a client or server is operative, the user entity communicating with a radio resource base station, may have the steps of: surveying a data traffic to/from the client or server so as to derive a media presentation description describing versions of differing bandwidths of a media content, and forwarding, at least partially, the media presentation description to a radio resource manager responsible for assigning the communication resources of the radio resource base station to user entities to which the user entity belongs.

According to another embodiment, a method for being performed on a user entity on which a client is operative, the user entity communicating with a radio resource base station, may have the steps of: determining a received media content throughput or buffer state of a media content retrieved by the client from a server and informing a radio resource manager responsible for assigning the communication resources of the radio resource base station to the user entity, on the determined media content throughput or buffer state.

According to another embodiment, a method may have the steps of: inspecting a media presentation description describing versions of a media content of differing bandwidths, within a data traffic from a server to a client operating at a user entity; inspecting a media request from the client to the server, requesting a wanted version of the media content; and deciding, depending on a current resource situation information and the media presentation description, to forward the media request to the server, or, alternatively, to cause that the media request does not lead to the wanted version of the media content being sent to the client.

According to another embodiment, a method may have the steps of: inspecting a media presentation description describing versions of a media content of differing bandwidths, within a data traffic from a server to a client operating at a user entity; inspecting a media request from the client to the server, requesting a wanted version of the media content; obtaining an user entity's buffering state for the client by simulating same based on channel quality feedback from the user entity to the base station or a monitoring of a media content buffer positioned on the other side of the base station or within the base station, or extracting the user entity's buffering state from an explicit signalization within a data traffic from the client to the server; and deciding, depending on the user entity's buffering state and the media presentation description, to forward the media request to the server, or, alternatively, to cause that the media request does not lead to the wanted version of the media content being sent to the client.

Another embodiment may have a method configured to inspecting a media presentation description request from a client operating at a user entity to a server, the media presentation description request requesting a media presentation description from the server, the media presentation description describing versions of a media content of differing bandwidths; inspecting the media presentation description within a data traffic from the server to the client; deciding, based on a current resource situation information and the media presentation description, to forward the media presentation description to the client as an answer to the media presentation description request, or to intercept the media presentation description, and modify the media presentation description.

According to another embodiment, a method for radio resource managing may have the steps of: surveying data traffic between clients operating at user entities, and one or several servers; checking as to whether there are media presentation descriptions within the data traffic from the one or several servers to different ones of the clients, which relate to a common media content, depending on the check, offer to the clients a multicast version of the common media content, besides unicast versions of the media content; or depending on the check, causing a change of a protocol for clients downloading the common media content from a unicast protocol to a multicast protocol.

According to another embodiment, a method for assigning communication resources of at least one base station to user entities may have the steps of: surveying a data traffic to a server or a client operating at one of the user entities to or control information from another radio resource manager for assigning communication resources to at least one different base station so as to obtain information on guaranteed communication resources currently assigned to an external user entity which the other of the server and the client operates on, or a buffer state of the other of the server and the client, and performing the assignment depending on the information obtained.

Another embodiment may have a computer program having a program code for performing, when running on a computer, the above methods.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 3shows a first embodiment of a radio resource manager in accordance with the present application. The radio resource manager ofFIG. 3is generally indicated with reference sign30and is configured to assign communication resources of a base station32to user entities for which one is representatively shown at34. The user entity34is, for example, a mobile terminal such as a mobile phone, a laptop or the like, but may also be a stationary device. The user entity34is able to communicate with the base station32via a wireless channel36via its antenna or antennas (not shown). The base station32appropriately manages the multiplexing of communication data, i.e. downlink and uplink data onto the communication channel36, and may have also one or more antennas (not shown). In particular, the base station32appropriately multiplexes downlink data for the various user entities34onto the transmit signal output by base station32. Different multiplexing schemes may be used to this end. For example, the base station32may use OFDM and, in particular, LTE. In any case, the base station32is able to distribute or assign the communication resources of the communication channel to the user entities, including user entity34, in a time-varying manner so as to adapt the assignment of the communication resources of base station32to the user entities—called, inter alias, the scheduling—to the current resource situation. For example, the base station32may rely on any combination of the following parameters in order to perform the scheduling:1) The number of user entities34served by the base station32, i.e., the number of user entities34having performed a registration at the base station32and thus, the number of user entities34among which the base station's communication resources are to be distributed.2) The sort of the communication data to be exchanged with the individual user entities, the sort of communication data differentiating, for example, real time (low delay) media data such as speech signals, from HTTP requested data and the like.3) User profiles assigned to the served user entities with the profiles being assigned, for example, with different maximum bit rates and/or minimum bit rates for downlink and/or uplink, or defining a priority among the user entities with the RRM30favoring, in assigning the communication resources, user entities having a higher priority over user entities having a lower priority.4) Channel quality feedback from the user entities, indicating the user entities' current reception quality situation, i.e. the channel quality between base station32on the one hand and the individual served user entities34on the other hand, wherein the base station32measures the channel quality, for example, by respective channel feedback signals from the user entities5) Channel rate requests from the user entities, indicating the user entities' wishes for the assignment of further bandwidth.

In case more than one base station32and38may serve one user entity, then the number concerns the number of user entities served by all the base stations currently serving, or at least currently being available for serving, the user entities in some area. The interaction between these base stations could also be taken into account when determining the assignment of the communication resources. In that scenario, information such as subcarriers aggregated by RRM30or information derived by RRM30about the user entities34such as Handover between cells, can be further shared between base stations32and38and collected and used by a higher level RRM30.

The base station32may have different options/parameters in order to differently assign the communication resources to the user entities. This is true for both downlink and uplink communication. For example, the base station32could implement a scheduling by any combination of the following settings:1) The association of subcarriers to the served user entities, such as the OFDM subcarriers. Typically, the maximum number of subcarriers used in LTE is 20 MHz bandwidth. Naturally, this may be modified. For the successor of LTE, called LTE-Advanced, multiple carriers of 20 MHz up to 100 MHz is in discussion. This is called carrier aggregation. That is, subcarriers may also be aggregated subcarriers.2) The association or distribution of time slots to the served user entities.3) The spatial coverage of the base stations cell within which the user entities have to be to be able to communicate with the base station32, the spatial coverage being changed by use of, for example, MIMO techniques.4) The association of the individual subcarriers to modulation constellations

In case of not implementing the scheduling by any of the just-mentioned setting options, the base station32may either not use the respective transmission feature or use a fixed setting instead. For example, the base station32may not use time division multiplexing within the downlink and/or no time division multiplexing within the uplink or the respective time division multiplexing may be fixed over time. The same applies with respect to the MIMO functionality of the frequency division multiplexing involving the assignment of subcarriers.

In any case, depending on the assigned communication resources, each user entity34experiences an effective transmission bandwidth for both downlink and uplink.

As a minor note it should be noted that the radio resource manager30ofFIG. 3could be included, could be part of, or could be housed by, the base station32. However, the radio resource manager30could also be arranged physically separated from the base station32. In particular, it could even be possible that the radio resource manager30is not especially associated with a certain base station. Rather, the radio resource manager30could manage the radio resource management for a higher number of user entities resulting in the cells of more than one base station.FIG. 3, for example, shows an optional further base station38, the communication resources of which may, optionally, also be controlled by radio resource manager30. In particular, it could be possible that the base stations32and38form, along with a radio resource manager30, a wireless network that allows for the user entities to be concurrently served by more than one base station. That is, user entities currently present in the overlap area of both base station cells could have communication resources of both base stations assigned to it by the radio resource manager30. Accordingly, the effectively available communication bandwidth of user entity34would, in that case, be the sum of the effective bandwidth offered, or assigned to it, by each of the serving base stations32and38. Naturally, the number of serving base stations could be increased.

In any case, the problem involved with the functionality of the radio resource manager30as described so far is that a client40operating at one of the user entities, such as user entity34, seeks to obtain a media content from a server42in a version having an information content level as high a possible. The client may, for example, be an application running on a user entity's operating system such as a browser, a VoIP (voice over IP) application or the like, although other possibilities exist as well. The server, in turn, may be a program, such as a VoIP application or a media content server, running on a host such as a computer, another mobile user entity, a work station, or a network.

Imagine, for example, that the client40of user entity34seeks to download a media content44from server42and that this media content44is available at server42in different versions as described by a media presentation description46which is also available from server42for client40. The different versions of the media content44may differ in any combination of any subset of the following parameters:1) Spatial resolution2) Temporal resolution3) Number of views4) Bit depth5) Signal to noise ratio6) Number of audio channels.

That is, the media content44may be a video. The data traffic via which client40obtains the media content44from server42is at least surveyable by radio resource manager30as it is depicted by dotted line48which shows that the data traffic between server42and client40leads past base station32or the base stations32and38, respectively, with a content of the data traffic being inspectable by the radio resource manager30as shown with arrow50. Alternatively, the data traffic may even lead through the radio resource manager30as illustrated by dashed arrow52so that, in accordance with this alternative, the radio resource manager30would even be able to not only inspect, but also intercept or otherwise influence portions of the data traffic between client40and server42.

The data traffic may use any appropriate protocol such as HTTP. The underlying transport protocol may be TCP or UDP.

However, although the descriptions of embodiments are focused on HTTP streaming, the data transfer itself may be also applied differently, such as via RTP [IETF RFC 3550]. Therefore, a description of the media in a session is given by a SDP [IETF RFC 4566] (Session Description Protocol) file. Such an SDP file is to be regarded as an “MPD” in the sense of the present application and allows the description of different media characteristics such as different encoding parameters to be chosen from.

Due to the fact that the various versions of the media content44convey a different amount of information on the media content44, these versions allow for a ranking among these versions with respect to their minimum transmission bandwidth necessitated in order to play the respective version at the client40without interruptions.

Normally, a client40is configured to provide the user with a version offering the highest possible information on the media content44. The highest possible version may be defined as the one which is still presentable to the user by the facilities available by the user entity34such as by the display and loudspeakers available at the user entity34, or by the media player, decoder or the like. To be more precise, although not shown inFIG. 3, the user entity34may comprise a display for displaying the frame sequence of the media content44and one or more loud speakers in order to reproduce an optional audio signal accompanied to the frame sequence. In the latter case, the client40may try to provide the user with the version of the media content44which offers the highest spatial resolution which is still reproducible by the display of the user entity34, for example.

Finally, client40requests a wanted version of the media content44from server42such as, for example, by a HTTP request. In order to enable the client40to decide on the version to be provided to the user, client40is provided with the media presentation description46within the data traffic from the server42to client40. For example, client40requests the media presentation description46of the media content44from server42which, in turn, responds by sending the media presentation description46to client40. As described above, the media presentation description46indicates to client40the available versions available at server42of media content44and the necessitated minimum transmission bandwidths of these versions. Accordingly, client40evaluates the currently available efficient bandwidth offered or assigned to the user entity34by radio resource manager30and selects, usually, the version having the highest level and necessitating, accordingly, the highest minimum transmission bandwidth necessitated which still is below, or equal to, the efficient bandwidth offered by video radio resource manager30.

However, as described in the introductory portion of the specification of the present application, as all the clients40operating at the user entities seek to provide the users with the maximum bandwidth version of the respective media content, the strain put onto the communication resources of the base station32is high although, for example, the strain would not have to be that high if the clients40would lower their requested version level.

Accordingly, in accordance with the embodiment ofFIG. 3, the radio resource manager30is configured to assign the communication resources of the base station32to the user entities including user entity34, depending on the media representation description46within the data traffic from a respective server42to a respective client40operating at the respective user entity34. As will get clear from the below description, the communication resources assigned by RRM using the outlined dependency on the MPD46, may especially pertain the uplink and/or downlink communication resources, which represent a major part of the overall communication resources which, in turn, may also encompass control signaling such as the acknowledgment feedback loop of TCP or the afore-mentioned quality feedback.

To be more precise, the radio resource manager30is configured to inspect the media presentation description46describing the versions of the video content44of differing bandwidths within the data traffic from the server42to client40and takes the information provided by the media presentation description into account, along with the other input parameters, when assigning the communication resources of the base station32to the user entities among which the user entity34is.

For example, if there is currently a high strain put onto the communication resources of base station32due to, for example, a high number of user entities34to be served, radio resource manager30may decide that a version of the media content44currently requested from server42by client40should currently not be available for the client40and accordingly, reduces the amount of communication resources assigned to user entity34, thereby effectively reducing the effective bandwidth offered to the user entity34. In other words, the radio resource manager30may decide, that in high strain situations, client40should switch from a higher level version of the media content44to a lower level version thereof, at least temporarily during the high strain put on to the communication resources of base station32. Of course, RRM30may check the existence of such a lower bandwidth version in advance. Naturally, the client could also get for some reasons, e.g., to optimize the video quality watched by clients in the cell, a version with a higher bandwidth in order to get a minimum acceptable video quality or information amount. In other words, the RRM30not necessarily assigns the communication resources to the clients merely in order to optimize the cell throughput. Rather, the RRM30could also take the video quality for all clients in the cell into account. In even other words, of course, there are cases where clients do notoriously apply for maximum quality. An example for such clients, are clients in the automatic switching mode exemplarily described below.

From another point of view, the radio resource manager30may be configured to, if the clients40of more than one of the user entities34to which the communication resources are assigned, are currently downloading respective media content44via the at least one base station32, perform the assignment of the communication resources to the more than one user entities34depending on the respective media presentation description46within the respective data traffic from the respective pair of server and client such that a cost function is optimized which, at least, depends on a quality measure and a minimum bandwidth of the versions for each media content44of the clients. To be more precise, the cost function to be optimized, may form a tradeoff between a total bandwidth and a total quality measure determined over the versions for each media content44of the clients. This optimization may result in clients getting a bandwidth for a lower quality version of their media content assigned thereto than originally applied for, as well as clients getting a bandwidth for a higher quality version of their media content assigned thereto than originally applied for. The “quality measure” for the individual media contents' versions needs not to be interval scaled. An ordinal scale as offered by @qualityRanking could be enough. That is, the ordinal scale may relate to the individual media contents only. Ordinality needs not to be valid among all media contents of all clients40. However, additional information may be included into the optimization cost function, such as a measure of a coding complexity of the respective media content, i.e. a measure for an average rate/distortion measure, of the media content. This coding complexity measure may be very coarse. For example, @contentCharacteristic mentioned below could be such a characteristic. All this information could be included into the media presentation description46of the respective media content requested by the respective client.

Moreover, the radio resource manager30may log a history of versions of the media content44requested by client40in order to use the history in order to re-assign a higher amount of communication resources to the respective client40in phases where the strain put on to the communication resources of the base station30decreases again.

The client40, in turn, will realize by evaluating the current effective bandwidth provided by radio resource manager30, that—incase the RRM30decided to lower the assigned communication resources amount—the currently requested and downloaded version of media content44is presentable to the user merely with interruptions. In other words, the client40will realize that the media buffer of the media player reproducing the media content44to the user is going to get empty due the decrease of the available transmission bandwidth via the wireless communication path36. While the client40is free to react to this situation as it wishes or as the client wishes, one reasonable option of the client40would be that same sends a request to server42, requesting a lower level version of the media content44, i.e., a version associated with a lower necessitated minimum transmission bandwidth than compared to the currently downloaded version of the media content44.

To summarize, in accordance with the embodiment ofFIG. 3, the radio resource manager30performs the scheduling—besides the dependency on available resources, channel quality as indicated by the user entities feedback, number of resource requests from the associated user entities, priorities among the user entities and the like, as mentioned above—depending on the media presentation description46within the data traffic extending between respective pairs of servers and clients operating at respective user entities.

With respect to the embodiment ofFIG. 3, it is noted that the client30may, for example, represent software which is running on a user entity processor. Alternatively, the client may be implemented in hardware or programmable hardware.

Thus,FIG. 3reveals a radio resource manager configured to assign communication resources of a base station32to user entities34depending on a media presentation description46within a data traffic from a server42to a client40operating at one of the user entities32.

In the following, a possible implementation of the embodiment ofFIG. 3is explained. According to this possible implementation, the client30uses video streaming over HTTP in order to obtain the media content44from server42. In particular, the underlying transport protocol used for the video streaming over HTTP may be the TCP [RFC 793].

In fact, the implications pointed out here are valid for every protocol that shares the properties described in the following. The considered protocols here are connection oriented protocols with a congestion control mechanism based on reception of ACKs (acknowledgement)/NACKs (Negative-acknowledgement) or any other type of acknowledgment such as SACKs (Selective-acknowledgment) used for TCP. Possibly, these protocols may used additionally retransmission mechanisms for coping with packets losses parallel to the throughput adaptation result of the congestion control mechanism. On example of such a protocol would be when the underlying transport protocol used for video streaming over HTTP is the TCP [RFC 793]. TCP provides streaming data transfer with enhanced features to provide reliability, e.g. using acknowledgement messages (ACK) and flow control mechanisms, e.g. congestion control via slow start, congestion avoidance, fast retransmit and fast recovery. Flow control indicates the transmitter how many bytes can be received without overflow of internal buffers. The relevant media and status rates are depicted inFIG. 4and Table 1. As seen in the inFIG. 4, packet loss has an influence on the received TCP throughput and the same is expected for any other protocol with the aforementioned characteristics. Furthermore, the equation below shows a very good estimation of the TCP throughput based on the packet loss (p), Round Trip Time (RTT) and Maximum Transmission Unit (MTU) [18]. Therefore, tracking network layer packet losses in transmission is a very effective technique to allow the radio resource manager to assign communication resources of a base station32properly. Therefore,32may derive from the PHY layer information, such as lost radio frames/MAC layer packet data units and the higher layer MTU size as well as the TCP packet loss at the MAC buffers100of30(cf.FIG. 13) to derive the actual packet loss rate on the higher network layer such as the transport layer, e.g. for TCP.

TABLE 1Available Times and RatesSegment downloadTime it takes to download a single video segmenttimeMedia rateMedia rate, e.g. rate of the AVC/SVC video serviceInstantaneousVariable bit rate available on the physical layer ofratethe transport media, e.g. broadband wireless system,here: LTESegment downloadResulting received segment download rate, depend-rateing on the RRM in the LTE eNB

With respect toFIG. 3, for example, the radio resource manager30has different possibilities to check as to which version of a media content out of the MPD46the client40is currently downloading. For example, the RRM30may determine the version of the media content44currently downloaded by the client44via base station32by inspecting a media request from the client40to the server42. A simpler processing at RRM30, however, with less tracking operations, is, however, achievable when RRM30determines a throughput measure for a received media throughput of the client and predicts from the determined throughput measure as to which version of a media content44out of the media presentation description46, is currently downloaded by the client44via the at least one base station32. As the throughput measure, the assigned bandwidth itself may be used. Alternatively, RRM30may try to estimate the deviation/decrease of the actually received media content bandwidth of the respective client40from the originally assigned bandwidth to the respective user entity, by way of an evaluation of the quality feedback sent from the respective user entity34to the base station32, as has been just described. Even alternatively, an additionally functionality of the user entity may inform the RRM30about the actually received media content throughput rate.

Although the above description assumed the radio resource manager to survey the data traffic from the server42to the client40so as to obtain the media presentation description46, this overhead may alternatively displaced to the user entity such as some entity within the user entity, which is between a user entity's transceiver stage and the client (seeFIG. 7, for example). That is, this surveillance could be assumed by a surveillance stage within the user entity. The surveillance stage would forward the MPD30—back—to the RRM30, or at least a subpart thereof such as en excerpt thereof, or a set of parameters which are derived from a subpart of the MPD, wherein excerpt or set of parameters may, in turn, be enough in order to described the media content and its versions available at the server32. Thus, the user entity34may be configured to communicate with the radio resource base station32and may have the client40operative thereon, as described above, wherein, however, the user entity34may additionally be configured to survey the data traffic from the server42to the client40so as to derive the media presentation description46from the data traffic and forward, at least partially, the media presentation description to the radio resource manager30. Later, it will be shown that the user entity may have a server operating thereat instead of client40, with the RM however, acting the same, i.e. by surveying the data traffic from that server to any client outside the user entity in order to derive the MPD.

Moreover, in the implementation ofFIG. 3described next, client40and server42may use DASH in order to stream the media content44from server42to client40. DASH defines a certain structure or syntax for the media presentation description. According to DASH, the MPD uses tags to specify parameters needed for setting up logical channels between DASH client and DASH HTTP server. Tags can either be optional, marked with letter O, or mandatory, marked with letter M.

For implementing the embodiment ofFIG. 3, a combination of MPD tags, taken from the MPEG DASH standard (ISO/IEC 23009-1 [3]) could be used.

In particular, the mandatory @bandwidth tag could be taken into account which relies on the @minBufferTime tag and which is therefore quasi-mandatory.

The tags which the MPD could be constructed of, comprise:

TABLE 2MPD tagsMain tags:@bandwidthMspecifies a bound on the data rate anddata rate variation of theRepresentation as follows: Consider ahypothetical constant bitrate channel ofbandwidth with the value of this attributein bits per second (bps). Then, if theRepresentation is continuouslydelivered over this channel, starting atany SAP that is indicated either by@startWithSAP or by any SegmentIndex box, a client can be assured ofhaving enough data for continuousplayout providing playout begins after@minBufferTime * @bandwidth bitshave been received (i.e. at time@minBufferTime after the first bit isreceived).For dependent Representations thisvalue shall specify the minimumbandwidth as defined above of thisRepresentation and all complementaryRepresentations.@minBufferTimeMspecifies a common duration used inthe definition of the Representation datarate (see @bandwidth attribute in5.5.5.2).@qualityRankingOspecifies a quality ranking of theRepresentation relative to otherRepresentations in the same AdaptationSet. Lower values represent higherquality content. If not present then noranking is defined.Tags to be considered for more detailed client status tracking (optional tags):@availabilityEndTimeOspecifies the latest Segment availabilityend time for any Segment in the MediaPresentation. When not present, thevalue is unknown@availabilityStartTimeCMFor @type = “dynamic” this attribute shallMust bebe present. In this case it specifies thepresent foranchor for the computation of thetype = “dynamic”earliest availability time (in UTC) for anySegment in the Media Presentation.For @type = “static” if present, itspecifies the Segment availability starttime for all Segments referred to in thisMPD. If not present, all Segmentsdescribed in the MPD shall becomeavailable at the time MPD becomesavailable.@mediaPresentationDurationCMspecifies the duration of the entireMust beMedia Presentation. If the attribute ispresent fornot present, the duration of the Mediatype = “static”Presentation is unknown. In this casethe attributeMPD@minimumUpdatePeriodMPDshall be present.This attribute shall be present when theattributeMPD@minimumUpdatePeriodMPD isnot present.@startOif present, specifies the PeriodStart timeof the Period.The PeriodStart time is used as ananchor to determine the MPD start timeof each Media Segment as well as todetermine the presentation time of eachaccess unit in the Media Presentationtimeline.@durationOif present specifies the duration of thePeriod to determine the PeriodStarttime of the next Period.@bitstreamSwitchingODWhen this flag is set to ‘true’, theDefault: falsefollowing applies:All Representations in theAdaptation Set shall have the samenumber M of Media Segments;Let R1, R2, . . . , RN be all theRepresentations within the AdaptationSet.LetSi, j, for j > 0, be the jth MediaSegment in the ith Representation (i.e.,Ri)if present, let Si, 0 be theInitialization Segment in the ithRepresentation, andif present, let Bi be the BitstreamSwitching Segment in the ithRepresentation.The sequence ofany Initialization Segment, ifpresent, in the Adaptation Set, with,if Bitstream Switching Segmentsare present,Bi(1), Si(1), 1, Bi(2), Si(2), 2, . . . , Bi(k),Si(k), k, . . . , Bi(M), Si(M), MelseSi(1), 1, Si(2), 2, . . . , Si(k), k, . . . , Si(M), M,wherein any i(k) for all k values in therange of 1 to M, respectively, is aninteger value in the range of 1 to N,results in a “conforming Segmentsequence” as defined in 4.5.3 with themedia format as specified in the@mimeType attribute.More detailed rules may be defined forspecific media formats@startWithSAPOwhen present and greater than 0,specifies that in the associatedRepresentations, each Media Segmentstarts with a SAP of type less than orequal to the value of this attribute valuein each media stream.A Media Segment starts with a SAP in amedia stream if the stream contains aSAP in that Media Segment, ISAUis theindex of the first access unit that followsISAPand ISAPis contained in the MediaSegment.AdaptationSet0 . . . Nspecifies an Adaptation Set.At least one Adaptation Set shall bepresent in each Period. However, theactual element may be present only in aremote element if xlink is in use,For more details see 5.5.3.@minBandwidthOspecifies the minimum @bandwidthvalue in all Representations in thisAdaptation Set. This value has thesame units as the @bandwidthattribute.@maxBandwidthOspecifies the maximum @bandwidthvalue in all Representations in thisAdaptation Set. This value has thesame units as the @bandwidthattribute.@widthOspecifies the horizontal visualpresentation size of the video mediatype on a grid determined by the @sarattribute.In the absence of @sar width andheight are specified as if the value of@sar were “1:1”NOTE The visual presentation size ofthe video is equal to the number ofhorizontal and vertical samples used forpresentation after encoded samples arecropped in response to encodedcropping parameters, “overscan”signaling, or “pan/scan” displayparameters, e.g. SEI messages.@heightOspecifies the vertical visual presentationsize of the video media type, on a griddetermined by the @sar attribute.@sarOspecifies the sample aspect ratio of thevideo media component type, in theform of a string consisting of twointegers separated by ‘:’, e.g., “10:11”.The first number specifies the horizontalsize of the encoded video pixels(samples) in arbitrary units. The secondnumber specifies the vertical size of theencoded video pixels (samples) in sameunits as the horizontal size.@frameRateOspecifies the output frame rate (or in thecase of interlaced, half the output fieldrate) of the video media type in theRepresentation. If the frame or field rateis varying, the value is the averageframe or half the average field rate fieldrate over the entire duration of theRepresentation.The value is coded as a string, eithercontaining two integers separated by a“/”, (“F/D”), or a single integer “F”. Theframe rate is the division F/D, or F,respectively, per second (i.e. the defaultvalue of D is “1”).@mimeTypeMspecifies the MIME type of theconcatenation of the InitializationSegment, if present, and all consecutiveMedia Segments in the Representation.@codecsMspecifies the codecs present within theRepresentation. The codec parametersshall also include the profile and levelinformation where applicable.The contents of this attribute shallconform to either the simp-list or fancy-list productions of RFC6381, Section3.2, without the enclosing DQUOTEcharacters. The codec identifier for theRepresentation's media format, mappedinto the name space for codecs asspecified in RFC6381, Section 3.3, shallbe used.@indexRangeOspecifies the byte range that containsthe Segment Index in all MediaSegments of the Representation.The byte range shall be expressed andformatted as a byte-range-spec asdefined in RFC 2616, Clause 14.35.1. Itis restricted to a single expressionidentifying a contiguous range of bytes.@indexRangeExactOwhen set to ‘true’ specifies that for allSegments in the Representation, thedata outside the prefix defined by@indexRange contains the dataneeded to access all access units of allmedia streams syntactically andsemantically.This attribute shall not be present if@indexRange is absent.RepresentationIndex0 . . . 1specifies the URL including a possiblebyte range for the Representation IndexSegment.For the type definition refer to Table 14.Data location from SegmentInfo elementAdditional tag (optional)-NOT YET EXISTING ONES- PROPOSED NEW ATTRIBUTES:@automaticSwitchingOwhen set to ‘true’, indicates that therepresentation with the highestdecodable quality is the advantageousrepresentation not to be changed overtime. ‘’@robustLayerDecodingOThis parameter indicates that the acertain representation may not includeall dependent representations at anytime. This is, for example, to signal thatSVC media content arrives at the clientpotentially at lesser quality thanrequested/expected by the client@contentCharacteristicOspecifies the characteristics of thecontent so that different mappingbetween video rate and quality such asa rate distortion relation. Such a metricmay indicate the general characteristicsor bitrate encoding demands for acertain type of content such as Soccer,News, Action Movie, Music, e.g. as‘high’, ‘medium’, ‘low’ bitrate demands.In effect, this parameter could enable asimple video quality estimation furtherdepending on bitrate, resolution andframerate. @qualityranking may beincluded is this parameter

That is, the MPD46ofFIG. 3could have the parameters @bandwidth, @minBufferTime and, optionally, @qualityRanking for each available version (representation).

As seen above, it would even be possible that the MPD46merely comprises the first two of these parameters per version, namely @bandwidth and @minBufferTim.

An example of a MPD is shown in Listing 1 below. The example may correspond to a specific profile of the DASH standard [3] as identified, for example, by the profile attribute. The media presentation time is specified in 3256 seconds, the minimum buffer time in 1.2 seconds. The URLs (Uniform Resource Locator) of the segments of two representations are given where one representation necessitates 64 KB or 32 KB bandwidth and where the URL of the segments are created by concatenating one of the two alternative BaseURLs and the SegmentURLs included in the respective SegmentList elements of each representation. The duration of the segments is given by the duration attribute in the SegmentList element.

Listing 1 Example for a Media Packet Description (MPD) for Video Segments with Two Different Representations

Further, the implementation of the embodiment ofFIG. 3outlined in more detail below could be embedded within an LTE system. That is, the base station32or base stations32and38and the radio resource manager30could be part of an LTE system.

For LTE, different improvements have been introduced. Moving to Orthogonal Frequency-Division Multiple Access (OFDMA) in combination with Multiple-Input Multiple-Output (MIMO) enhancements and migration from circuit-switch to packet-switch networks has resulted in a mobile network that achieves peak throughputs up to 150/300 Mbps for LTE Rel. 8 with 2×2/4×4 MIMO. One of LTE's key achievements is the fulfillment of the ITU-R [15] latency requirements with a delay below 50 ms on the control plane and below 5 ms on the user plane, essential for a low end-to-end delay.

LTE implements fast retransmission mechanisms: automatic repeat requests (ARQ) and hybrid ARQ (HARQ) mechanisms at physical layer (PHY) and medium access control (MAC) layers, which necessitates fast re-ordering at the receiver. Thus, additional jitter and delay may be introduced by reorder buffering resulting in performance degradation for real-time TCP services, especially if HTTP/TCP video services are not identified and run over-the-top as best-effort service. TCP performance during handover in LTE is evaluated in [12] and it is shown that special packet forwarding techniques and packet reordering are necessitated to achieve high TCP performance.

In addition, LTE introduces decentralized scheduling and multi-user radio resource management (RRM) at the base station, the evolved NodeB (eNB). The decentralized approach necessitates the design of new robust cross-layer scheduling algorithms with QoS support in order to realize end-to-end QoS for different traffic services, such as HTTP/TCP live streaming.

The RRM entity, i.e.,30, is responsible for radio resource management which includes assigning resources to UEs, i.e.,34, on a short-term time frame, also referred to as scheduling, as well as long-term resource assignment, which works on a longer time frame and depends on varies parameters, e.g. UE feedback, user service demands etc. The resources to be assigned are taken from the time, frequency, space-grid used in LTE which is based on MIMO OFDMA. The amount of resources depends on the LTE parameters bandwidth, FDD or TDD mode, and MIMO mode to be used.

When implementing the embodiment ofFIG. 3with using DASH for streaming the media content and embedding the radio resource manager30into an LTE system, the result thereof may be depicted as shown inFIG. 5. In order to ease the understanding as to how the embodiment ofFIG. 5implements the functionalities of the elements shown inFIG. 3, the reference signs ofFIG. 3have been reused inFIG. 5and the explanations and description of these elements presented above with respect toFIG. 3shall equally apply forFIG. 5. This, in turn, also means that the RRM30needs not to be physically contained within the base station32. On the other hand, some reference signs ofFIG. 2have been re-used inFIG. 5whenever corresponding reference signs were missing inFIG. 3. Accordingly, client40is shown to be communicatively connected to server42such that the data traffic runs through the HDTP Cache16such as the internet, as far as the data traffic portion beyond the base station32is concerned. Moreover, the DASH content preparation stage14is shown from which the content of the media presentation description46may originally stem.

In describing the mode of operation of the implementation example ofFIG. 5, they may be called radio resource management using DASH over LTE. As a possible representation of the versions of the media content, a VC may be used. As the implementation ofFIG. 5follows the embodiment ofFIG. 3, the functionality of the RRM30ofFIG. 5realizes a passive signaling in order to more efficiently assign the radio resource to the clients.

In particular, the DASH client40issues a HTTP request for a video segment, server42. The RRM unit30inspects the MPD46requested by the particular user or client40using deep packet inspection50. Depending on the @bandwidth and @minBufferTime tag defined within the MPD46, the scheduler and long-term RRM30realizes the requested bandwidth for the given @minBufferTime. If the LTE's PHY data pipe, however, does not support the requested bandwidth, the RRM30automatically tries to assure the next lower bandwidth specified for the AVC video segment of the media content within the MPD46or ‘sidx’-Box and MPD. The DASH client40adjusts its HTTP get requests52according to the data rate restriction of the LTE's RRM30, e.g. by sending a HTTP get52to a service with lower rate requirements as listed in the MPD46.

This assures:1. Guaranteed service delivery of the HTTP video stream2. Prevents from over provisioning resources to a given user which would try to get as many resources as possible3. Hence 2, allows to save resources for other users within the LTE cell for a given time-frequency-space grid. This reduces the variance in IP throughput and thus allows a smooth service delivery of various traffic mixes to multiple users.4. TCP will optimally adapt to the data rate assigned by the LTE system

Since radio resources in cellular systems are shared among all users attached to the same eNB, the amount of resources assigned to one user can have an impact of how many resources are available for other users. Thus, the RRM30can choose to reduce the amount of resources for one user, even if this user has very good channel conditions, in favor of supporting other users. Taking into account bitrate and content characteristics (type of content e.g. movie, news, sports) or @qualityRanking, an overall video quality optimization over all users in the cell can be carried out.

Usage of trick modes (e.g. fast forward, fast rewind, jump) can be identified by RRM30by sequence of chunks requested by the client40. After trick mode usage, the client has to perform new rebuffering for @minBufferTime/new buffering detection by DPI. DPI stands for Deep Packet Inspection. This implies that the base station scheduler looks into the content of the IP packets and forms its decisions based on its inspections. Traditionally, the RRM operates on the MAC layer and does not look into the IP layer, as proposed by the ISO-OSI model.

With respect to the just-described implementation of the embodiment ofFIG. 3by the details described with respect toFIG. 5, it is noted that the various aspects in whichFIG. 5concretizes the embodiment ofFIG. 3may be transferred on toFIG. 3individually. This is true, for example, for the use of the TCP protocol for the data traffic, the use of the LTE system for defining the respective functionality of manager30, base station32and user entity34and the DASH streaming framework defining, at least partially the content of the MPD46and the functionality of server42and client40.

In accordance with the embodiments ofFIGS. 3 to 5, the video resource manager30directly dictated the rate allocation to the individual user entities and their clients40, respectively, as illustrated inFIG. 5at the “R” based on an evaluation of the media presentation description within the data traffic from the server42to the client40and assigning the communication resources of the base station32to the user entities accordingly. In accordance with the embodiments described below, this functionality of the resource manager30is optional.

FIG. 6shows a radio resource manager in accordance with a further embodiment of the present invention. As just said, with respect to the functionality and interconnection of the elements commonly shown inFIGS. 3 and 6, the description presented above with respect toFIG. 3remains the same. That is, the radio resource manager30assigns the communication resources of base station32to the user entities34in the way as described above, except for the dependency of this assignment on the media presentation description46being optional. Further, in accordance with the embodiment ofFIG. 6, the radio resource manager30is arranged such that the data traffic between client40and server42runs via the radio resource manager30so that the latter is able to influence this data traffic as described below.

In particular, in accordance with the embodiment ofFIG. 6, the radio resource manager30is additionally, i.e., in addition to the functionality described above with respect toFIG. 3, configured to inspect the media presentation description46describing the versions of the media content44of differing bandwidths, within the data traffic from the server42to client40operating at the user entity34, as well as a media request60from the client40to the server42, the media request60requesting a wanted version of the media content44.

Based on both inspections, resource manager30decides, depending on information describing the current resource situation at least with respect to the user entity34which sent the request60, and the media presentation description addressed to the user entity34: 1) to forward the media request60to the server42(unmodified), or, alternatively, 2) to cause that the media request60does not lead to the wanted version of the media content44being sent to the client40. For example, the resource manager30could perform the causing via 2a) modifying the media request60to the extent that the modified media request requests a version of the media content44of less bandwidth or 2b) intercepting the media request44and emulating or instructing the server42to send back a non-availability response from the server42to the user entity34or client40. Alternatively, a response on low bandwidth may be performed by RRM30, or any other feedback may be caused to be performed by the server so as to instruct the client to change its request accordingly.

This means the following. As described above with respect toFIG. 3, the radio resource manager30has access to the current resource situation information. In particular, the radio resource manager30has access to this current resource situation information not only with respect to user entity34, but for all user entities. Based on this information, the radio resource manager30knows about the current strain put onto the communication resources of base station32and knows about the communication resources available for the user entity34. Further, the radio resource manager30has access to the media presentation description46and inspecting the same, the radio resource manager30knows about alternative versions of the media content44which client40on user entity34seeks to download.

Based on the overall information, i.e., the current resource situation information and the media presentation description46, the radio resource manager30is able to decide as to whether the current load which the base station32faces, is low enough in order to justify to just forward the media request60to server42in an unmodified version. However, if the radio resource manager30determines, from the current resource situation information and the media presentation description, that part of the bandwidth necessitated for the currently requested version of media content44should not be transferred from the other user entities, because for example, the remaining bandwidth is not even sufficient to provide all these other user entities' clients with the lowest bandwidth version of their requested media content, the radio resource manager30decides to modify the media request60to the extent that the modified media request requests a lower bandwidth version. Accordingly, the server42will answer to this modified request by sending the lower bandwidth version to client40which is able to handle the case that the answer to its request is actually the answer to a request for a lower bandwidth version. For example, the lower bandwidth version differs from the originally wanted version of the media content44merely by the omission of certain media stream parts, the omission of which does not disturb the media decoder at the user entity34responsible for reproducing the media content. That is, the lower bandwidth version could be a lower information level of a scalable media content, or the lower bandwidth version be another media file, which is, however, coded using the same coding scheme.

Instead of modifying the media request60, it could be possible that the server42intercepts the media request60and emulates or instructs the server to send back a non-availability response from the server42to the client40. In both cases, client40will receive an answer from the server42according to which the wanted version is not available at the server although indicated in the media presentation description46. Although client40is free to react to this answer in any manner, one reasonable way of reaction would involve the client40newly sending another request to server42with a new request, however, requesting a lower bandwidth version of the media content44from server42, thereby effectively resulting in the same situation as resulting from the above-mentioned modification of the media request, namely the server42sending back to client40the lower bandwidth version.

Thus, a first step which could be involved in the radio resource manager's decision among the above-identified three decision options 1) to 2b) could be to check as to whether there is any lower bandwidth version of the media content44available or not. This check is performed based on the media presentation description46. A second step could involve checking the current resource situation information, as to whether any of options 2a) or 2b) is advisable or not.

A further extension or abstraction of the embodiment ofFIG. 6is described in the following with respect toFIG. 7.FIG. 7shows an embodiment of the user entity34in more detail. In accordance with the embodiment described below with respect toFIG. 7, the additional radio resource managers functionality with respect to the handling, i.e., forwarding, modification and/or interception, of media request60, is displaced from the radio resource manager30along the data traffic between server42and client40to the user entities domain34and, in particular, somewhere between a user entities transmission stage70and client40. It is to be understood, however, that this is also merely an example and that this functionality could also be assumed by another entity, positioned elsewhere.

In particular,FIG. 7shows the user entity34as comprising one or several antennas72, a transceiver stage70, a resource manager74, the client40, a media reproducer76and hardware for actually presenting the media to the user including, for example, a display78and one or several speakers80. All these elements are serially connected to each other in the order of their mentioning. The transmission stage70is responsible for performing the communication with the base station32so that the respective data path is transparent for the subsequent or higher layer applications such as those represented by client40. The transceiver stage70performs, for example, the (de)multiplexing such as OFDM (de)multiplexing, time division (de)multiplexing, reception quality feedback to the base station32, channel estimation and so forth. Moreover, transceiver stage70is able to send requests to base station32requesting an increase of bandwidth to be assigned to the respective user entity34with sending such requests being, for example, triggered by any of the subsequent modules such as client40. The transceiver stage70may be implemented in hardware or a combination of hardware, programmable hardware and/or software or any combination thereof.

The resource manager74is connected between the transceiver stage70and client40and is, accordingly, able to perform the above-explained radio resource manager's functionality with respect to the modification, forwarding and/or interception of media requests from the client40to server42via the wireless interface represented by transceiver stage70and antenna72, respectively. That is, resource manager74has access to current resource situation information via transceiver stage70. In particular, transceiver stage70is able to inform the resource manager74about a currently available transmission rate resulting from the current assignment of communication resources to the user entities by radio resource manager30(seeFIG. 6). Further, resource manager74is able to inspect the media presentation description46within the data traffic from the server42to client40. By inspecting the media request60from client40to server42, the resource manager74is, thus, able to perform the same decision as described above with respect toFIG. 6, namely the decision among the above-discussed decision options of forwarding the media request, or alternatively, modifying the media request or intercepting the media request with emulating or instructing the server42to send back a non-availability response. Naturally, resource manager74has merely access to a proper subset of the current resource situation information compared to radio resource manager30. However, nevertheless, resource manager74may avoid the client40requesting versions of media content44which, when considering the resource situation at the base station32at full, is not fair with regard to the other user's server base station32or may not be frequently stream-able by the client40.

With regard to the embodiments ofFIGS. 6 and 7, it should be noted that the resource manager30and74, respectively, may be configured to merely switch between options 1) and 2) or 1) and 3). Moreover, with regard to the resource manager74, it is noted that same may be configured to exploit, as a part of the current resource situation information, long term communication resource guarantees sent by radio resource manager30to user entity34.

Thus,FIGS. 6 and 7reveal a resource manager configured to inspect a media presentation description46describing versions of a media content44of differing bandwidths, within a data traffic from a server42to a client40operating at a user entity34; inspect a media request60from the client40to the server42, requesting a wanted version of the media content44; and decide, depending on a current resource situation information and the media presentation description46, to (1) forward the media request60to the server, or, alternatively, to (2) modify the media request60to the extent that the modified media request requests a version of the media content44of less bandwidth, or to intercept the media request60and emulate, or instruct the server42to send back, a non-availability response from the server42to the client40.

Similar to the embodiment described above with respect toFIGS. 3 to 5, in the following possible implementations of the embodiments ofFIGS. 6 and 7are described in the following. That is, these possible implementations assume the wireless communication system to be an LTE system and the streaming of the media content uses DASH. In the same manner asFIG. 5in relation toFIG. 3,FIG. 8reuses the previously used reference signs and accordingly the description of the functionality of the elements ofFIGS. 6 and 7shall equally apply to the elements shown inFIG. 8with the same reference signs.

In combination with DASH, the LTE RRM30can inspect the MPD46requested by all attached UEs34. If a given UE has a good radio channel and issues a high bandwidth request60, the LTE RRM30can send a status code trigger, a so-called status code injections, such that the HTTP DASH server42transmits a W3C HTTP status code80to indicate that this bandwidth is not available. Possible W3C HTTP status codes are listed below. Thus, the LTE RRM30can force a UE34to request a lower data rate without direct signaling to the UE34. This saves resources used for signaling which can be used for data instead, e.g. these resources can be scheduled to other Ues34. The UE's TCP/IP service automatically adapts to the assigned rate by the eNB RRM algorithms, which may be taken from the MPD @bandwidth tag.

The eNB RRM unit30inspects the MPD46requested by a UE34. In addition, it may take information from the mobility management entity (MME) not shown inFIG. 8. Depending on the user profile, e.g. moving speed, handover statistics, and requested MPD, the RRM entity30can enforce a higher or lower video quality by indirect signaling80through W3C HTTP status codes (see, for example, http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html).

In the above description ofFIG. 8, it was assumed that the versions of the media content44available on server42are available separately, i.e., in non-scalable versions at, however, different information content However, the above description ofFIG. 8is easily transferable to the case where the available different bandwidth versions of the media content44are available in the form of one media stream which, however, is coded in a scalable manner such as an SVC or MVC stream. In this case, the mode of operation of the radio resource manager30ofFIG. 8may be described as follows.

The LTE RRM entity30inspects the MPD46requested by the particular user using deep packet inspection50. Depending on the available radio resources, the LTE scheduler30evaluates the bandwidth amount requested by a given user. If the requested bandwidth exceeds the available bandwidth for a given SVC or MVC layer, the LTE RRM entity30can trigger the HTTP DASH server42to send a W3C HTTP status code to that user40. The SVC/MVC decoder70within the DASH client40receives the error status code and automatically requests a lower SVC or MVC layer which necessitates less bandwidth and thus saves radio resources on the LTE system.

The radio resources can be limited due to bad channel quality of a given user or due to the amount of other users requesting resources. The LTE RRM30can force users with good channel quality to sacrifices resources which can then be assigned to users suffering under a worse channel quality.

Depending on priority policy within the LTE RRM30, the RRM30can use the MPD46to assure service delivery of the lowest SVC/MVC layer, the base layer before allowing HTTP requests of higher SVC/MVC layers through triggering W3C HTTP status codes80.

The HTTP DASH server42may transmit one of the following W3C HTTP status codes:404 Not Found466 Streaming Rate Exceeded (tbs. in RFC)503 Service Unavailable509 Bandwidth Limit Exceeded

Before stepping forward to describe the next embodiment of the present application, it should be noted that the general structure of a user entity34as shown inFIG. 7is, generally, also applicable to all the other embodiments when removing the resource manager74. The media reproducer76may be a media decoder able to decode the media content44received from server42. Client40and media reproducer76may be coupled to each other and communicate to each other. The media reproducer may even be partially integrated within the client40.

According to the embodiment ofFIGS. 3 to 5, the communication resources assigned to the individual user entities and, in particular, the assignment itself was adapted depending on a result of the inspection of the media presentation description. In accordance with the subsequent embodiments ofFIGS. 6 to 8, the part of the data traffic between client and server, which pertains the media requests sent from the client to the server, has been influenced in order to achieve a more efficient exploitation of the base stations, communication resources or to obtain a more fair distribution of the base stations communication resources to the user entities. In accordance with both embodiments, radio resource manager30is able to also take LTE closed-loop feedback on the physical layer into account in accordance with the subsequently explained implementation example. That is, the following implementation possibility is meant to denote a more detailed explanation of the implementation examples ofFIGS. 5 and 8. That is, in accordance with the present implementation possibility, the radio resource management (RRM) scheduler30takes the LTE closed-loop feedback from the physical layer of LTE into account for the decision at the LTE EMB32to decide which video representation or version of the media content44is best suited for the DASH client. Again, in accordance with the embodiment ofFIG. 3and the implementation ofFIG. 5, the resource manager30seeks to obtain the download of the most suitable representation or version indirectly by accordingly assigning the communication resources to the respective clients40for which the respective representation is dedicated. While in accordance with the embodiment ofFIG. 6and the implementation ofFIG. 8, the radio resource manager30seeks to reach the download of the best suitable representation by the client by appropriately influencing the clients media requests as described above.

The RRM unit30takes, for example, the LTE closed-loop feedback into account when selecting between different representations of AVC segments of media content44, (H.264/)SVC layers or when deciding between 2D or 3D video delivery in case of (H.264/)MVC. The LTE eNB RRM30may inspect the MPD46to adjust RRM parameters to the parameters specified for the particular video segments in case ofFIGS. 3 and 5and to influence the HTTP set requests in case ofFIGS. 6 and 8.

The UE40may signal quality metrics of the radio channel, so-called channel quality feedback (CQI), as well as buffer levels of video buffer, see Table 3, to the eNBs RRM entity30. The feedback information may be reduced by sending a peak to average ratio (PAR), e.g. a peak to average rate ratio (PARR) indicator on a periodic or aperiodic time basis. With this information, the eNBs RRM entity30can perform multi-user scheduling with buffer awareness for HTTP streaming services.

The channel quality metric of the physical layer (PHY) data to be used for calculation of the PAR and/or PARR may involve one or any combination of the following parameters as defined within the LTE standard:CQI: Channel Quality IndicationRI: Rank IndicatorPHY layer data ratePHY layer delay and jitterRSRP: Reference Signal Received PowerRSSI: Received Signal Strength IndicatorRSRQ: Reference Signal Receive Quality.

RSRQ=N×RSRPRSSI
where N is the number of resource blocks across which the RSSI value was measured.

As become clear from the above-outlined implementation detail, the radio resource managers30ofFIGS. 3 and 6could employ closed-loop feedback on the physical layer as sent out by the client's user entities to the base station, respectively. That means, the system on the sender side, can rely on the cross-layer information in order to improve the video transport, while the receiver side does not need any cross-layer interfaces. Furthermore, the RRM can estimate based on the channel, how much more bandwidth could be assigned to one or more clients in order to improve its video quality.

For example, the RRM30ofFIGS. 3 and 6, could be configured to determine an average bandwidth assigned to the user entities and predict from the determined average bandwidth as to which version of a media content44out of the media presentation description46, is currently downloaded by the respective clients such as44. This forms a simple way to find out the client's state. For each client, RRM30merely has to identify the average bandwidth the respective client40is receiving, and to predict from that which media rate it may have selected.

Moreover, as outlined above, it could be possible that the radio resource manager30tries to derive media buffering state information, i.e., information indicating a kind of buffering state of the client operating at the respective user entity. In other words, the radio resource manager30could exploit the information concerning the user entities34reception condition in order to ascertain as to whether the respective user entity is actually able to effectively correctly receive the assigned bandwidth. Using this information, the radio resource manager30is able to emulate the buffering state of the clients operating at the user entities by taking the minimum bandwidth information into account which is accessible for the radio resource manager30from the media presentation description46as described above. By this measure, the radio resource manager30is able to emulate or simulate the buffering states of the clients40running on the user entities34and to deduce client's behavior and client's priorities therefrom. For example, clients40for which the simulation reveals that the buffer runs out of media data, may be assigned a higher priority than clients40for which the simulation reveals that the buffer is full.

Naturally, the above-described possibility of simulating the buffering state or deriving media buffering state information from data traffic between the client40and the respective server is quite computationally complex and the accuracy obtained may be low.

Thus, the embodiment ofFIG. 3may be extended in a way according to which the radio resource manager30could also be configured to assign the communication resources of base station32to the user entities not only depending on the media presentation description46(in addition to the current resource situation information), but also depending on media buffering state information derived from channel quality feedback from the respective user entities at which the respective client or clients40operate. In particular, the derived media buffering state information may have been derived by the above-described simulation simulating a buffer of the respective user entities client40which is filled using the estimated effective bit rate of the respective user entity34and is entered at the presentation bandwidth indicated in the media presentation description46.

Of course, the same may be said with regard to the radio resource manager30ofFIG. 6. That is, the simulation result may be used by radio resource manager30in order to decide on the influence of the media requests of the user entities clients40.

Further, also the embodiment ofFIG. 7may be extended in that sense. That is, the resource manager74ofFIG. 7may use the current resource situation information in order to simulate the client's media buffer state and to act accordingly in order to protect, as part of the wireless communication community, the base stations communication resources against two greedy clients40.

However, as just-described, the “simulation” of the client's buffering state may be subject of a high degree of uncertainty and, accordingly, embodiments ofFIGS. 3 and 6may be amended in a way so that the radio resource manager30does not have to derive or simulate the buffering state of the user entities client but, instead, the radio resource manager30exploits explicit media buffering state information within a data traffic from the client40. Based on the media presentation description46and the media buffering state information within the data traffic from the client40to server42, the radio resource manager30could perform the communication resource assignment more accurately because of a more accurate buffering state estimation. In the media buffering state information within the data traffic from the client40, the latter would explicitly indicate the current media buffering state, i.e. the current media buffer's fill level. A concrete implementation possibility is described in more detail below.

In accordance with an alternative embodiment, however, the radio resource manager30ofFIG. 3could alternatively perform the assignment of the communication resources of the base station32to the user entities depending on the media buffering state information within the data traffic from the client40, but without dependency on the media presentation description46. Merely surveying the media buffering states of several user entities clients40would enable the radio resource manager30to obtain a more fair distribution of the available base stations communication resources to the user entities.

Thus,FIG. 3also relates to a radio resource manager30configured to assign communication resources of a base station32to user entities34depending on media buffering state information of a client operating at one of the user entities. The assignment of the communication resources to the user entities could be further performed based on one or more of the above mentioned possibilities such as the number of user entities34to which the communication resources of the base station (32) have to be assigned at an appropriate ratio, the a sort of communication data to be exchanged between the user entities and the base station, and so forth. Further, in assigning the communication resources to the user entities, the above mentioned setting could be adjusted depending on the media buffering state information, namely one or more of subcarriers, time slots, and a spatial coverage of the base stations cell. As just-described, the media buffering state information could be extracted from an explicit signalization within a data traffic from the client40to the server42, or the media buffering state information could be derived by simulating a user entity's buffering state based on channel quality feedback from the user entity34to the base station32.

The latter possibility also pertains the embodiments ofFIGS. 6 and 7. Instead of using the current resource situation information and the media presentation description46, the radio resource manager30and the resource manager74ofFIGS. 6 and 8, respectively, could be configured to perform the decision with respect to the way of handling the media request60depending on the media buffering state information within the data traffic from the client40.

Thus, the above embodiments also reveal a resource manager configured to inspect a media presentation description46describing versions of a media content44of differing bandwidths, within a data traffic from a server42to a client40operating at a user entity34; inspect a media request60from the client40to the server42, requesting a wanted version of the media content44; receive media buffering state information from the client40; and decide, depending on the media buffering state information and the media presentation description46, to (1) forward the media request60to the server, or, alternatively, to (2) modify the media request60to the extent that the modified media request requests a version of the media content44of less bandwidth, or to intercept the media request60and emulate, or instruct the server42to send back, a non-availability response from the server42to the client40.

A possible implementation for the embodiment as just-described as an alternative description ofFIGS. 3, 6 and 7is described in the following. This more detailed implementation could be entitled “DASH over LTE with closed-loop feedback over the top (OTT)”. According to this implementation possibility, the client's BufferLevel is more precisely tracked at DPI-Scheduler30of the LTE system using direct client feedback over the top, e.g. quality metric such as BufferLevel as defined in Table 3.

TABLE 3Quality Metrics for Buffer LevelsKeyTypeDescriptionBufferLevelListList of buffer occupancy levelmeasurements during playout atnormal speed.EntryObjectOne buffer level measurement.TRealTime of the measurement of theTimebuffer level.LevelIntegerLevel of the buffer in milli-seconds. Indicates the playoutduration for which media dataof all active media componentsis available starting from thecurrent playout time.

A possible resulting implementation is shown inFIG. 9. By comparing the implementation ofFIG. 9with the implementation possibility ofFIG. 5, it is clear that the implementation ofFIG. 5has been extended by the LTE feedback90from the user entity34to the RRM30wherein the latter, i.e., the RRM30, uses the LTE feedback, i.e., the channel quality feedback from the user entity34, in order to perform a better communication resource rate allocation R.

In the following, with regard to the above embodiments, some possible implementation details with respect to the embodiment client40is described. As indicated above, the client's behavior is free to be set by the respective client issuer and, accordingly, the above embodiments did not put very much stain onto the description of the client's behavior. On the other hand, in order to increase a thorough understanding of the embodiments outlined above, a possible client behavior is described hereinafter by assuming that the client is a DASH client.

DASH, as defined in [ISO/IEC 23009-1], is a client-driven adaptation technology, but it does not specify client behavior and lets complete freedom for different implementations. However, the MPD and QM reported by the clients contain some important information from which the client behavior can be predicted. This important information refers to the signaling in:@minBufferTime@bandwidthimplicit allocated LTE client rate, measurable by client as TCP throughput, if enough data is availableclient adapts to TCP throughput depending on intended play-out delay/potential outagesQM, reported by the clientBitstream switching flag

The goal of DASH client is to play continuously the streamed content at the highest quality it can support based on its equipment characteristics. In order to play continuously the buffer at the clients shall not empty at any time. The @minBufferTime in the MPD promises to clients that if such an amount of data is stored at their buffers at the beginning of the session, they can play a video version signaled to have @bandwidth if they download at a rate at least such high as the value indicated in @bandwidth. Therefore, it is expected that clients pre-buffer at least so much data before starting play-out of the video and switch to a different version of the video with a different @bandwidth when variations in their buffer fullness happen based on its magnitude relative to @minBufferTime. Since clients' buffer fullness is unknown to the Base Station and estimating it may be difficult or inaccurate e.g. when trick modes are used QM reports from the users (especially the QM mentioned above) may be a useful tool for predicting user behavior.

Furthermore, a DASH client is logically divided into two components as shown inFIG. 10: the DASH Access Client40aand MPEG Media Engine40b, as shown inFIG. 7.DASH Access Client40a: This entity is responsible for parsing the MPD46, performing the scheduling algorithm and passing the media64to the MPEG Media Engine40bin format92MPEG Media Engine40b: This entity is responsible for processing the media data92, i.e., decoding, reconstructing etc.

Referring to the above description ofFIG. 7, there are two possible options for implementing an enhanced DASH client which takes advantage of any of the above described favorable functionalities of the user entity and/or client. These possibilities are:To have a cross-layer DASH Access client: The cross-layer access client takes measurements from the physical layer and possibly receives additional signaling from the LTE network. Using this additional intelligence better estimation of the channel and an enhanced adaptation scheduling can be performed.However typically already implemented DASH clients are foreseen, where adaptation happens in higher layers by monitoring e.g. client buffer levels or needed time for download in a given amount of data, as for instance for implementation of DASH clients in browser etc. In this case, one possibility is to have and external “media manager” component (seeFIGS. 8 and 9) that takes care of the adaptation. Similar to the one described before, but the DASH client would not be aware of this. In order to avoid this “duplicated” DASH Access Client (that the DASH Access client also performs adaptation) additional signaling is necessitated at the MPD level: a new attribute may be added, e.g. @automaticSwitching, which would indicate the DASH Access client that adaptation is performed out of the DASH client, i.e. in the receiver device, by the “resource manager”74. The @automaticSwitching contained in an MPD indicates to the client that the server or any device in the middle may adjust the video rate conforming to the video's profile and level according to the selected and requested representation, thus the client shall not do any media rate adaptation.

The second case, i.e. with the “resource manager” is depicted inFIG. 11. As can be seen fromFIG. 11, the resource manager74uses data100at a lower OSI layer compared to the client/server data traffic in order to act as the resource manager as described above.

In particular, the resource manager74could perform either the adaptation and requests of media, or could also perform DPI or modify the requests of the users, etc. Furthermore, the “media manager” could exchange some additional signaling messages with the RRM about physical layer information and resource allocation in order to perform a more intelligent adaptation than the one it could be done at a normal DASH Client, where only information of higher layers is used.

Regarding the embodiment ofFIGS. 6 and 7and the corresponding implementations such asFIG. 8, it should be noted that the embodiments depicted in these figures may be implemented in an alternative way to result in an alternative embodiment according to which the media request influence is replaced by a media description presentation influence in order to yield a better resource management. However, even a combination of the above-described functionality with respect to these figures and the below-outlined functionality may be used.

In particular, in accordance with the alternative embodiment ofFIG. 6as described, the radio resource manager30is configured to inspect a media presentation description request from the client operating at the user entity34to server42, the media presentation description request requesting the media presentation description46from the server42. The resource manager30then inspects the media presentation description46within the data traffic from the server42to client40and decides, based on the current resource situation information and the media presentation description46, which option of the latter should be used: 1) forwarding the media presentation description46to the client40as an answer to the media presentation description request, i.e., leaving the media presentation description46unmodified, or 2) intercepting the media presentation description46, reducing the media presentation description46so as to describe merely a proper subset of the versions of the media content44of differing bandwidths and send the reduced media presentation description46to the client40as the answer to the media presentation description request. Again, although the radio resource manager30does not directly instruct the client40to change the requested version of the media content to a lower bandwidth version thereof, it is very likely that client40will change further media requests for media content44so as to refer to such a lower bandwidth version due to the reduction of the media presentation description46.

Again, the above-described functionality is valid not only for the radio resource manager30resulting beyond the base station from the user entities view but also for the resource manager74ofFIG. 7resulting within the user entity itself. All the above possible implementation details mentioned above with respect toFIG. 7are also applicable to the above-outlined alternative embodiment ofFIGS. 6 and 7, respectively.

Thus,FIGS. 6 and 7also reveal a resource manager configured to inspect a media presentation description request from a client40operating at a user entity34to a server42, the media presentation description request requesting a media presentation description46from the server42, the media presentation description46describing versions of a media content44of differing bandwidths; inspect the media presentation description46within a data traffic from the server42to the client40; decide, based on a current resource situation information and the media presentation description46, to (1) forward the media presentation description46to the client40as an answer to the media presentation description request, or to (2) intercept the media presentation description46and modify same.

For example, the interception and modification could involve the resource manager reducing the media presentation description46so as to describe merely a proper subset of the versions of the media content44of differing bandwidths, and sending the reduced media presentation description to the client40as the answer to the media presentation description request. It could be also possible to add information to the MPD46to be used as feedback to the client40: In order to instruct the client40to, e.g., sent the quality metrics such as explicit buffer state information mentioned below, to the RRM30instead of to the server32, or to indicate a protocol change, namely from unicast to multicast as also described in more detail below; or to let the client40know that a device, namely the resource manager itself, in the middle may do adjustments of the media44requested by the client40so that the client40should not adjust the rate. Naturally, the protocol change indication may be conducted by the RRM30by performing, or causing someone else such as the server32, to perform a protocol translation corresponding to the indicated protocol change.

As in the case of influencing the media requests, the resource manager may be configured to inspect the media presentation description46so as to identify within the media presentation description46a version of a media content44, which has a lower minimum bandwidth associated therewith as the wanted version of the media content44, wherein the radio resource manager is configured to, if such a version having a lower minimum bandwidth associated therewith is present, perform the decision dependent on the current resource situation information. The resource manager may be a radio resource manager and is further configured to perform an assignment of communication resources of a base station to user entities to which the user entity at which the client operates, belongs. However, the resource manager may alternatively be arranged within the user entity between a transceiver stage70thereof, and the client40, wherein the resource manager is configured to obtain the current resource situation information from the transceiver stage70. Further, the resource manager may be configured to simulate a user entity's buffering state based on channel quality feedback from the user entity to the base station, which is comprised by the current resource situation information, and to perform the decision depending on the user entity's buffering state.

Next, possible implementation details regarding the above-outlined embodiments are described with these details concerning the possibility to realize the streaming of the media data in the form of a DASH push service.

DASH services over LTE can be enhanced by so-called push services. SeeFIG. 12, for example. There are two possible approaches:1. HTTP Server PushThe DASH client46connects to HTTP server42which, in turn, performs TCP/service handshake and tunnel setupThe server42then pushes video data to the DASH client402. LTE Proxy PushThe DASH client40connects to LTE Proxy server within LTE eNB which performs TCP/service handshake and tunnel setupThe LTE RRM entity30uses HTTP get to retrieve the video data representation from the HTTP server42The LTE RRM30pushes video data to the DASH client12

Push information may be specified within the MPD, which refers to the push representation. In case of SVC or MVC this information can include the layers to be pushed to the DASH client. Here, the MPD46informs the eNB RRM30about a potential rate switch, so that usage of radio resources can be optimized also for other users. E.g., in case of the LTE Proxy Push, the LTE RRM30can decide to push a service with a lower quality and lower rate requirement to save resources for other users.

In other words, the base station may serve as a site for perform proxy push processing in all of the above embodiments. To be more precise, the radio resource manager may serve as such a site.

A further alternative description of the embodiment ofFIG. 6is presented, wherein the following alternative description shall be understood such that the functionality of the radio resource manager described below may replace the above-described spatial functionality of the radio resource manager30according to which same influences the data traffic between client and server or may represent an additional functionality of the radio resource manager30.

In any case, in accordance with the embodiment described next, the radio resource manager30ofFIG. 6is, besides assigning the communication resources of base station32to the user entities34, additionally configured to survey the data traffic between the clients40operating at the several user entities34and one or several servers42in order to check as to whether there are media presentation descriptions46within the data traffic which relate to a common media content. Depending on the check, the radio resource manager then decides to: (1) offer the clients40a multicast version of the common media content, besides unicast versions of the media content44or (2) cause a change of a protocol for clients40downloading the common media content44from a unicast protocol to a multicast protocol.

The above-described functionality may, however, also be performed within a radio resource manager which is external to, or separate from, the radio resource manager30shown inFIG. 6which is responsible for performing the assignment of the base stations communication resources to the user entities. The surveying of the data traffic between clients and servers and the check as to whether there are media presentation descriptions commonly ordered by more than one of the clients by way of respective media presentation description requests, may be performed independent on the assignment processing. The resulting advantage is readily understandable when considering that the result of the respective clients40switching from a unicast version to be received to multicast versions of the same content. The switching yields more available bit rate for other clients due to the fact that the necessitated bit rate for these clients may be collapsed to merely one streaming.

It goes without saying that the alternative mentioning of options (1) and (2) shall not be understood such that the radio resource manager in accordance with the present embodiment is actually configured to, or able to, perform both options. Rather, the radio resource manager decides, based on the result of the check, as to whether any of options 1 or 2 shall be triggered or not. To be more precise, the radio resource manager leaves the data traffic between the clients40and the servers42unchanged in case there are no media presentation descriptions within the data traffic from the one or several servers to a different one of the clients which relate to a common media content44. In this case, neither option 1 nor option 2 is performed by the radio resource manger. To be even more precise, the radio resource manager leaves the respective data traffic unchanged in case a manipulation of any of the data traffic does not promise very much bit rate savings. However, imagine the case where several users decide to switch to a live streaming such as a soccer game or any other live news, respectively. In this case, it would be favorable to be able to switch from a unicast streaming to all these clients, to a multicast streaming. In accordance with the first option, the radio resource manager, when realizing the overlapping media presentation description within the data traffic, is configured to manipulate media presentation descriptions to clients40which requested a media presentation description regarding the media live streaming by way of a respective media presentation description request. The modification changes the original media presentation description to the extent that besides, or instead of, the unicast version of the media content44being available, only the multicast version is available. Accordingly, at least these newly joining clients40would consider, or would have to consider, the multicast version. In accordance with the second alternative, the radio resource manager30would be configured to change, in case of realizing overlapping media presentation descriptions within the data traffic, for example, respective media requests from the clients requesting the common media content44so as to be changed from requesting a unicast version to a multicast version. Alternative modifications are also feasible.

Thus,FIG. 6does also reveal a radio resource manager configured to survey data traffic between clients40operating at user entities34, and one or several servers32, and check as to whether there are media presentation descriptions within the data traffic from the one or several servers32to different ones of the clients40, which relate to a common media content44, wherein the radio resource manager is configured to, depending on the check, offer to the clients40a multicast version of the common media content44, besides unicast versions of the media content44; or the radio resource manager is configured to, depending on the check, cause a change of a protocol for clients40downloading the common media content from a unicast protocol to a multicast protocol. This radio resource manager could also be responsible for the assignment of communication resources of the base station32to the user entities34. The just-outlined embodiment is combinable with any of the other embodiments.

A more concrete implementation of the above-outlined embodiment is described below. According to this concrete implementation, a DASH unicast and broadcast/multicast switchover is realized. As described above, such a switch over is advantageous for live services to reduce the cell usage. In this regard, it is noted that the just-mentioned embodiment is not only usable when considering users associated with, or locked to, one or several common base stations32. Rather, the wireless network in general, including all of its cells and the backbone interconnecting the base station itself, would inadvertently be strained by an excessively high number of clients requesting a media content streaming using a unicast protocol which streaming could, alternatively, also be performed by a multicast protocol.

Accordingly, a base station/LTE network delivers live services to unicast user. If number of user request for service increases, the service should be switched over to a multicast/broadcast service in order to reduce data rate demands on the backbone and the radio link of the mobile network infrastructure.E.g. from HTTP to FLUTE (broadcast file download protocol via UDP)

User requests data service for HTTP service. Http server return HTTP get request via FLUTE protocol.

A protocol change may be applied, based on an indication in the MPD, e.g. as an “Redundant URL” containing a link to a description of a FLUTE (FLUTE—File Delivery over Unidirectional Transport) [IETF RFC 3926] session, e.g., in the Session Description Protocol SDP [IETF RFC 4566]. A redundant URL indicates an alternative media location with alternative transmission characteristics, such as a protocol change form HTTP to FLUTE. Furthermore, the protocol change may also include a change of the source location, from a unicast to a multicast address.

It is again explicitly noted with regard toFIGS. 3 and 6and the corresponding implementation examples, that it is possible that a user entity is served by more than one base station32, currently. That is, it is possible that the user entity receives the MPD via another base station than the one for which the RRM scheduler performs RRM. The terminal needs basic IP connectivity in order to receive the MPD, which is in this case established over a wireless system, e.g. LTE, using LTE's RRM unit. So in order to receive the MPD, the UE needs to have some resources assigned by the RRM. In current LTE Rel. 8/9, a terminal is connected to a single base station (operating on a certain frequency, e.g. 2.6 GHz with 10 or 20 Mhz bandwidth) which has a unique cell identifier (Cell-ID). In this case, the UE can only get the MPD using the underlying LTE network. In a next step, multiband techniques can be used, already with existing LTE. Multiband means that, e.g. we have 1 base station operating at 800 MHz, and another one operating at 2.6 GHz. A terminal can be connected to both base stations at the same time, since each has its own cell ID. So a terminal can have more than 1 IP entry point, here in the example it has 2, and could use the one base station for retrieving the MPD and the other one for actually retrieving the data. In this case it would independently utilize both RRM units. This can also be extended to other technologies, e.g. using LTE for distributing the MPD, and Wifi for getting the data. A multiband approach like this would necessitate some kind of intelligence within the client, which decides which technology to use based on current network load, or channel quality etc.

With respect to the above description relating to the simulation of the buffer state associated with the client40, it is noted that the buffer state simulated may also be another buffer positioned elsewhere within the user entity34. For example, the buffering state simulated could actually also relate to a MAC layer buffer within the transceiver stage of the user entity. See, for example,FIG. 13, which shows a pedant of the just-mentioned MAC layer buffer within the transceiver stage70, namely buffer100. Buffer100may also be positioned within base station32. In other words,FIG. 13shows a possible implementation of a portion of the data path between client40and server32, including a possible implementation of the client40. Differing from all of the above figures,FIG. 13also shows MAC layer entities such as the MAC layer buffer100, i.e. a network buffer positioned on the other side of, i.e. beyond RRM30relative to client40. The base station's transceiver stage102corresponding to the user entity's transceiver stage70is also shown for sake of completeness. The transceiver stage70also accommodates MAC layer entities such as, inter alias, another MAC layer buffer which is, however, not shown inFIG. 13. By the way, the RRM30ofFIG. 3could also monitor the latter buffer with respect to its amount of media content for the client40cached, in order to simulate the buffer state if the user entity.

Further it is mentioned that, additionally or alternatively to the functionalities described above, the RM74inFIG. 7 or 13could relieve the RRM30ofFIG. 3of surveying the data traffic between server and client so as to derive the MPD. Thus, the resource manager74could be used to fully parse and inspect the media presentation description and translate it to a subset media presentation description only including the potential bit rate operation points supported by the client for the requested media service, such a particular HTTP Streaming session. That is, the translated media presentation description may represent a rudimentary description of the versions of the media content44available at the respective server, i.e. a kind of media presentation description in sense of the description above with respect toFIG. 3. As described above, merely a ranking among the information density of the individual versions may be signalized within the translated media presentation description, i.e. a very coarse measure of the quality of the respective version. Alternatively, as just-mentioned, for each version, the necessitated minimum bandwidth for presenting the respective version to the user may be signalized within the translated media presentation description for each relevant media content version, i.e. for those media content versions which are presentable to the user at the user entity in accordance with the user entity's facilities. This translated MPD may then forwarded to the radio resource manager30, e.g. on PHY/MAC layer, in order to let it use these bit rate operation points for further scheduling and radio resource allocation decisions for the particular client as well as other clients under its control. The type of a video service which allows for adaptivity, i.e. the service allows the support of different bit rates, respectively operation points, may be indicated using Quality of Service parameter signaling, such as defined in [19]. Therefore new traffic classes, such as “Adaptive Non-Conversational Video and Adaptive Video”, may be added to Table 6 to indicate the service's characteristics. These new classes could further necessitate the indication of a set of rates to be chosen from for resource allocation at the radio resource manager, i.e. the indication of the translated MPD. The signaling of a guaranteed minimum bitrate (GBR), needs to be extended to allow the signaling of the minimum rate and/or other meaningful operation points for the service. As far as the minimum bitrate is concerned, it should be noted that a translated media presentation description may indicate this minimum bitrate in terms of a bitrate measured at the high OSI data traffic level, such as the TCP level, or at some lower OSI layer level, such as in terms of minimum bitrate to be assigned by the base station or radio resource manager30. Reference is made to the above discussion of the discrepancy between the bitrate actually assigned and transmitted, and the bitrate actually effective in the media content transmission, the discrepancy resulting, for example, from packet loss and re-transmission upon NACKs or ACKs.

As just-mentioned, the transmission of a translated media presentation description derived from the actual media presentation description46by the resource manager74residing within the user entity34, could be integrated into any existing radio resource network such as LTE by introducing a new type or sort of communication data to be exchanged between the user entity, respectively, and the base station such as the above mentioned “Adaptive Non-Conversational communication”, and transmitting the translated MPD within the protocol process of the activation of this new communication data type, i.e. this dedicated bearer.FIG. 15shows this possible integration exemplarily in more detail. LTE was exemplarily used as a representative of a radio resource network here, but in principle the description ofFIG. 15is readily transferable onto other radio resource networks. In particular,FIG. 15shows consecutive steps performed in creating such an exemplary bearer, i.e. “Adaptive Non-Conversational communication”, and transmitting a translated media presentation description to the radio resource manager30. In particular,FIG. 15shows all these steps in their temporal order along time axis110by respective blocks and associated arrows outlined in more detail below, where these blocks and associated arrows are drawn in a horizontal direction, so as to extend over the respective entities involved in the respective step, namely the entities of the data traffic chain: user entity40, base station32, radio resource manager30, mobility management entity112, packet gateway114, and media server42. As already noted above, the mobility management entity112is also connected to all the base stations of the radio resource network and may even be implemented, at least partially, on the same hardware as radio resource manager30. As also already mentioned above, the mobility management entity112is responsible for managing the user's access data such as debiting the user's payment account, managing the users' profiles, which profiles in turn indicate certain user rights such as maximum bandwidth assignable to the respective user, restriction to certain communication data types/sorts and the like. Moreover, the mobility management entity112may be responsible for handling the handovers of user entities transitioning from one base station's cell to another base station's cell. The packet gateway114, in turn, assumes responsibility for interfacing the radio resource network, to which entities40,32, and112belong, to the outside, namely the internet or the like. Possible integration of the radio resource manager30and the mobility management entity112into one unit is exemplarily illustrated by a dashed line116, whereas the dotted line118indicates the possibility that radio resource manager30may be positioned within base station32.

As is derivable fromFIG. 15, it is assumed that the user entity40may have already been attached to the radio resource network and a default bearer may have already been activated so that the user entity40is able to perform minimum tasks via the radio resource network such as, for example, performing low complexity access to the internet. The step of attachment and default bearer activation is shown at116. To be more precise, step116is performed by transceiver stage70as far as the user entity's domain is concerned. Then, it is assumed that the user, or the client40at user entity34, sends the MPD request118to the media server42using, in the present example, the default bearer session. The media server42sends back the MPD in step120where the resource manager74within user entity34parses this MPD in step122in order to translate, as described above, the MPD of step120into a translated MPD. Then, a dedicated bearer activation is triggered at124such as, for example, the activation of “Adaptive Non-Conversational communication”. For example, the trigger124may have been caused by the user of, or the client40at, user entity34requesting media content which the MPD parsed at step122refers to. In response to trigger124, the resource manager74and the transceiver stage70cooperate in order to send a bearer resource allocation request in step126to base station32, which in turn is instructed thereby to forward the respective allocation request to radio resource manager30and mobility management entity112in step128, respectively. The allocation request comprises the above-mentioned translated media presentation description using, for example, the syntax described in more detail below. Thereupon, the mobility management entity112informs the packet gateway114that a respective bearer resource is to be created at step130using the Bearer Resource Command, wherein the creation itself is performed at step132. Accordingly, from step128on, the radio resource manager30knows about the content of the translated media presentation description, but the activation of the dedicated bearer has not yet been confirmed. Accordingly, mobility management entity112starts another acknowledgment routine by sending a dedicated bearer activation request in step134to the base station32, which in turn forwards same in step136to the user entity34, and in particular to transceiver stage70. Then, at step140, the transceiver stage70signals the acceptance of the dedicated bearer activation to base station32, which in turn informs in step142the radio resource manager30and the mobility management entity112accordingly. From that time on, the radio resource manager30is able to perform the above-described radio resource assignment, i.e. the scheduling, by using the translated media presentation description as signalized from resource manager74to resource manager30via steps120to128. Accordingly, the media transmission session144between client40at user entity34and media server42, may be controlled by radio resource manager30in an efficient way when considering the assignment of the radio resources to all the user entities served by base station32and radio resource network, respectively.

With respect toFIG. 15, it is noted that, generally, there are two possibilities to setup dedicated radio bearers. The first method is client driven. Here, the UE34is connected via default bearer to the internet as shown inFIG. 15. Based on a response120of a previously issued MPD request118by the client40, the user entity's RM74receives the corresponding MPD file for inspection and triggers124the dedicated radio bearer accordingly. This is done by triggering a dedicated bearer activation by issuing126a ESM bearer resource allocation request to the mobility management entity112(MME) (cp. Sect. 8.3.8 in [20]). This message126contains an information element (IE) defining the necessitated evolved packet system (EPS) quality of service information, i.e. the translated MPD.

An alternative possibility is network driven. Here, the P-GW114triggers the setup of the radio bearer which is necessitated to keep the necessitated QoS bearer during handover procedure. In both cases, ESM Activate Dedicated Bearer Request messages, (see Sect. 8.3.3 in [20]) are sent which contain EPS quality of service information, (see Sect. 9.9.4.3 in [20]) shown in the table below. This table is (compared to [20]) extended or modified to contain signaling for GBR with minimum only and alternative higher-bitrates as well as for Non-GBR with alternative bit rates, i.e. the translated MPD. In case the UE triggers the dedicated bearer as illustrated inFIG. 15, it provides the information elements such as the alternative bit rates found in the MPD. In case the network triggers the dedicated bearer, the alternative bit rates and the translated MPD, respectively, shall be provided by the corresponding P-GW in case of handover, or from the resource manager (74) after inspecting the MPD. Therefore, the P-GW needs to inform the RRM about the MPDs location or its content. In [20] other messages, i.e. Bearer Resource Modification request (Sect. 8.3.10) and Activate default EPS Bearer request (Sect. 8.3.6) contain also the EPS quality of service information message shown in Table 3 and may be used for providing the alternate bitrates mentioned before.

87654321EPS quality of service IEIoctet 1Length of EPS quality of service contentsoctet 2QCIoctet 3Maximum bit rate for uplinkoctet 4*Maximum bit rate for downlinkoctet 5*Guaranteed bit rate for uplinkoctet 6*Guaranteed bit rate for downlinkoctet 7*Maximum bit rate for uplink (extended)octet 8*Maximum bit rate for downlink (extended)octet 9*Guaranteed bit rate for uplink (extended)octet 10*Guaranteed bit rate for downlink (extended)octet 11*

One possibility is to add more octets as shown in Table 4. The rate indicated in the Guaranteed bitrates would correspond to the minimum bandwidth that has to be guaranteed, such as for the lowest quality/lowest information density region, while the alternative bitrates for downlink and uplink describe the bitrates that are available to download found in the original MPD46. The fields of alternative bit rates is present depending on the value of the QCI field. If the new QCI values defined in Table 5, for example, are used the alternative bit rates for downlink or uplink shall be present. This mechanism allows backward compatibility. If the QCI value is not understood another GBR or non-GBR QCI is selected depending on the whether the Guaranteed bit rate is present or not.

TABLE 4Extended EPS quality of service informationelement by alternative bit rates87654321EPS quality of service IEIoctet 1Length of EPS quality of service contentsoctet 2QCIoctet 3Maximum bit rate for uplinkoctet 4*Maximum bit rate for downlinkoctet 5*Guaranteed bit rate for uplinkoctet 6*Guaranteed bit rate for downlinkoctet 7*Maximum bit rate for uplink (extended)octet 8*Maximum bit rate for downlink (extended)octet 9*Guaranteed bit rate for uplink (extended)octet 10*Guaranteed bit rate for downlink (extended)octet 11*Number of additional alternative downlink ratesoctet 12*Alternative bit rate for downlink_1octet 13*. . .. . .Alternative bit rate for downlink_Noctet 12 + N*Number of additional alternative uplink ratesoctet 13 + N*Alternative bit rate for uplink_1octet 14 + N*. . .Alternative bit rate for uplink_Moctet 13 + N + M*

Another possibility would be to add an additional message to EPS quality of service information message, which will be added to the aforementioned messages where the EPS quality of service information message is used (ESM bearer resource allocation request, ESM Activate Dedicated Bearer Request, Bearer Resource Modification request and Activate default EPS Bearer request). This would allow to let the EPS quality of service message as it is. The content of the extension could be as follows in Table 5. In this case the Guaranteed bitrate values should be taken as in the EPS quality of service information message, but the QCI value would be overwritten by the extension message. The alternative bit rates would also be described in this extension message.

TABLE 5Additional message carrying the bitrate alternativesfor a EPS quality of service information element87654321EPS quality of service extension IEIoctet 1Length of EPS quality of service extension contentsoctet 2QCIoctet 3Number of additional alternative downlink ratesoctet 4*Alternative bit rate for downlink_1octet 5*. . .. . .Alternative bit rate for downlink_Noctet 4 + N*Number of additional alternative uplink ratesoctet 5 + N*Alternative bit rate for uplink_1octet 6 + N*. . .Alternative bit rate for uplink_Moctet 5 + N + M*

As shown inFIG. 15, MME112has to exchange messages with the rest of the core network, i.e. with S-GW and P-GW114to setup a bearer with a given QoS for a service. S-GW is the gateway between base station (eNB) and other EPC (Evolved Packet Core) entities, e.g. P-GW. The P-GW (also sometimes specified as PDN-GW=Packet Data Network Gateway) is the interface between EPC and Internet/backbone. So all data in LTE networks is routed from: UE (terminal)<->eNB<->S-GW<->P-GW<->Internet/Backbone.

The exchange of further messages includes a GTP-C Bearer Resource Command (see. Sect. 7.2.5 in [21]) from MME to S-GW and from S-GW to P-GW, a GTP-C Create Bearer Request (see. Sect. 7.2.3 in [21]) from P-GW114to S-GW and S-GW to MME112and a E-RAB Setup Request/Response (see. Sect. 8.2.1.1 and Sect. 8.2.1.2 in [22]), which informs the radio resources manager30about the QoS characteristics that have to be provided. These messages mentioned before have to be extended accordingly to the extensions presented in Table 4 and Table 5. For instance, for the GTP-C Bearer Resource Command the Flow QoS IE in Sect. 8.16 in [21] should be extended with the Alternate bit rates defined here, as shown for example in Table 6. For the GTP-C Create Bearer Request the Bearer QoS IE in Sect. 8.15 in [21] should be extended with the Alternate bit rates defined here, as shown for example in Table 7. For the E-RAB Setup Request, the MME112should insert the negotiated Alternative bit rates in the E-RAB Level QoS Parameters in Sect. 9.2.1.15 in [22]. For this purpose, the E-RAB Level QoS should be extended adding the additional Alternative bit rates defined before, as shown for example in Table 8 and Table 9.

TABLE 6Flow Quality of Service (Flow QoS)BitsOctets876543211Type = 81 (decimal)2 to 3Length = n4SpareInstance5Label (QCI)6 to 10Maximum bit rate for uplink11 to 15Maximum bit rate for downlink16 to 20Guaranteed bit rate for uplink21 to 25Guaranteed bit rate for downlink26Number of additional alternative downlink rates (N)Alternative bit rate for downlink_1. . .26 + NAlternative bit rate for downlink_NNumber of additional alternative uplink rates (M)Alternative bit rate for uplink_1. . .27 + N + MAlternative bit rate for uplink_M28 + N + MThese octet(s) is/are present only if explicitly specifiedto (n + 4)

TABLE 7Bearer Level Quality of Service (Bearer QoS)BitsOctets876543211Type = 80 (decimal)2-3Length = n4SpareInstance5SparePCIPLSparePVI6Label (QCI)7 to 11Maximum bit rate for uplink12 to 16Maximum bit rate for downlink17 to 21Guaranteed bit rate for uplink22 to 26Guaranteed bit rate for downlink27Number of additional alternative downlink rates (N)Alternative bit rate for downlink_1. . .27 + NAlternative bit rate for downlink_NNumber of additional alternative uplink rates (M)Alternative bit rate for uplink_1. . .28 + N + MAlternative bit rate for uplink_M29 toThese octet(s) is/are present only if explicitly specified(n + 4)

Similar to the process described before, a hand-over could be initiated by a eNodeB as described in [23]. In such a case, the bearer setup or bearer maintenance (with same QoS characteristics) is not initiated neither by the MME nor P-GW, issuing a ESM bearer resource allocation request, but is done within the X2 interface defined in 3GPP [24]. In such a case the extended syntax, proposed previously, with alternative bitrates has to be included in the appropriate messages. Concretely, for interface X2, the HANDOVER REQUEST message is defined (cf. section 9.1.1.1[23]), which contains a E-RAB Level QoS Parameter IE/Group Name. This IE is defined in section 9.2.9 in [23] and should be extended as shown in Table 8. The syntax of this message would be the same as the E-RAB Setup Request described before.

Furthermore, additionally or alternatively to the functionalities described above, the resource manager74can forward the actual received throughput, such as seen by a higher level TCP session, as information to the radio resource manager30, in order to let it identify the actual resulting application throughput for further scheduling and radio resource allocation decisions for the particular client as well as other clients under its control. More generally, the user entity34may be for communicating with the radio resource base station32, on which the client40is operative, wherein the user entity34may be configured to determine the actually received media content throughput or buffer state of a media content retrieved by the client40from the server42and inform the radio resource manager30on the determined media content throughput or buffer state. The determination may involve the client40sending the respective information to the resource manager74which assumes responsibility for the respective task within the user entity.

With regard to the embodiment ofFIGS. 3 to 5, it should be mentioned that the above description primarily concerned the downlink case, i.e. the case where the radio resource manager assigned the downlink communication resources to the user entities34, although the above embodiments are also transferable to the uplink case. In a more general point of view, for example,FIGS. 3 to 5and all the other embodiments concerning the functionality of the radio resource manager30according to which the assignment of communication resources is performed, the radio resource manager may more generally be configured to assign communication resources, i.e. downlink and/or uplink communication resources of the at least one base station32to the user entities34depending on a media presentation description within a data traffic from a server to a client, where one of the server and the client operates at one of the user entities34with this one, however, being not necessarily the client. This will be explicitly outlined in more detail below. See, for example,FIG. 16. As a minor note, it is stated that server and client may even be both operating on one common user entity, and accordingly, “one of the server and the client” is to be understood as “at least one of”.

FIG. 16corresponds toFIG. 3except for the client40and the server42being switched: the server42operates at the user entity34, while the client40is positioned on the other side of the base station32relative to user entity34. When considering the more detailed explanation of a possible internal structure of the user entity as shown inFIG. 7, server32may be thought of as replacing client40inFIG. 7. This means the following. The radio resource manager30may survey the data traffic between server42and40. In particular, the radio resource manager30may inspect the media presentation description46therefrom. Based thereon, the radio resource manager30may assign the uplink communication resources of the base station32to the user entities among which the user entity34is at which server42operates. In principle, all of the above discussion with respect to potential behaviors of the resource manager30stay the same. That is, the resource manager30may also inspect and log the media requests from the client40to server42and perform the assignment of the uplink communication resources depending on an evaluation thereof and so forth.

The concordance between the embodiment ofFIGS. 3 to 5on the one hand andFIG. 16on the other hand remains valid even when considering the above-outlined extension of the embodiment ofFIGS. 3 to 5according to which part of the functionality of the radio resource manager30is transferred from RRM30onto the resource manager74positioned between server42on the one hand and transceiver stage70on the other hand (seeFIG. 7, for example). That is, also true for the case ofFIG. 16: the resource manager74may be configured to relieve the RRM30of surveying the data traffic between server42at user entity34and client40. That is, even in that case, i.e. where the server42is running on user entity34, the resources of the uplink bandwidth may be also managed analogously, namely by resource manager74indicating to the radio resource manger30the bit rate alternatives, i.e. the translated MPD, and RRM30using the translated MPD to perform the uplink resource assignment depending thereupon. The resource manager74may indicate the alternative bitrates for the uplink in the above-mentioned ESM messages, that contain the extended EPS quality of service message, as shown in Table 4.

See, for example,FIG. 14. On the left hand side,FIG. 14shows a flow diagram similar toFIG. 15, i.e. using a time axis110and differentiating the entities involved with the respective steps shown in the blocks by spreading the entities along the horizontal direction and showing by the arrows associated with the respective blocks, between which entities the respective step takes place. On the right hand side ofFIG. 14, the case ofFIG. 15is illustrated again, i.e. the case where the client resides at the user entity. On the left hand side, the case is shown where a server42operates at a user entity34. In fact, the client operating at the one user entity and the server operating at the other user entity may form a pair between which media content is transferred. Such a situation may take place within, for example, a video conference where the server operating at user entity34′ transmits to the client operating at user entity34″ a video concerning the participant of the video conference at user entity34′ captured, for example, by means of a respective camera of the user entity. Other use cases are, however, possible as well. For example, the client may download a file from the media server at someone else's user entity34′. In that case, the participating entities in the data traffic between the server at user entity34′ on the one hand and the client at user entity34″ on the other hand, are—shown in the order of their mentioning from left to right inFIG. 14: user entity34′, base station32′ to which user entity34′ is currently attached, the radio resource management30′ responsible for assigning the communication resources of base station32′, the mobility management entity112′ responsible for controlling the radio resource network to which base station32′ and radio resource manager30′ belong, the packet gateway114′ which belongs to the same radio resource network, the packet gateway114″ and the mobility management entity112″ both belonging to the radio resource network to which the base station32″ belongs, to which client34″ is attached, the radio resource manager30″ responsible for assigning the communication resources of base station32″, the base station32″ itself, and the user entity34″. As shown inFIG. 14, the user entity34″ would perform attachment and default bearer activation at step116′ in a same way as the user entity34″ does in step116. As described above with respect toFIG. 15, the client residing on user entity34″ may send in step118an MPD request to the server residing at user entity34′, whereupon the latter sends back the MPD in step120to user entity34″. Thereupon, in step122, the resource manager74residing at user entity34″ parses the MPD and then causes activation of the dedicated bearer along the line of the above description of steps126to142, whereupon the resource manager30assigns the downlink communication resources of base station32″ in accordance with a translated MPD forwarded by resource manager74of user entity34″ within the media transmission session144which then takes place between client and server. On the uplink domain side, similar steps are taken. The server42residing at user entity34′ causes the activation of the dedicated bearer, i.e. here an adaptive conversational or non-conversational communication type session, analogously to steps126to142described above with respect toFIG. 15, whereupon, within the media transmission session144, the radio resource manager30′ assigns the uplink resources of base station32′ in accordance with the translated media presentation description as forwarded by server at user entity34′ within the bearer resource allocation request126.

It should be mentioned thatFIG. 14merely exemplarily showed the case where server and client both reside on user entities tied to respective radio resource networks. The example ofFIG. 14is readily transferable onto a case where the client is not operating at a user entity, but, for example, at a stationary computer, for example. Moreover, it should be mentioned that the sown scenario may also take place within one common radio resource network and that the RRM′ and RRM″ and/or MME′ and MME″ and/or are the same.

By the way, it is noted that for all of the above embodiments, it may happen that the server where the media content44resides, may be separated from the entity acting as the server to provide the media presentation description. More generally, the MPD46may stem from another entity or server than the server providing the media content44itself. This possibility is, for example, illustrated inFIG. 14with dotted lines regarding the origin and target of the arrows corresponding to steps120and118, respectively. In particular, this potential MPD source is shown at150with dotted lines. In case of this extra MPD source150, the radio resource manager30′ may, nevertheless, be informed by the resource manager74on the translated media presentation description. In that case, however, resource manager74would, instead of inspecting the data traffic between the client at user entity34″ and the server at user entity34′, instruct the server at user entity34′ to provide the resource manager74at user entity34″ with the translated media presentation description.

Thus, in other words, the user entity34on the left inFIG. 14is set as the media server and the user entity34on the right is set as the client40. The MPD is requested by the client from the MPD source150, which may be any server in the network (one special case is when the server with the MPD is the media server at user entity34′). Since the media server knows the characteristics of the media, which are advertised at the MPD, it uses this information for indicating the alternative bitrates in the mentioned ESM messages and sets up the bearer, for which the uplink bitrate is especially important (the server needs to upload the data). The client, however, needs to parse the receive MPD and uses the described information for the bearer allocation, where the downlink bitrate has especial importance (the client40needs to download the data). However, since TCP may be used, the downlink bitrate is also important for the server, as well as the uplink bitrate for the client.

There is an especial case, e.g. in conversational scenarios, where each of the user entities34has a media server and a client simultaneously operating thereat. In this case both user entities34would request the media presentation description (e.g. MPD or SDP) and would use this information for describing the alternative bitrates for both uplink and downlink, based on the media characteristics offered at their respective servers and on the media characteristics that are supposed to receive as clients40.

In such a scenario, where the user entities34have a media server and a client simultaneously, it may happen that two different eNodeBs take care of the different user entities34taking part in the conversation. The radio resource manager30operating for each of the eNodeBs and taking care of the user entities34operates independently optimizing each of the air interfaces for the different users. The problem of such a scenario is that the air interface of the one user entity34is not taken into account for optimization of the radio resources of the other user entity34. Thus, a suboptimal decision may be taken. For example, if more data is uploaded from one user entity34, than the amount of data that can be downloaded at the other user entity34, which the first user entity34is communicating with, some data will be dropped at the radio resource manager30working with the user entity34with “download problems”. A solution would be to extend the messages defined in the X2 interface [23] and add a message that provides concrete information about the resources that will be ensured for each of the users, based on the information defined in the MPD or SDP. In such a way, both eNBs perform a collaborative resource allocation taking into account the information in the SDP or MPD, as defined through this document. The new message could be e.g., UE RESOURCE STATUS REPORT and contain a resource allocation IE, as shown in Table 9, Table 10 and Table 11.

The latter embodiment reveals a collaborative resource allocation without media knowledge in the sense described now. That is, see, for example,FIG. 3.FIG. 3shows merely one radio resource manager30but as already noted above, a system of several radio resource managers may form a radio system with all the radio resource managers30operating independent from each other in the sense that each radio resource manger30assigns, by optimization, its communication resources of its at least one base station32to the user entities34being within the reach of its base stations32merely based on information travelling over its own base station(s)32, such as quality feedback from the user entities34as outlined above, the number of user entities34to be served and so forth. Reference is made to the above discussion. That is, each RRM performs its own scheduling independently from each other. The independency of the scheduling is, however, broken through in accordance with the present embodiment in the sense that the RRMs also distribute information on their current radio resource distribution to its UEs, to outside for the use in the other RRMs. In the example just described, it is not necessary that the radio resource managers exploit information residing within media presentation descriptions if there are any. But according to the embodiment described now, it may, nevertheless, be avoided that the independently operating radio resource managers30disadvantageously assign unmatched communication resources to user entities which, by accident, have a communicating pair of client and server operating thereon. This is achieved as follows.

In particular, the radio resource manager surveys the data traffic towards a server or a client operating at one of the user entities34or some control messages exchanged between radio resource managers so as to obtain information on i) guaranteed communication resources currently assigned to the other of the server and the client, or a buffer state of the other of the server and the client. In case of the server operating on the user entity34served by the current radio resource manager30, the buffer state of this server could form, for example, an output buffer state, i.e. the fill level of an output buffer. This could be interesting, for example, in case of live streaming or video conferences. In case of the client40operating on the user entity34, the buffer state will be the fill level of an input buffer of the client. It is to be emphasized that in accordance with the present embodiment, the radio resource manager30(cf.FIG. 3) obtains this information regarding a server or client served by another radio resource manager30. Merely, the counterpart of the client/server pair is operating on the user entity34served by the radio resource manager30itself. In accordance with the present embodiment, the radio resource manager30uses this information concerning a client/server counterpart operating on a user entity served elsewhere, in order to perform the assignment of communication resources of the at least one base station32by which the user entity34is served. By this measure, it is possible to avoid that the radio resource manager30assigns to some user entity34unnecessarily increased communication resources although, for example, the buffer state of the client/server counterpart is high, or the guaranteed communication resources currently assigned to an external user entity which the server/client counterpart operates on, is low.

In order to make this clear, reference is made toFIG. 17, which shows such a system comprising several radio resource managers. In the LTE framework, the RRMs would from the afore-mentioned eNodeBs. One of the radio resource managers is exemplarily denoted with30, the other with30′. The fact that merely two managers are shown is exemplary. Both managers30and30′ assign their communication resources of their at least one respective base station32and32′, respectively. The assignment or scheduling is performed independently from each other except for the interactions involving the control signals or data traffic insertions described now.

InFIG. 17, one user entity34is exemplarily shown to be served by a base station32belonging to radio resource manager30and another user entity34′ is shown to be served by the base station32′ belonging to radio resource manager30′. On user entity34, a client40operates, and a server42is exemplarily shown to operate on user entity34′. Both communicate with each other by a data traffic which is illustrated by a dashed line inFIG. 17. The data traffic may of the telecommunicating type, download type or the like. As already noted with regard toFIG. 3, it is not necessary that the radio resource managers30and30′ are crossed by the data traffic. It would be sufficient if both radio resource managers30and30′ merely had access to the data traffic in order to survey and inspect same.

In order to avoid miss-optimization between RRM30and30′, both inform each other about current UE buffer states and currently guaranteed bitrates to the respective other RRM.

In accordance with a first alternative, both RRM might be kept agnostic to each other. The respective information is inserted into the client/server data stream so that miss-optimization may even be avoided in case of server or client being served outside the radio system in the internet, for example.

Radio resource manager30′ is, for example, able to survey the data traffic from server32towards client40in order to obtain information on guaranteed communication resources currently assigned to user entity34which client40operates on, or the buffer state of this client40. By this measure, radio resource manager30′ is able to avoid spending too much communication resources for server42although, for example, the buffer state of client40is already high, or the guaranteed communication resources currently assigned to user entity34are low. On the other hand, radio resource manager30is able to survey the data traffic from client40towards server42in order to obtain information of the guaranteed information resources currently assigned to user entity34′ or the buffer state of server42. In the same manner, radio resource manager30is, by use of this information, able to avoid assigning too much communication resources to user entity34although, for example, the buffer state of server42approaches an empty state of fill level, or although the guaranteed communication resources currently assigned to user entity34′ are low.

As already denoted above, the guaranteed communication resource could be something which the radio resource managers30and30′ determine within the assignment of communication resources of its base station(s)32to its served user entities34. That is, radio resource manager30and30′, respectively, assign guaranteed communication resources to user entities34and34′ in units of some time intervals, such as, for example, time intervals of 3 to 10 seconds. They also obey the guaranteed communication resources in assigning the communication resources within those time intervals. Either, the radio resource managers30and30′ use the guaranteed communication resources fixedly via the time intervals, or they vary the communication resources assigned to the user entities, but merely within the limits imposed by the guaranteed communication resources.

There are different possibilities as to how the information of the buffer state or the guaranteed communication resources from an external radio resource manager's domain enters the radio resource manager's domain of a radio resource manager serving a client/server counterpart via the data traffic. For example, radio resource managers30and30′ could be configured to insert information on the guaranteed communication resources assigned to its served user entity into the data traffic from the client40or server42running on its served user entity. Radio resource manager30′, for example, could insert into the data stream from server42to client40the information concerning the guaranteed communication resources assigned to user entity34′, and the radio resource manager30, in turn, could insert into the data traffic from client40to server42the information concerning the guaranteed communication resources assigned to user entity34. Further, the insertion does not necessarily have to be performed by radio resource managers30and30′, by themselves. As already outlined above with respect to the foregoing embodiment, such an insertion could also be performed by resource managers74running on the user entities34and34′, respectively. In that case, the radio resource managers30and30′ would inform the user entities34and34′, respectively, on their guaranteed communication resources, i.e. the guaranteed communication resources assigned to the user entities34and34′, they are operating on, and this information would be surveyed and inspected by the resource managers74, which, in turn, perform the just mentioned insertion instead of the radio resource manager.

In accordance with a second alternative, both RRMs30and30′ inform each other about current UE buffer states and currently guaranteed bitrates concerning UE's served by themselves to the respective other RRM via control signals199. In the LTE architecture, for example, such control signals could be exchanged between the RRMs via, for example, the X2 interface, S-GW or the like using, for example, the HSS as an operator which guides the path of control signal exchange accordingly. In accordance with this example, radio resource managers30and30′ would, for example, perform the following steps: 1) realizing that the client or server operating on the user entity served by themselves, seeks to setup an immediate transmission session, i.e. a media transmission session involving this client or server commences; 2) Checking whether the counterpart, i.e. server or client, with which a media transmission session is set-up, is served by any of the other RRMs of the radio system; 3) If yes, accompanying the media transmission session with control signals199. The path for the control signals is guided via the HSS, for example. For example, radio resource manager30informs radio resource manager30′ via control signals199of the client's buffer state wherein the radio resource manager30may have obtained this information as explained above, i.e. by simulation or feedback from a resource management74within user entity34. Or radio resource manager30may inform radio resource manager30′ via control signals199on the guaranteed radio resources assigned to user entity34. Radio resource manager30′ does the same in the reverse direction during the media transmission session. That is, radio resource manager30′ informs the radio resource manager30via control signals199of the server's buffer state and/or the guaranteed radio resources for user entity34′.

Naturally, the just described embodiment would also be combinable with any of the afore-mentioned embodiments. This is true, for example, as far as the embodiments are concerned according to which the buffer state of the client or server, which operates on the user entity served by the radio resource manager itself, is used by the radio resource manager in order to perform the communication resource assignment.

Table 9 extends the Message Type Table in section 9.2.13 in [23] as follows:

Table 10 shows the syntax of the UE RESOURCE STATUS REPORT.

Table 11 shows the syntax of the UE Allocated Resource Information IE.

Alternatively a variety of bitrates based on the SDP or MPD (based on media characteristics) could be provided with a maximum supported bitrate as shown in the following table:

TABLE 6Standardized QCI characteristics [cp. 19]Packet DelayPacket ErrorResourceBudgetLoss RateQCITypePriority(NOTE 1)(NOTE 2)Example Services1GBR2100 ms10−2Conversational Voice(NOTE 3)24150 ms10−3Conversational Video (Live(NOTE 3)Streaming)2-2GBR with4150 ms10−3Conversational Video (Live(seeminimumStreaming),additionalonly andNote: Here the UENOTE)alternativeindicates it bit ratehigher-alternatives not only forbitratesthe downlink, but also forthe uplink3GBR350 ms10−3Real Time Gaming(NOTE 3)45300 ms10−6Non-Conversational Video(NOTE 3)(Buffered Streaming)4-2GBR with5300 ms10−6Adaptive Non-(seeminimumConversational Videoadditionalonly and(Buffered Streaming, e.g.NOTE)alternativeHTTP Streaming)higher-Note: A UE may indicatebitratesthe presence of thealternative bitrates viaindicating a new QCI value,but it may also be possibleto fully backwardcompatible add a list ofalternative bitrates behindthe existing values of GBR,and MBR.5Non-GBR1100 ms10−6IMS Signalling(NOTE 3)66300 ms10−6Video (Buffered Streaming)(NOTE 4)TCP-based (e.g., www, e-mail, chat, ftp, p2p filesharing, progressive video,etc.)6-2Non-GBR6300 ms10−6Adaptive Video (Buffered(seewithStreaming)additionalalternativeTCP-based (e.g., www, e-NOTE)bit ratesmail, chat, ftp, p2p filesharing, progressive video,HTTP Streaming, etc.)Note: A UE may indicatethe presence of thealternative bitrates viaindicating a new QCI value,but it may also be possibleto fully backwardcompatible add a list ofalternative bitrates behindthe existing values of GBR,and MBR. In case of notexpecting GBR and MBRvalues as usual for non-GBR services, these fieldsmay be presented butshould be set to Null.7Non-GBR7100 ms10−3Voice,(NOTE 3)Video (Live Streaming)Interactive Gaming88300 ms10−6Video (Buffered Streaming)(NOTE 5)TCP-based (e.g., www, e-mail, chat, ftp, p2p filesharing, progressive video,etc.)99(NOTE 6)NOTE 1:A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is located “close” to the radio base station (roughly 10 ms) and the case where the PCEF is located “far” from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual packet delays - in particular for GBR traffic - should typically be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.NOTE 2:The rate of non congestion related packet losses that may occur between a radio base station and a PCEF should be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station.NOTE 3:This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's uplink/downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established/modified.NOTE 4:If the network supports Multimedia Priority Services (MPS) then this QCI could be used for the prioritization of non real-time data (i.e. most typically TCP-based services/applications) of MPS subscribers.NOTE 5:This QCI could be used for a dedicated “premium bearer” (e.g. associated with premium content) for any subscriber/subscriber group. Also in this case, the SDF aggregate's uplink/downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for “premium subscribers”.NOTE 6:This QCI is typically used for the default bearer of a UE/PDN for non privileged subscribers. Note that AMBR can be used as a “tool” to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer.

As has also been described above, the above embodiments also, inter alias, revealed a client—such as software, hardware, or programmable hardware—for being operative on a user entity34for communication with a radio resource base station32, the client40being configured to retrieve from a server42a media presentation description and a media content44, the media presentation description46describing versions of differing bandwidths of the media content44, the client being configured to be switchable from a normal mode to a slave mode by means of a signalization from a radio resource manager30responsible for assigning the communication resources of the base station32to the user entity, wherein the client is configured to, in the normal mode, request the media content44from the server42in a version determined by the client based on the communication resources assigned to the user entity, and, in the slave mode, request the media content44from the server42in a version determined by the client irrespective of the communication resources assigned to the user entity. The Client may further be configured to, in the normal mode, request the media content44from the server42in a version determined by the client based on the communication resources assigned to the user entity and a buffer state of the media content. The client may also further be configured to, in the slave mode, request the media content44from the server42continuously in a version which corresponds to a highest bandwidth version among the versions of differing bandwidth in the media presentation description46. That is, a client behavior could be controlled by, for example, @automaticSwitching indicator in MPD: the client may be informed that a device in-the-middle may adjust the bitrate of the selected segments in the middle to optimize the cell resources, so that the client shall not react on bitrate changes itself.

LIST OF REFERENCES