Sign In to Follow Application
View All Documents & Correspondence

Radio Resource Management Concept For Transferring Media Content From A Server To A Client

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

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
20 November 2019
Publication Number
04/2020
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
kolkatapatent@Lsdavar.in
Parent Application
Patent Number
Legal Status
Grant Date
2024-01-09
Renewal Date

Applicants

FRAUNHOFER-GESELLSCHAFT ZUR FÖRDERUNG DER ANGEWANDTEN FORSCHUNG E.V.
Hansastraße 27c, 80686 München, GERMANY

Inventors

1. SCHIERL, Thomas
Dunckerstrasse 72, 10437 Berlin, GERMANY
2. WIRTH, Thomas
Prenzlauer Allee 35, 10405 Berlin, GERMANY
3. HAUSTEIN, THOMAS
Zum Reiherstand 2, 14469 Potsdam, GERMANY
4. SANCHEZ, YAGO
Warschauer Strasse 67, 10243 Berlin, GERMANY

Specification

Resource Management Concept

Description

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 3 GPP [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 necessary information 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 in Figure 1.

As is visible from Fig. 1, the participating entities in a DASH environment are: the DASH server 10 which receives its media content to be distributed to respective DASH clients 12 from some DASH content preparation stage 14, the DASH client 12 itself and the network interconnecting the DASH server 10 and the DASH client 12 with the network 16 being denoted as "HTTP Cache". As depicted in Fig. 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 server 10 the media presentation description MPD 18 which, in turn, has been generated along with the versions of the media content by the DASH content preparation stage 14 so as to describe the various versions of the media content available at the DASH server 10.

Figure 2 shows 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 client 12 is shown to be connected to the HTTP CASH 16 via a concatenation of an LTE base station 20, a radio channel 22 and a user entity 24, wherein a radio resource manager 26 is shown to be comprised by the base station 20 and the user entity 24 may be a mobile

terminal such as a mobile phone or the like at which the DASH client 12 is operating in form of, for example, a software running on the user entity's processor. It is assumed that the DASH client 12 as well as the LTE eNB 20 have access to the media presentation description (MPD 18). The MPD 18 provides sufficient information about the video representation at server 10 to provide a streaming service to the user 12 by the user requesting segments from the HTTP server 10 using TCP/IP as transport protocol. Initially, the dash client 12 transmits a HTTP get request to the HTTP server 10. After HTTP handshake a TCP tunnel between server 10 and client 12 is established. This TCP tunnel is transparent for the underlying physical transport layer. Depending on the information provided by the MPD 18, the DASH client 12 has enough information for demultiplexing, decoding and rendering the included media data appropriately.

The problem involved with the scenario depicted in Fig. 2 is the usual behavior of the DASH client 12 according to which each DASH client 12 seeks to provide its user with the version of the media content residing on the respective server 10 having the highest quality and/or information content possible at the currently assigned communication resources, assigned by the radio resource manager 26 to the user entity 24 of the respective DASH client 12. 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 client 12 maximally strains the available radio resources of the base station 26 and the base station and the radio resource manager 26, 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 entities 24.

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.

This object is achieved by the subject matter of the independent claims.

Preferred embodiments of the present invention are described below with respect to the figures among which

Fig. 1 shows a block diagram of an example of DASH architecture;

Fig. 2 shows a block diagram illustrating the current deployment architecture for

DASH in LTE networks, wherein the solid white boxes indicate devices specified in the DASH standard, while the dashed white boxes are conceptual or transparent;

Fig. 3 shows a block diagram of an exemplary radio resource environment including a radio resource manager, based on which different embodiments of the radio resource manager according to the present invention are described;

Fig. 4 shows a graph of the media rate vs. instantaneous rate vs. segment download rate;

Fig. 5 shows a diagram of a possible implementation of a first embodiment of the radio resource manager of Fig. 3;

Fig. 6 shows a block diagram of a further exemplary radio resource environment including a radio resource manager, based on which different embodiments of the radio resource manager according to the present invention are described;

Fig. 7 shows block diagram of a user entity including a resource manager, based on which different embodiments of the resource manager according to the present invention are described;

Fig. 8 shows a diagram of a possible implementation of an embodiment of the radio resource manager of Fig. 6;

Fig. 9 shows a diagram of a possible implementation of an embodiment of the radio resource manager of Fig. 3 and 6;

Fig. 10 shows a diagram of a possible implementation of a client suitable for being used in the embedment of Fig. 7;

Fig. 1 1 shows a block diagram of an exemplary radio resource environment including a resource manager of Fig. 10;

Fig. 12 shows a block diagram of another exemplary radio resource environment including a radio resource manager according to Fig. 3 or 6;

Fig. 13 shows a block diagram of a possible implementation of a portion of the data path between client and server, including a possible implementation of the client;

Fig. 14 shows a sequence of steps performed in a scenario with a server operating at one user entity and the corresponding client operating at another user entity in accordance with an embodiment;

Fig. 15 shows a sequence of steps performed in a scenario where a resource manager of the user entity at which a client operates, relieves the radio resource manager of the MPD parsing;

Fig. 16 shows a block diagram of an exemplary radio resource environment including a radio resource manager assigning uplink communication resources in accordance with an embodiment; and

Fig, 17 shows a system of radio resource managers in accordance with another embodiment.

Fig. 3 shows a first embodiment of a radio resource manager in accordance with the present application. The radio resource manager of Fig. 3 is generally indicated with reference sign 30 and is configured to assign communication resources of a base station 32 to user entities for which one is representatively shown at 34. The user entity 34 is, for example, a mobile terminal such as a mobile phone, a laptop or the like, but may also be a stationary device. The user entity 34 is able to communicate with the base station 32 via a wireless channel 36 via its antenna or antennas (not shown). The base station 32 appropriately manages the multiplexing of communication data, i.e. downlink and uplink data onto the communication channel 36, and may have also one or more antennas (not shown). In particular, the base station 32 appropriately multiplexes downlink data for the various user entities 34 onto the transmit signal output by base station 32. Different multiplexing schemes may be used to this end. For example, the base station 32 may use OFDM and, in particular, LTE. In any case, the base station 32 is able to distribute or assign the communication resources of the communication channel to the user entities, including user entity 34, in a time- varying manner so as to adapt the assignment of the communication resources of base station 32 to the user entities - called, inter alias, the scheduling - to the current resource situation. For example, the base station 32 may rely on any combination of the following parameters in order to perform the scheduling:

1) The number of user entities 34 served by the base station 32, i.e., the number of user entities 34 having performed a registration at the base station 32 und thus, the number of user entities 34 among 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 RRM 30 favoring, 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 station 32 on the one hand and the individual served user entities 34 on the other hand, wherein the base station 32 measures the channel quality, for example, by respective channel feedback signals from the user entities

5) Channel rate requests from the user entities, indicating the user entities' wishes for the assignment of further bandwidth.

In case more than one base station 32 and 38 may 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 RRM 30 or information derived by RRM 30 about the user entities 34 such as Handover between cells, can be further shared between base stations 32 and 38 and collected and used by a higher level RRM 30.

The base station 32 may 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 station 32 could 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 station 32, 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 station 32 may either not use the respective transmission feature or use a fixed setting instead. For example, the base station 32 may 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 entity 34 experiences an effective transmission bandwidth for both downlink and uplink.

As a minor note it should be noted that the radio resource manager 30 of Fig. 3 could be included, could be part of, or could be housed by, the base station 32. However, the radio resource manager 30 could also be arranged physically separated from the base station 32. In particular, it could even be possible that the radio resource manager 30 is not especially associated with a certain base station. Rather, the radio resource manager 30 could 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 station 38, the communication resources of which may, optionally, also be controlled by radio resource manager 30. In particular, it could be possible that the base stations 32 and 38 form, along with a radio resource manager 30, 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 manager 30. Accordingly, the effectively available communication bandwidth of user entity 34 would, in that case, be the sum of the effective bandwidth offered, or assigned to it, by each of the serving base stations 32 and 38. Naturally, the number of serving base stations could be increased.

In any case, the problem involved with the functionality of the radio resource manager 30 as described so far is that a client 40 operating at one of the user entities, such as user entity 34, seeks to obtain a media content from a server 42 in 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 client 40 of user entity 34 seeks to download a media content 44 from server 42 and that this media content 44 is available at server 42 in different versions as described by a media presentation description 46 which is also available from server 42 for client 40. The different versions of the media content 44 may differ in any combination of any subset of the following parameters:

1) Spatial resolution

2) Temporal resolution

3) Number of views

4) Bit depth

5) Signal to noise ratio

6) Number of audio channels.

That is, the media content 44 may be a video. The data traffic via which client 40 obtains the media content 44 from server 42 is at least surveyable by radio resource manager 30 as it is depicted by dotted line 48 which shows that the data traffic between server 42 and client 40 leads past base station 32 or the base stations 32 and 38, respectively, with a content of the data traffic being inspectable by the radio resource manager 30 as shown with arrow 50. Alternatively, the data traffic may even lead through the radio resource manager 30 as illustrated by dashed arrow 52 so that, in accordance with this alternative, the radio resource manager 30 would even be able to not only inspect, but also intercept or otherwise influence portions of the data traffic between client 40 and server 42.

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 content 44 convey a different amount of information on the media content 44, these versions allow for a ranking among these versions with respect to their necessary minimum required transmission bandwidth necessary in order to play the respective version at the client 40 without interruptions.

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

Finally, client 40 requests a wanted version of the media content 44 from server 42 such as, for example, by a HTTP request. In order to enable the client 40 to decide on the version to be provided to the user, client 40 is provided with the media presentation description 46 within the data traffic from the server 42 to client 40. For example, client 40 requests the media presentation description 46 of the media content 44 from server 42 which, in turn, responds by sending the media presentation description 46 to client 40. As described above, the media presentation description 46 indicates to client 40 the available versions available at server 42 of media content 44 and the necessary minimum required transmission bandwidths of these versions. Accordingly, client 40 evaluates the currently available efficient bandwidth offered or assigned to the user entity 34 by radio resource manager 30 and selects, usually, the version having the highest level and necessitating, accordingly, the highest minimum required transmission bandwidth which still is below, or equal to, the efficient bandwidth offered by video radio resource manager 30.

However, as described in the introductory portion of the specification of the present application, as all the clients 40 operating 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 station 32 is high although, for example, the strain would not have to be that high if the clients 40 would lower their requested version level.

Accordingly, in accordance with the embodiment of Fig. 3, the radio resource manager 30 is configured to assign the communication resources of the base station 32 to the user entities including user entity 34, depending on the media representation description 46 within the data traffic from a respective server 42 to a respective client 40 operating at the respective user entity 34. As will get clear from the below description, the communication resources assigned by RRM using the outlined dependency on the MPD 46, 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 manager 30 is configured to inspect the media presentation description 46 describing the versions of the video content 44 of differing bandwidths within the data traffic from the server 42 to client 40 and 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 station 32 to the user entities among which the user entity 34 is.

For example, if there is currently a high strain put onto the communication resources of base station 32 due to, for example, a high number of user entities 34 to be served, radio resource manager 30 may decide that a version of the media content 44 currently requested from server 42 by client 40 should currently not be available for the client 40 and accordingly, reduces the amount of communication resources assigned to user entity 34, thereby effectively reducing the effective bandwidth offered to the user entity 34. In other words, the radio resource manager 30 may decide, that in high strain situations, client 40 should switch from a higher level version of the media content 44 to a lower level version thereof, at least temporarily during the high strain put on to the communication resources of base station 32. Of course, RRM 30 may 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 RRM 30 not necessarily assigns the communication resources to the clients merely in order to optimize the cell throughput. Rather, the RRM 30 could 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 manager 30 may be configured to, if the clients 40 of more than one of the user entities 34 to which the communication resources are assigned, are currently downloading respective media content 44 via the at least one base station 32, perform the assignment of the communication resources to the more than one user entities 34 depending on the respective media presentation description 46 within 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 content 44 of 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 content 44 of 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 clients 40. 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 description 46 of the respective media content requested by the respective client.

Moreover, the radio resource manager 30 may log a history of versions of the media content 44 requested by client 40 in order to use the history in order to re-assign a higher amount of communication resources to the respective client 40 in phases where the strain put on to the communication resources of the base station 30 decreases again.

The client 40, in turn, will realize by evaluating the current effective bandwidth provided by radio resource manager 30, that - incase the RRM 30 decided to lower the assigned communication resources amount - the currently requested and downloaded version of media content 44 is presentable to the user merely with interruptions. In other words, the client 40 will realize that the media buffer of the media player reproducing the media content 44 to the user is going to get empty due the decrease of the available transmission bandwidth via the wireless communication path 36. While the client 40 is free to react to this situation as it wishes or as the client wishes, one reasonable option of the client 40 would be that same sends a request to server 42, requesting a lower level version of the media content 44, i.e., a version associated with a lower necessary minimum transmission bandwidth than compared to the currently downloaded version of the media content 44.

To summarize, in accordance with the embodiment of Fig. 3, the radio resource manager 30 performs 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 description 46 within the data traffic extending between respective pairs of servers and clients operating at respective user entities.

With respect to the embodiment of Fig. 3, it is noted that the client 30 may, 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. 3 reveals a radio resource manager configured to assign communication resources of a base station 32 to user entities 34 depending on a media presentation description 46 within a data traffic from a server 42 to a client 40 operating at one of the user entities 32.

In the following, a possible implementation of the embodiment of Fig. 3 is explained. According to this possible implementation, the client 30 uses video streaming over HTTP in order to obtain the media content 44 from server 42. 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 in Figure 4 and Table 1. As seen in the in Figure 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 station 32 properly. Therefore, 32 may 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 buffers 100 of 30 (cf. Fig. 13) to derive the actual packet loss rate on the higher network layer such as the transport layer, e.g. for TCP.

With respect to Fig. 3, for example, the radio resource manager 30 has different possibilities to check as to which version of a media content out of the MPD 46 the client 40 is currently downloading. For example, the RRM 30 may determine the version of the media content 44 currently downloaded by the client 44 via base station 32 by inspecting a media request from the client 40 to the server 42. A simpler processing at RRM 30, however, with less tracking operations, is, however, achievable when RRM 30 determines 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 content 44 out of the media presentation description 46, is currently downloaded by the client 44 via the at least one base station 32. As the throughput measure, the assigned bandwidth itself may be used. Alternatively, RRM 30 may try to estimate the deviation/decrease of the actually received media content bandwidth of the respective client 40 from the originally assigned bandwidth to the respective user entity, by way of an evaluation of the quality feedback sent from the respective user entity 34 to the base station 32, as has been just described. Even alternatively, an additionally functionality of the user entity may inform the RRM 30 about the actually received media content throughput rate.

Although the above description assumed the radio resource manager to survey the data traffic from the server 42 to the client 40 so as to obtain the media presentation description 46, 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 (see Fig. 7, for example). That is, this surveillance could be assumed by a surveillance stage within the user entity. The surveillance stage would forward the MPD 30 - back - to the RRM 30, 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 server 32. Thus, the user entity 34 may be configured to communicate with the radio resource base station 32 and may have the client 40 operative thereon, as described above, wherein, however, the user entity 34 may additionally be configured to survey the data traffic from the server 42 to the client 40 so as to derive the media presentation description 46 from the data traffic and forward, at least partially, the media presentation description to the radio resource manager 30. Later, it will be shown that the user entity may have a server operating thereat instead of client 40, 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 of Fig. 3 described next, client 40 and server 42 may use DASH in order to stream the media content 44 from server 42 to client 40. 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 of Fig. 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 @minBufferTime tag and which is therefore quasi-mandatory.

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

That is, the MPD 46 of Fig. 3 could have the parameters @bandwidth, @minBufferTime and, optionally, @quality Ranking for each available version (representation).

As seen above, it would even be possible that the MPD 46 merely 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 requires 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.

Claims

1. Radio resource manager configured to assign communication resources of at least one base station (32) to user entities (34) depending on a media presentation description (46) relating to a media content (44) transferred within a data traffic from a server (42) to a client (40) with one of the server (42) and the client (40) operating at one of the user entities (32).

2. Radio resource manager according to claim 1, wherein the radio resource manager is configured to assign downlink communication resources of the at least one base station (32) to the user entities (34) depending on the media presentation description (46), with the client operating at the one of the user entities (32).

3. Radio resource manager according to claim 1, wherein a radio resource manager is configured to assign uplink communication resources of the at least one base station (32) to the user entities (34) depending on the media presentation description (46), wherein the server (42) operates at the one of the user entities.

4. Radio resource manager according to any of claims 1 to 3, further configured to survey the data traffic from the server (42) to the client (40) so as to obtain the media presentation description (46).

5. Radio resource manager according to any of claims 1 to 3, further configured to receive the media presentation description (46) from the user entity.

6. Radio resource manager according to any of the previous claims, wherein the media presentation description comprises, for each version of a media content (44) to be transferred within the data traffic from the server (42) to the client (40), a quality measure and a minimum bandwidth of the versions of the media content (44).

7. Radio resource manager according to any of claims 1 to 6, further configured to inspect the media presentation description (46) so as to identify within the media presentation description (46) a version of the media content (44), which has a lower minimum bandwidth associated therewith as a version of the media content (44), currently downloaded by the client (44) via the at least one base station, wherein the radio resource manager is configured to perform the assignment of the communication resources to the user entities dependent on as to whether such a version having a lower minimum bandwidth associated therewith is present or absent.

8. Radio resource manager according to claim 7, further configured to perform the assignment of the communication resources to the user entities dependent on as to whether such a version having a lower minimum bandwidth associated therewith is present or absent such that the communication resource assigned to the one user entity are more likely - related to equal probability among possible states of remaining parameters depending on which the radio resource manager assigns the communications resources - to be lower in case of the version having a lower minimum bandwidth associated therewith being present, than compared to the case of the version having a lower minimum bandwidth associated therewith being absent.

9. Radio resource manager according to any of claims 1 to 8, further configured to inspect the media presentation description (46) so as to identify within the media presentation description (46) a version of the media content (44), which has a higher minimum bandwidth associated therewith as a version of the media content (44), currently downloaded by the client (40) via the at least one base station, wherein the radio resource manager is configured to perform the assignment of the communication resources to the user entities dependent on as to whether such a version having a higher minimum bandwidth associated therewith is present or absent.

10. Radio resource manager according to any of claims 1 to 8, further configured to perform the assignment of the communication resources to the user entities based on one or more of

• a number of user entities 34 to which the communication resources of the at least one base station (32) have to be assigned at an appropriate ratio,

• a sort of communication data to be exchanged between the user entities and the at least one base station,

• user profiles assigned to the user entities, the profiles defining a priority ranking among the user entities,

· channel quality feedback from the user entities, and

• channel rate requests from the user entities.

11. Radio resource manager according to any of claims 1 to 10, further configured to, in assigning the communication resources to the user entities, adjust one or more of

• subcarriers,

• time slots, and

• a spatial coverage of the at least one base station's cell,

depending on the media presentation description (46).

12. Radio resource manager according to any of claims 1 to 1 1, further configured to, if the clients of more than one of the user entities to which the communication resources are assigned, are currently downloading respective media content via the at least one base station, perform the assignment of the communication resources to the more than one user entities (34) depending on a respective media presentation description (46) within a data traffic from a respective server (42) to the respective client (40) such that a cost function is optimized which, at least, depends a quality measure and a minimum bandwidth of the versions for each media content (44) of the clients.

13. Radio resource manager according to any of claims 1 to 12, further configured to determine a throughput measure for a received media throughput of the client and predict from the determined throughput measure as to which version of a media content (44) out of the media presentation description (46), is currently downloaded by the client (44) via the at least one base station (32).

14. Radio resource manager according to any of claims 1 to 13, further configured to determine a throughput measure for a received media throughput of the client and perform the assignment depending on the determined throughput measure.

15. Radio resource manager according claim 13 or 14, further configured to use the assigned communication bandwidth as the throughput measure, estimate the throughout measure from the assigned communication bandwidth by way of an evaluation of a quality feedback from the user entity (34), or receive the throughout measure from the user entity (34).

16. Radio resource manager according to any of claims 1 to 15, further configured to determine a version of the media content (44) out of the media presentation description (46), which is currently downloaded by the client (44) via the at least one base station (32), by inspecting a media request (60) from the client (40) to the server (42).

17. Radio resource manager according to any of claims 1 to 16, further configured to log a history of versions of a media content requested by the client (40) and further use the history in order to decide on increasing an amount of communication resources currently assigned to the client (40) in case a strain put onto the communication resources of the at least one base station (32) decreases.

18. Radio resource manager according to any of claims 1 to 17, further configured to simulate a user entity's buffering state based on channel quality feedback from the user entity to the at least one base station, or monitor a media content buffer (100) positioned on the other side of the base station (32) or within the base station (32), or extract the buffering state from an explicit signalization within a data traffic from the client (40) to the server (42) and to perform the assignment depending on the buffering state as far as downlink communication resources of the base station are concerned.

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

20. User entity according to claim 19, wherein the user entity is configured to perform the forwarding in a lower OSI layer than an OSI layer via which the data traffic is conveyed.

21. User entity for communicating with a radio resource base station (32), on which a client (40) 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 (42) and inform a radio resource manager (30) responsible for assigning the communication resources of the radio resource base station (32) to the user entity, on the determined media content throughput or buffer state.

22. User entity according to claim 21, wherein the user entity is configured to perform the informing in a lower OSI layer than an OSI layer via which the media content retrieval is conveyed.

23. Client for being operative on a user entity (34) for communication with a radio resource base station (32), the client (40) being configured to retrieve from a server (42) a media presentation description and a media content (44), the media presentation description (46) describing versions of differing bandwidths of the media content (44), 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 (30) responsible for assigning the communication resources of the base station (32) to the user entity, wherein the client is configured to, in the normal mode, request the media content (44) from the server (42) 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 (44) from the server (42) in a version determined by the client irrespective of the communication resources assigned to the user entity.

24. Client according to claim 23, further configured to, in the normal mode, request the media content (44) from the server (42) in a version determined by the client based on the communication resources assigned to the user entity and a buffer state of the media content.

25. Client according to claim 23 or 24, further configured to, in the normal mode, request the media content (44) from the server (42) in a version determined by the client based on buffer state of the media content such that the version determined is changed to a version with a lower quality compared to a currently determined version, in case of an amount of the communication resources assigned to the user entity, decreasing.

26. Client according to any of claims 23 to 25, further configured to, in the slave mode, request the media content (44) from the server (42) continuously in a version which corresponds to a highest bandwidth version among the versions of differing bandwidth in the media presentation description (46).

27. Resource manager configured to

inspect a media presentation description (46) describing versions of a media content (44) of differing bandwidths, within a data traffic from a server (42) to a client (40) operating at a user entity (34);

inspect a media request (60) from the client (40) to the server (42), requesting a wanted version of the media content (44); and

decide, depending on a current resource situation information and the media presentation description (46),

to forward the media request (60) to the server, or, alternatively,

to cause that the media request (60) does not lead to the wanted version of the media content (44) being sent to the client (40).

28. Resource manager according to claim 27, configured to perform the causing by modifying the media request (60) to the extent that the modified media request requests a version of the media content (44) of less bandwidth, or intercepting the media request (60) and emulating, or instructing the server (42) to send back, a non- availability response from the server (42) to the client (40).

29. Resource manager according to claim 27 or 28, further configured to inspect the media presentation description (46) so as to identify within the media presentation description (46) a version of a media content (44), which has a lower minimum bandwidth associated therewith as the wanted version of the media content (44), 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.

30. Resource manager according to any of claims 27 to 29, wherein the resource manager is a radio resource manager and is further configured to perform an assignment of communication resources of at least one base station to user entities to which the user entity at which the client operates, belongs.

31. Resource manager according to any of claims 27 to 30, wherein the resource manager is arranged within the user entity between a transceiver stage (70) thereof, and the client (40), wherein the resource manager is configured to obtain the current resource situation information from the transceiver stage (70).

32. Resource manager according to any of claims 27 to 31, further configured to simulate a user entity's buffering state based on a 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.

33. Resource manager configured to

inspect a media presentation description (46) describing versions of a media content (44) of differing bandwidths, within a data traffic from a server (42) to a client (40) operating at a user entity (34);

inspect a media request (60) from the client (40) to the server (42), requesting a wanted version of the media content (44);

obtain an user entity's buffering state for the client by simulating same based on channel quality feedback from the user entity (34) to the base station (32) or a monitoring of a media content buffer (100) positioned on the other side of the base station (32) or within the base station (32), or extracting the user entity's buffering state from an explicit signalization within a data traffic from the client (40) to the server (42); and

decide, depending on the user entity's buffering state and the media presentation description (46),

to forward the media request (60) to the server, or, alternatively,

to cause that the media request (60) does not lead to the wanted version of the media content (44) being sent to the client (40).

34. Resource manager according to claim 33, configured to perform the causing by modifying the media request (60) to the extent that the modified media request requests a version of the media content (44) of less bandwidth, or intercepting the media request (60) and emulating, or instructing the server (42) to send back, a nonavailability response from the server (42) to the client (40).

35. Resource manager according to claim 33 or 34, wherein the resource manager is configured to configured to perform the decision further based on a current resource situation information.

36. Resource manager according to claim 35, further configured to inspect the media presentation description (46) so as to identify within the media presentation description (46) a version of a media content (44), which has a lower minimum bandwidth associated therewith as the wanted version of the media content (44), 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.

37. Resource manager according to any of claims 33 to 36, wherein the resource manager is a radio resource manager and is further configured to perform an assignment of communication resources of at least one base station to user entities to which the user entity at which the client operates, belongs.

38. Resource manager according to any of claims 33 to 37, wherein the resource manager is arranged within the user entity between a transceiver stage (70) thereof, and the client (40), wherein the resource manager is configured to obtain the current resource situation information from the transceiver stage (70).

39. Resource manager according to any of claims 33 to 38, further configured to simulate a user entity's buffering state based on a 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.

40. Resource manager configured to

inspect a media presentation description request from a client (40) operating at a user entity (34) to a server (42), the media presentation description request requesting a media presentation description (46) from the server (42), the media presentation description (46) describing versions of a media content (44) of differing band widths;

inspect the media presentation description (46) within a data traffic from the server (42) to the client (40);

decide, based on a current resource situation information and the media presentation description (46),

to forward the media presentation description (46) to the client (40) as an answer to the media presentation description request, or

to intercept the media presentation description (46), and modify the media presentation description.

41. Resource manager according to claim 40, further configured to, in modify the media presentation description, removing, or removing and, then, re-inserting, one or more versions of the media content (44) of higher-than-average bandwidth.

42. Resource manager according to claim 40, further configured to, in performing the interception and modification,

add information to the media presentation description (46) in order to

instruct the client (40) to send explicit signalization regarding media buffering state information to the resource manager instead of to the server (32),

indicate a protocol change from a unicast to multicast protocol;

inform the client (40) that the resource manager may adjustment the media content (44);

and send the information-added media presentation description to the client (40) as the answer to the media presentation description request, or

reduce the media presentation description (46) so as to describe merely a proper subset of the versions of the media content (44) of differing bandwidths, and send the reduced media presentation description to the client (40) as the answer to the media presentation description request.

43. Resource manager according to any of claims 40 to 42, further configured to inspect the media presentation description (46) so as to identify within the media presentation description (46) a version of a media content (44), which has a lower minimum bandwidth associated therewith as the wanted version of the media content (44), 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.

44. Resource manager according to any of claims 40 to 43, wherein the resource manager is a radio resource manager and is further configured to perform an assignment of communication resources of at least one base station to user entities to which the user entity at which the client operates, belongs.

45. Resource manager according to any of claims 40 to 44, wherein the resource manager is arranged within the user entity between a transceiver stage (70) thereof, and the client (40), wherein the resource manager is configured to obtain the current resource situation information from the transceiver stage (70).

46. Resource manager according to any of claims 40 to 45, further configured to simulate a buffering state associated with the client (40) 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 buffering state.

47. Radio resource manager configured to assign communication resources of a base station (32) to user entities (34) depending on media buffering state information of a client operating at one of the user entities.

48. Radio resource manager according to claim 47, further configured to perform the assignment of the communication resources to the user entities based on one or more of

• a number of user entities (34) to which the communication resources of the base station (32) have to be assigned at an appropriate ratio,

• a sort of communication data to be exchanged between the user entities and the base station,

• user profiles assigned to the user entities, the profiles defining a priority ranking among the user entities,

• channel quality feedback from the user entities, and

• channel rate requests from the user entities.

49. Radio resource manager according to claim 48, further configured to, in assigning the communication resources to the user entities, adjust one or more of

• subcarriers,

• aggregated subcarriers,

• time slots, and

• a spatial coverage of the base stations cell,

depending on the media buffering state information.

50. Radio resource manager according to any of claims 47 to 49, further configured to extract the media buffering state information from an explicit signalization within a data traffic from the client (40) to the server (42), or derive the media buffering state information by simulating a buffering state associated with the client (40) based on channel quality feedback from the user entity (34) to the base station (32).

51. Radio resource manager configured to

survey data traffic between clients (40) operating at user entities (34), and one or several servers (32);

check as to whether there are media presentation descriptions within the data traffic from the one or several servers (32) to different ones of the clients (40), which relate to a common media content (44),

wherein the radio resource manager is configured to, depending on the check, offer to the clients (40) a multicast version of the common media content (44), besides unicast versions of the media content (44); or the radio resource manager is configured to, depending on the check, cause a change of a protocol for clients (40) downloading the common media content from a unicast protocol to a multicast protocol.

52. Radio resource manager according to claim 51, further configured to assign communication resources of a base station to the user entities.

53. Radio resource manager configured to assign communication resources of at least one base station (32) to user entities (34), wherein the radio resource manager is configured to

survey a data traffic to a server (42) or a client (40) operating at one of the user entities (34) 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 (42) and the client (40) operates on, or

a buffer state of the other of the server (42) and the client (40), and

perform the assignment depending on the information obtained.

54. Radio resource manager according to claim 53, further configured to, in assigning the communication resources of the at least one base station (32) to the user entities (34), assign guaranteed communication resources to the user entities (34) in units of time intervals, and to obey the guaranteed communication resources in assigning the communication resources within said time intervals.

55. Radio resource manager according to claim 54, further configured to insert information on the guaranteed communication resources assigned to the user entity which the one of the server (42) and the client (40) operates on, into data traffic from the server (42) or client (40) operating the at one of the user entities (32).

56. Radio resource manager according to claim 53 or 54, further configured to

responsive to a set-up of a media transmission session between the server or client operating on the one of the user entity, and the other of the server and client, checking as to whether the other of the server and client operates on an external user entity which is served by any other radio resource manager of a radio system to which the radio resource manager belongs;

if the other of the server and client operates on an external user entity which is served by any other radio resource manager of the radio system,

sending outbound control information signaling

guaranteed communication resources currently assigned to the user entity, or

a buffer state of the one of the server (42) and the client (40),

to the other radio resource manager of the radio system, and

surveying inbound control information signaling the information on

the guaranteed communication resources currently assigned to the external user entity which the other of the server (42) and the client (40) operates on, or

the buffer state of the other of the server (42) and the client (40),

from the other radio resource manager of the radio system.

57. Radio resource manager according to any of claims 53 to 56, further configured to perform the assignment of the communication resources to the user entities based on one or more of

• a number of user entities (34) to which the communication resources of the at least one base station (32) have to be assigned at an appropriate ratio,

• a sort of communication data to be exchanged between the user entities and the at least one base station,

• user profiles assigned to the user entities, the profiles defining a priority ranking among the user entities,

• channel quality feedback from the user entities, and

• channel rate requests from the user entities.

58. Radio resource manager according to any of claims 53 to 57, further configured to, in assigning the communication resources to the user entities, adjust one or more of

• subcarriers,

• time slots, and

• a spatial coverage of the at least one base station's cell.

59. Radio resource manager according to any of claims 53 to 58, configured to perform the assignment depending on the information obtained such that

the communication resources assigned to the user entity decrease if the buffer state of the other of the server (42) and the client (40) increases; and/or

the communication resources assigned to the user entity decrease if the guaranteed communication resources currently assigned to the external user entity decreases.

60. Method for radio resource managing comprising

assigning communication resources of at least one base station (32) to user entities (34) depending on a media presentation description (46) relating to a media content (44) transferred within a data traffic from a server (42) to a client (40) with one of the server (42) and the client (40) operating at one of the user entities (32).

61. Method for being performed on a user entity on which a client (40) or server (32) is operative, the user entity communicating with a radio resource base station (32), the method comprising

surveying a data traffic to/from the client (40) or server (32) so as to derive a media presentation description (46) describing versions of differing bandwidths of a media content (44), and

forwarding, at least partially, the media presentation description to a radio resource manager (30) responsible for assigning the communication resources of the radio resource base station (32) to user entities to which the user entity belongs.

62. Method for being performed on a user entity on which a client (40) is operative, the user entity communicating with a radio resource base station (32), the method comprising

determining a received media content throughput or buffer state of a media content retrieved by the client from a server (42) and

informing a radio resource manager (30) responsible for assigning the communication resources of the radio resource base station (32) to the user entity, on the determined media content throughput or buffer state.

63. Method comprising

inspecting a media presentation description (46) describing versions of a media content (44) of differing bandwidths, within a data traffic from a server (42) to a client (40) operating at a user entity (34);

inspecting a media request (60) from the client (40) to the server (42), requesting a wanted version of the media content (44); and

deciding, depending on a current resource situation information and the media presentation description (46),

to forward the media request (60) to the server, or, alternatively,

to cause that the media request (60) does not lead to the wanted version of the media content (44) being sent to the client (40).

64. Method comprising

inspecting a media presentation description (46) describing versions of a media content (44) of differing bandwidths, within a data traffic from a server (42) to a client (40) operating at a user entity (34);

inspecting a media request (60) from the client (40) to the server (42), requesting a wanted version of the media content (44);

obtaining an user entity's buffering state for the client by simulating same based on channel quality feedback from the user entity (34) to the base station (32) or a monitoring of a media content buffer (100) positioned on the other side of the base station (32) or within the base station (32), or extracting the user entity's buffering state from an explicit signalization within a data traffic from the client (40) to the server (42); and

deciding, depending on the user entity's buffering state and the media presentation description (46),

to forward the media request (60) to the server, or, alternatively,

to cause that the media request (60) does not lead to the wanted version of the media content (44) being sent to the client (40).

65. Method configured to

inspecting a media presentation description request from a client (40) operating at a user entity (34) to a server (42), the media presentation description request requesting a media presentation description (46) from the server (42), the media presentation description (46) describing versions of a media content (44) of differing bandwidths;

inspecting the media presentation description (46) within a data traffic from the server (42) to the client (40);

deciding, based on a current resource situation information and the media presentation description (46),

to forward the media presentation description (46) to the client (40) as an answer to the media presentation description request, or

to intercept the media presentation description (46), and modify the media presentation description.

66. Method for Radio resource managing, comprising

surveying data traffic between clients (40) operating at user entities (34), and one or several servers (32);

checking as to whether there are media presentation descriptions within the data traffic from the one or several servers (32) to different ones of the clients (40), which relate to a common media content (44),

depending on the check, offer to the clients (40) a multicast version of the common media content (44), besides unicast versions of the media content (44); or depending on the check, causing a change of a protocol for clients (40) downloading the common media content from a unicast protocol to a multicast protocol.

67. Method for assign communication resources of at least one base station (32) to user entities (34), the method comprising

surveying a data traffic to a server (42) or a client (40) operating at one of the user entities (34) 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 (42) and the client (40) operates on, or

a buffer state of the other of the server (42) and the client (40), and

performing the assignment depending on the information obtained.

68. Computer program having a program code for performing, when running on a

computer, a method according to any of claims 60 to 67.

Documents

Orders

Section Controller Decision Date

Application Documents

# Name Date
1 201938047370-IntimationOfGrant09-01-2024.pdf 2024-01-09
1 201938047370-STATEMENT OF UNDERTAKING (FORM 3) [20-11-2019(online)].pdf 2019-11-20
2 201938047370-FORM 1 [20-11-2019(online)].pdf 2019-11-20
2 201938047370-PatentCertificate09-01-2024.pdf 2024-01-09
3 201938047370-Information under section 8(2) [14-12-2023(online)].pdf 2023-12-14
3 201938047370-FIGURE OF ABSTRACT [20-11-2019(online)].pdf 2019-11-20
4 201938047370-Written submissions and relevant documents [14-12-2023(online)].pdf 2023-12-14
4 201938047370-DRAWINGS [20-11-2019(online)].pdf 2019-11-20
5 201938047370-DECLARATION OF INVENTORSHIP (FORM 5) [20-11-2019(online)].pdf 2019-11-20
5 201938047370-Correspondence to notify the Controller [23-11-2023(online)].pdf 2023-11-23
6 201938047370-FORM-26 [23-11-2023(online)].pdf 2023-11-23
6 201938047370-COMPLETE SPECIFICATION [20-11-2019(online)].pdf 2019-11-20
7 201938047370-Information under section 8(2) [01-11-2023(online)].pdf 2023-11-01
7 201938047370-FORM 18 [05-12-2019(online)].pdf 2019-12-05
8 201938047370-US(14)-ExtendedHearingNotice-(HearingDate-30-11-2023).pdf 2023-10-30
8 201938047370-Proof of Right (MANDATORY) [19-12-2019(online)].pdf 2019-12-19
9 201938047370-FORM 3 [04-08-2023(online)].pdf 2023-08-04
9 201938047370-Information under section 8(2) (MANDATORY) [16-01-2020(online)].pdf 2020-01-16
10 201938047370-FORM-26 [20-02-2020(online)].pdf 2020-02-20
10 201938047370-REQUEST FOR ADJOURNMENT OF HEARING UNDER RULE 129A [04-08-2023(online)].pdf 2023-08-04
11 201938047370-Information under section 8(2) [04-04-2020(online)].pdf 2020-04-04
11 201938047370-US(14)-HearingNotice-(HearingDate-11-08-2023).pdf 2023-07-21
12 201938047370-Information under section 8(2) [17-07-2023(online)].pdf 2023-07-17
12 201938047370-Information under section 8(2) [22-09-2020(online)].pdf 2020-09-22
13 201938047370-Information under section 8(2) [10-10-2020(online)].pdf 2020-10-10
13 201938047370-Information under section 8(2) [26-05-2023(online)].pdf 2023-05-26
14 201938047370-Information under section 8(2) [01-12-2020(online)].pdf 2020-12-01
14 201938047370-Information under section 8(2) [30-03-2023(online)].pdf 2023-03-30
15 201938047370-FORM 3 [17-02-2023(online)].pdf 2023-02-17
15 201938047370-Information under section 8(2) [12-04-2021(online)].pdf 2021-04-12
16 201938047370-Information under section 8(2) [17-11-2022(online)].pdf 2022-11-17
16 201938047370-Information under section 8(2) [30-06-2021(online)].pdf 2021-06-30
17 201938047370-Information under section 8(2) [14-11-2022(online)].pdf 2022-11-14
17 201938047370-Information under section 8(2) [14-09-2021(online)].pdf 2021-09-14
18 201938047370-FER.pdf 2021-11-03
18 201938047370-FORM 3 [19-08-2022(online)].pdf 2022-08-19
19 201938047370-ABSTRACT [02-08-2022(online)].pdf 2022-08-02
19 201938047370-Information under section 8(2) [03-12-2021(online)].pdf 2021-12-03
20 201938047370-CLAIMS [02-08-2022(online)].pdf 2022-08-02
20 201938047370-Information under section 8(2) [02-02-2022(online)].pdf 2022-02-02
21 201938047370-DRAWING [02-08-2022(online)].pdf 2022-08-02
21 201938047370-FORM 3 [08-02-2022(online)].pdf 2022-02-08
22 201938047370-FER_SER_REPLY [02-08-2022(online)].pdf 2022-08-02
22 201938047370-Information under section 8(2) [09-02-2022(online)].pdf 2022-02-09
23 201938047370-FORM 4(ii) [25-04-2022(online)].pdf 2022-04-25
23 201938047370-OTHERS [02-08-2022(online)].pdf 2022-08-02
24 201938047370-Information under section 8(2) [22-07-2022(online)].pdf 2022-07-22
25 201938047370-OTHERS [02-08-2022(online)].pdf 2022-08-02
25 201938047370-FORM 4(ii) [25-04-2022(online)].pdf 2022-04-25
26 201938047370-FER_SER_REPLY [02-08-2022(online)].pdf 2022-08-02
26 201938047370-Information under section 8(2) [09-02-2022(online)].pdf 2022-02-09
27 201938047370-DRAWING [02-08-2022(online)].pdf 2022-08-02
27 201938047370-FORM 3 [08-02-2022(online)].pdf 2022-02-08
28 201938047370-CLAIMS [02-08-2022(online)].pdf 2022-08-02
28 201938047370-Information under section 8(2) [02-02-2022(online)].pdf 2022-02-02
29 201938047370-ABSTRACT [02-08-2022(online)].pdf 2022-08-02
29 201938047370-Information under section 8(2) [03-12-2021(online)].pdf 2021-12-03
30 201938047370-FER.pdf 2021-11-03
30 201938047370-FORM 3 [19-08-2022(online)].pdf 2022-08-19
31 201938047370-Information under section 8(2) [14-09-2021(online)].pdf 2021-09-14
31 201938047370-Information under section 8(2) [14-11-2022(online)].pdf 2022-11-14
32 201938047370-Information under section 8(2) [17-11-2022(online)].pdf 2022-11-17
32 201938047370-Information under section 8(2) [30-06-2021(online)].pdf 2021-06-30
33 201938047370-FORM 3 [17-02-2023(online)].pdf 2023-02-17
33 201938047370-Information under section 8(2) [12-04-2021(online)].pdf 2021-04-12
34 201938047370-Information under section 8(2) [01-12-2020(online)].pdf 2020-12-01
34 201938047370-Information under section 8(2) [30-03-2023(online)].pdf 2023-03-30
35 201938047370-Information under section 8(2) [10-10-2020(online)].pdf 2020-10-10
35 201938047370-Information under section 8(2) [26-05-2023(online)].pdf 2023-05-26
36 201938047370-Information under section 8(2) [22-09-2020(online)].pdf 2020-09-22
36 201938047370-Information under section 8(2) [17-07-2023(online)].pdf 2023-07-17
37 201938047370-Information under section 8(2) [04-04-2020(online)].pdf 2020-04-04
37 201938047370-US(14)-HearingNotice-(HearingDate-11-08-2023).pdf 2023-07-21
38 201938047370-FORM-26 [20-02-2020(online)].pdf 2020-02-20
38 201938047370-REQUEST FOR ADJOURNMENT OF HEARING UNDER RULE 129A [04-08-2023(online)].pdf 2023-08-04
39 201938047370-FORM 3 [04-08-2023(online)].pdf 2023-08-04
39 201938047370-Information under section 8(2) (MANDATORY) [16-01-2020(online)].pdf 2020-01-16
40 201938047370-Proof of Right (MANDATORY) [19-12-2019(online)].pdf 2019-12-19
40 201938047370-US(14)-ExtendedHearingNotice-(HearingDate-30-11-2023).pdf 2023-10-30
41 201938047370-FORM 18 [05-12-2019(online)].pdf 2019-12-05
41 201938047370-Information under section 8(2) [01-11-2023(online)].pdf 2023-11-01
42 201938047370-FORM-26 [23-11-2023(online)].pdf 2023-11-23
42 201938047370-COMPLETE SPECIFICATION [20-11-2019(online)].pdf 2019-11-20
43 201938047370-DECLARATION OF INVENTORSHIP (FORM 5) [20-11-2019(online)].pdf 2019-11-20
43 201938047370-Correspondence to notify the Controller [23-11-2023(online)].pdf 2023-11-23
44 201938047370-Written submissions and relevant documents [14-12-2023(online)].pdf 2023-12-14
44 201938047370-DRAWINGS [20-11-2019(online)].pdf 2019-11-20
45 201938047370-Information under section 8(2) [14-12-2023(online)].pdf 2023-12-14
45 201938047370-FIGURE OF ABSTRACT [20-11-2019(online)].pdf 2019-11-20
46 201938047370-PatentCertificate09-01-2024.pdf 2024-01-09
46 201938047370-FORM 1 [20-11-2019(online)].pdf 2019-11-20
47 201938047370-IntimationOfGrant09-01-2024.pdf 2024-01-09
47 201938047370-STATEMENT OF UNDERTAKING (FORM 3) [20-11-2019(online)].pdf 2019-11-20

Search Strategy

1 S4-100783_IMS_HTTP_StreamingE_30-10-2021.pdf
1 searchstrategyE_30-10-2021.pdf
2 S4-100783_IMS_HTTP_StreamingE_30-10-2021.pdf
2 searchstrategyE_30-10-2021.pdf

ERegister / Renewals

3rd: 13 Feb 2024

From 22/10/2014 - To 22/10/2015

4th: 13 Feb 2024

From 22/10/2015 - To 22/10/2016

5th: 13 Feb 2024

From 22/10/2016 - To 22/10/2017

6th: 13 Feb 2024

From 22/10/2017 - To 22/10/2018

7th: 13 Feb 2024

From 22/10/2018 - To 22/10/2019

8th: 13 Feb 2024

From 22/10/2019 - To 22/10/2020

9th: 13 Feb 2024

From 22/10/2020 - To 22/10/2021

10th: 13 Feb 2024

From 22/10/2021 - To 22/10/2022

11th: 13 Feb 2024

From 22/10/2022 - To 22/10/2023

12th: 13 Feb 2024

From 22/10/2023 - To 22/10/2024

13th: 13 Feb 2024

From 22/10/2024 - To 22/10/2025

14th: 30 Sep 2025

From 22/10/2025 - To 22/10/2026