KR20050057682A - Reporting for multi-user services in wireless networks - Google Patents

Abstract

The basic idea of the present invention is to adapt multi-user multimedia data in a communication system with a server providing the multi-user multimedia data to clients and with an intermediate network part. Said intermediate network part is arranged to provide information on communication between the server and the clients. The server sends multimedia data to the clients. Distribution characteristics are determined for the clients, which are considered by the generation of an aggregated feedback report on the clients' reception conditions of the multimedia data in the intermediate network part. Said feedback report includes additional information about aggregation fashion. Said aggregated feedback report is sent to the server in order the server adapts the transmission of the multimedia data from the server to the clients according to the aggregated feedback report.

Description

Reporting for Multi-User Services in Wireless Networks

The present invention relates to a method for performing multicast in a mobile communication network.

In particular, the present application can be applied in a point-to-point packet-switched telecommunication network.

Universal Mobile Telecommunications Systems (UMTS) are being developed to provide wireless broadband multimedia services using the Internet protocol. UMTS, a third-generation (3G) mobile communication, combines streaming with unique services such as, for example, geographical positioning, to provide high-quality Internet content to a user. Image, voice, audio and video content are examples of mobile multimedia services delivered to users through media streaming and download technologies. This means that whenever content is placed on a media server, an on-demand can be delivered via download or streaming. To download the content, the user clicks on a link, waits for the content to download and starts playing. Since hypertext transfer protocol (HTTP) can be used to download files, the download capability is easy to integrate. To access streaming data or general speaking multimedia data, the user clicks on a link to begin playback almost immediately. Because streaming is a semi-real-time service that receives and plays data at the same time, it is larger in protocol and service implementation, especially when operating over networks with low or no quality of service, as in universal mobile telecommunications systems (UMTS). Give demand. The radio resource used at the end of the transmission will be used in a good way.

The current work is to introduce broadcasting and multicasting into WCDMA and GSM wireless networks. Both broadcast and multicast provide transport efficiency and reduce the load on content servers such as streaming servers, for example. In addition, solutions will be calculated to perform streaming or general formulated multimedia transmission in wireless networks. In the following, a corresponding structure is described.

1 shows a so-called current multimedia broadcast / multicast service (MBMS) architecture. In the following only examples of different access networks, such as UTRAN, GERAN, which connect the most important nodes and end users (UEs) are mentioned. The access network is handled by the GGSN, which is responsible for connecting external networks such as SGSN and the Internet, which are serving nodes that communicate with the edge nodes. The BM-SC entity connected to the GGSN is responsible for providing multicast / broadcast, for example for bearer establishment and data forwarding. The BM-SC provides an interface to the content provider so that the content provider can request data delivery to the user. The BM-SC may authorize the content provider and charge the content provider.

As a simple solution, it seems that at the moment only the downlink channel is supported in the portion of the wireless network for data traffic to end users. This means that there is no uplink channel in the access network that can be used by the end user (UE), for example, to send a report considering the reception quality.

Transmission of multimedia flows for a single user is performed in the wireless network by means of a packet switched streaming structure. The structure is shown in FIG. This shows a streaming client that is connected with a UMTS Core network via an access network such as UTRAN or GERAN. In the Universal Mobile Telecommunications System (UMTS), two important types of nodes are shown, SGSN and GGSN. SGSN is a serving node for handling users added to the access network. GGSN is responsible for connecting to external networks such as IP networks. For the purpose of providing multimedia, there are several other entities in an IP network, such as a content server, which is responsible for providing the multimedia data.

Multimedia data is distributed by a multimedia protocol. 3 shows a protocol stack with real-time transport protocol (RTP), which is the protocol layer responsible for multimedia transmission. Real-time transport protocol (RTP) is not as reliable as the case of Universal Datagram Protocol (UDP), but because it provides fast transmission, it is a suitable transport protocol for the transmission of streaming data. Use the Universal Datagram Protocol (UDP). HTTP and Real-Time Streaming Protocol (RTSP) run on Reliable Transmission Control Protocol (TCP). Real-Time Streaming Protocol (RTSP) provides session control for streaming sessions. HTTP is used for the transmission of still images, bitmaps, graphics and text.

Real-time transport protocol (RTP) is an end-to-end network transport feature suitable for applications that transmit real-time data such as audio, video, or simulation data over multicast or unicast network services. to-end network transport function. The functions provided by real-time transfer protocol (RTP) include payload type identification, sequence numbering, timestamping and delivery monitoring. Real-time transfer protocol (RTP) is used to monitor QoS and convey information about the participants of an ongoing session, including the related RTP control protocol (RTCP), which enhances data transfer. Each media stream of a conference is transmitted as a separate real-time transport protocol (RTP) session along with a separate RTCP control stream.

The Real-Time Transfer Protocol (RTP) adds a timestamp and sequence number to the Universal Datagram Protocol (UDP) packet of each particular Real-Time Transfer Protocol (RTP) header. The time stamp relates to the presentation or composition time of the media carried in the payload of a sampling or real-time transfer protocol (RTP) packet. This is used in conjunction with the RTP Control Protocol (RTCP) to play media at the correct rate and to synchronize the presentation of other streaming media. Payload specifications define the description of time stamps and other real-time transfer protocols (RTPs). The recipient uses the sequence number to detect packet loss statistics based on the fact that the loss can be reported to the server by the RTCP.

 The RTCP report provides statistics on data received from preceding sources, such as the number of packets lost, cumulative number of packets lost, interarrival jitter, etc., since the preceding report. Additional drafts define the format for extension in RTCP transmitter and receiver reports. A detailed description of the RTCP can be found in FRC 1889, Chapter 6. RTCP is based on the periodic transmission of control packets to all participants in a session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of data and control packets, for example using separate port numbers in conjunction with Universal Datagram Protocol (UDP).

The primary function of the RTCP is to provide feedback depending on the quality of the data distribution. It is an integral part of the role of the transport protocol, the real-time transport protocol (RTP), and relates to the flow and congestion control functions of other transport protocols. The feedback can be used directly to identify the cause of the variance faults. The transmission of the received feedback report to all participants allows the observer to assess whether the problem is local or overall. By using a distributed mechanism such as IP multicast, for entities such as network service providers who are not involved in the session to receive feedback information and act as a third-party monitor to identify the cause of network problems. It is also possible. This feedback function is performed by the RTCP transmitter and receiver reports. Since the RTP Control Protocol (RTCP) specification requires every participant to send an RTCP packet, the rate should be controlled to be increased for real-time transfer protocol (RTP) to multiple participants. By having each participant send control packets to all others, each can keep the number of participants independent. This number is used to calculate the rate at which packets are sent.

Moreover, the RTCP has an optional function for conveying minimal session control information such as, for example, participant identification to be presented in the user interface. This will most likely be used in sessions where participants enter and leave without membership control or parameter negotiation. RTCP is used as a convenient channel for reaching all participants but is not necessarily expected to support all the control communication needs of the application. There may be a need for higher-level session control protocols beyond the aspects of this specification.

In addition to the last function being optional, the functions described above are mandatory and recommended for all environments when real-time transport protocol (RTP) is used in an IP multicast environment.

Therefore, the multimedia service of the wireless network will be used for a single user, so-called unicast connection as well as a group of users, so-called point-to-multipoint or multipoint-to-multipoint connection. Point-to-multipoint services demand high demands on the network infrastructure and consume significant amounts of bandwidth. Some examples of such services are video-conferencing, whiteboarding, real-time multi-user games, multimedia messages, virtual worlds, and the like. This type of multimedia application is used for transport broadcast or multicast mode. Broadcast has the potential to address packets for all destinations by using special codes in the address field. When a packet with this code is sent, it is received and processed by all users of the network. This mode of operation is called broadcasting. Multicasting supports sending to a subset of users. Each can register to a multicast group. When a packet is sent to a particular group, it is delivered to all users registered with that group.

The RTP Control Protocol (RTCP) has a mechanism for reporting in the case of multicast sessions. However, in the case of wireless networks, multicast reporting wastes air interface resources and potentially overloads network servers. Furthermore, the preferred multicast solution has only the downlink and no uplink channel. This means that the user cannot send an RTCP report to the source.

In RFC 1889, an entity, a so-called mixer, is introduced. The mixer receives real-time transport protocol (RTP) packets from one or more sources, possibly alters the data format, combines the packets in some way and then delivers the new real-time transport protocol (RTP) packets. Since the time between multiple input sources is generally not synchronized, the mixer makes time adjustments between the streams and generates its own time for the combined stream. Thus, all data packets originating from the mixer will be identified by having a mixer that is its synchronization source. Therefore, the mixer creates a new message that is a combination of the received messages.

However, the use of RTCP receiver reports for the current real-time transport protocol (RTP) is mandatory in multicast sessions. In particular, it is important for the multicast transmitter to receive reports that the client is still listing as a signal. The current revision of the Real-Time Transfer Protocol (RTP) provides a feature for suppressing the use of RTCP receiver reports. However, by omitting an RTCP receiver report, an important means of obtaining quality feedback from the receiver is also omitted. The source is not adaptable to changing conditions and cannot provide alternative streams.

In any case, if the RTCP report from a single client indicates that some real-time transport protocol (RTP) frames are faulty or lost, and that the client should be used with a lower data rate, what does the source do? It may be a question of what to do. This is a big problem, especially in wireless networks where heterogeneous users are increasing. Multimedia users are characterized by a variety of mobile terminals with a wide range of display sizes and capabilities. In current multicast solutions, the source will either ignore this report or adapt to the slowest receiver. Both are not suitable when the client is charged for the service and the bearer used for the service. In addition, several different radio-access networks make multiple maximum-access link speeds available. Because of the physical nature of cellular wireless networks, the quality and hence the data rate of an ongoing connection will vary, contributing to heterogeneous problems.

Therefore, the following problem occurs in consideration of RTCP reporting in a multicast session of a wireless network. Inadequate radio resources are inefficiently used when all users send RTCP reports. This can also cause overloading of servers, such as RNC, SGSN, GGSN, for example in a football stadium, if the report is generated by a large number of users. Because of heterogeneous networks, the source has to adapt to the fewest users. Moreover, because of the large number of reports and the long time needed for evaluation of the reports, long delays occur before the source recognizes the problem. Moreover, the RTCP report does not contain all the necessary information for the wireless network.

Figure 1: Broadcast / Multicast Service (MBMS) Architecture

Figure 2: Packet Switched Streaming (PSS) Structure

Figure 3: Protocol stack with protocol layer for streaming transmission

4: Protocol model for the present invention

5 an embodiment of the invention for determining distribution characteristics associated with a client

6 is an embodiment of the present invention for generating a feedback report collected for each mobile terminal;

7 an embodiment of the present invention for generation of a feedback report collected per cell

It is an object of the present invention to provide a solution for the efficient use of a wireless interface for multi-user multimedia services in a wireless network.

The invention is embodied in the manner described in claims 1, 18. Advantageous embodiments are described in the dependent claims.

The basic idea is to adapt to the multi-user multimedia data of a communication system having a server and an intermediary network portion that provides the client with multi-user multimedia data. The intermediate network portion is configured to provide information in accordance with the communication between the server and the client. The server sends the multimedia data to the client. For the client, the distribution characteristics considered by the generation of feedback reports collected in accordance with the client reception conditions of the multimedia data in the intermediate network portion are determined. The feedback report includes additional information about the aggregation fashion. The collected feedback report is sent to the server in an order that the server adapts to the transmission of multimedia data from the server to the client in accordance with the collected feedback report.

An advantage of the present invention is that it provides efficient use of scarce and expensive network resources in wireless networks, especially in the uplink direction. The present invention is accomplished so that radio resources are utilized in a good way because the reports are related to more than one user. In the case of one user, the source needs to perform multiple reporting analyzes for multiple user sessions. This is a waste of resources, especially if members can be classified into one or a few access networks with very similar characteristics and behavior. Moreover, this will reduce the load and complexity of the source. This solution provides the only way of reporting when uplink channels cannot be used, as in the broadcast solution. In addition, the collected RTCP reports can take into account all the information in the cell rather than a single dedicated RTCP report per client. For example, in most overload situations, the RNC knows before congestion crashes by losing frames and can report it as a source for all clients in the same cell. This will enhance the quality experience for the end-user. Moreover, reporting in general is faster because the air interface delay is skipped. This is very much the same as in the single-user multimedia case.

In one embodiment of the present invention, the distributed characteristic relates to a geographical area comprising a group of clients. As limited to wireless communication networks, one or more cells may design a geographic area.

In another embodiment, the distributed feature relates to a given multicast group structure, which may include a client having an apparatus for receiving data transmitted at high or low speeds.

In a preferred embodiment, the distribution characteristic relates to information received from radio resource management. Radio resource management has actual information regarding the current transmission performance according to the air interface. Therefore, it is desirable to consider this information when generating a feedback report.

Interaction between the intermediary node and radio resource management may be performed frequently or event-centrically.

In another embodiment, the distribution characteristic relates to information received from a client. To improve the quality of the collected feedback report, the client sends its report. The advantage of this solution is that the collected feedback report contains information that cannot be determined from the distributed characteristics derived from the wireless layer.

The information received from the client is proposed to be sent frequently or event-centricly, for example when an extraordinary event occurs.

The feedback report from the client is preferably suppressed at the client's terminal. The advantage of this embodiment is that there is no traffic produced on the uplink channel to save radio resources. In particular, in the absence of an uplink channel, one can use this which is the preferred solution.

In addition, it is advantageous to receive information from the radio resource management and client with actual information regarding the current radio resource availability and to combine the information to generate a more accurate feedback report to the server.

In a preferred embodiment of the present invention, the additional information about the collection fashion includes a plurality of clients to which the collected feedback report is applied so that the server can distinguish when the report is applied to one client or a group of clients. Based on this information, for example, it can be determined according to the appropriate behavior whether adaptation is useful or whether replication of the actual stream is more appropriate.

In another preferred embodiment of the present invention, the additional information about the collecting fashion includes the radio characteristics of the access network with the client. With this information, the server can distinguish how to adapt to the multimedia flow, taking into account the specific characteristics of the different access networks.

It is also proposed that the collected feedback report contain information for the server about the adaptation method. Thus, the server receives additional information to make a good decision as to how the stream can be adapted.

Negotiation is preferably performed according to the frequency of the feedback report from the client and / or radio resource management to the intermediate node. This can be at fixed intervals or event-centric, meaning when certain circumstances occur.

In an advantageous embodiment, the client refrains from receiving the data stream and sending a feedback report to other clients such that the anonymity of the multimedia client with which the multimedia data is multicast is assured.

In a preferred embodiment of the present invention, the generated and collected feedback report includes a fraction of lost packets provided by the intermediary node according to the current conditions of delivery. This fraction may be the highest sequence number the intermediate node has received or the arrival interval jitter provided by the intermediate node.

The server receiving the collected feedback report is proposed to run in an appropriate manner. For example, the server adapts accordingly to the information contained in the report taking into account the percentage of clients to which the feedback applies is utilized. The response may inform the client of a new channel or adapt to the stream, for example to reduce the bit rate or switch to a more reliable codec.

In addition, it is proposed to implement the functions of the intermediate network part in the same network part. In an alternative solution, it is proposed to divide the function between several different nodes forming part of the intermediary network.

Embodiments of the present invention are based on real-time transfer protocol (RTP) with RTP control protocol (RTCP) for reporting feedback. However, the present invention will not be limited to this example of a multimedia protocol.

Moreover, the present invention describes an intermediary network portion that is adapted to perform adaptation of multi-user multimedia data in a communication system having a server for providing multi-user multimedia data to a client. The intermediate network portion is configured to provide information in accordance with the communication between the server and the client. It includes means for transferring multimedia data from the server to the client. The means for determining the distribution characteristic associated with the client is part of the intermediary network part. The task of the means is to determine from the radio resource management, for example, access to the lower layer which transmission condition the multimedia is sent to the client.

Moreover, the intermediary network portion node has means for generating a feedback report collected according to the client reception condition of the multimedia data in consideration of the distribution characteristic, wherein the feedback report includes additional information about the fashion of collection. The feedback report generated in this way is sent to the server by means for sending the collected feedback report.

It is proposed that the means of the intermediate network part be implemented in the same network node. Alternatively, it is proposed that the means for determining the distribution characteristic associated with the client and the means for generating the collected feedback report are divided among several different nodes. In the last case, it is required to provide a means for receiving external decision distribution characteristics associated with the client.

Detailed description of the present invention is given below.

In the following, the present invention is described with respect to a wireless network using real-time transfer protocol (RTP). Intermediate nodes and intermediary network parts are used as synonyms.

The basic idea is to have an intermediary network portion in the wireless network that handles the gathered RTCP reporting, rather than each user performing his own reports. The intermediate network portion, hereinafter described as an intermediate node, describes the functionality that can be implemented in one node or the functionality that can be partitioned between several different network nodes.

For example, for each multicast group, a collected RTCP reporting or one general feedback report is generated. Real-time determination of the dispersion characteristic is performed taking into account the cell and group structure associated with the characteristic determination. The generation of the feedback report is based on the real time determination of the distribution characteristic, the feedback report comprising additional information including, for example, the number of users to which the feedback report is applied. The feedback report is sent to a server that is a multicast source, utilizing the group feedback report by considering the percentage of users to which the feedback report is applied. Multicast / broadcast transmissions are adapted according to the feedback report utilized. Furthermore, arbitrarily, intermediary nodes are proposed to the multicast source according to how it adapts to the stream for the corresponding group of users, for example only multiple unicast is proposed if it is possible or a handover overlay cell. Or another access network may be proposed. This is because the RNC, which can provide specific data to the intermediary node, may have information such as, for example, the radio characteristics of the cell area, since it does not have the source and will determine whether the stream can be adapted in good circumstances. Can be. By way of example, RTCP generally indicates that the reception quality is not good, triggering the source to fall to the bit rate for the next lower level. The RNC, which determines many session settings per nearly overloaded cell and time unit, may indicate that the bit rate should be reduced.

By receiving the collected feedback report, the source utilizes the information contained in the report taking into account the percentage of clients to which the feedback is applied. The reaction may inform the client of a new channel or allow the stream to adapt, for example, to reduce the bit-rate or switch to a more reliable codec.

Generate an RTCP receiver report at an intermediary node that suppresses the client from sending an RTCP receiver report and hides the receiver of the entire cell. The intermediary node obtains information from the RNC and generates an RTCP report from it. In addition, RTCP packets with special radio information can be used and removed at the RTCP generating node, which is an intermediate node.

Furthermore, this may be important for the remaining users and / or sources, as the RTCP report may optionally include the actual end-user address in addition to the number of users.

A description is given below with respect to FIG. 4.

4 shows a protocol model for the present invention. This illustrates a multicast source for transmitting multimedia data to a client by means of a real-time transport protocol (RTP) transmitter message, not shown in the figure. The protocol stack of a multicast source includes a Real-Time Transfer Protocol (RTP) with a Universal Datagram Protocol (UDP) and a corresponding RTP Control Protocol (RTCP) layer overlying the IP protocol. L2 is a general description of the link layer, which depends on the network over which data is sent. The corresponding protocol stack is shown in the multicast receiver on the receiver side. However, the link layer is described for a wireless network in the case of a radio link protocol using a radio resource control (RRC) protocol. According to the present invention, there is an intermediary node, which is part of an intermediary network that lies between the multicast source and the multicast receiver. Several different options for generating the collected feedback report are shown in FIG.

It is possible that the intermediary node does not receive certain information from the client. That means that RTCP reporting over the air interface cannot be used. Generation of an RTCP feedback report is performed from scratch of the intermediary node based on the received real-time transport protocol (RTP) stream and the radio resource management (RRM) knowledge of the particular cell or region. The communication link 10 is used for the purpose of receiving radio resource management (RRM) information. This information may be sent frequently or on an event-based basis. Because the client suppresses the transmission of RTCP reports according to the Real-Time Transport Protocol / RTP Control Protocol (RTP / RTCP) level and because all RTCP reports are blocked at the client's terminal, No report is sent from the client.

In certain situations, a client may send an RTCP report according to a unicast uplink channel, event-driven reporting according to a communication link between the multicast receiver and the intermediate node. That means that even if the report is suppressed or blocked at the client's terminal, there is an option to send only an RTCP report with specific information, which means that it is not constant that the RTCP report is sent. Means that. Only in the case of extraordinary events, RTCP reporting is done. If a report is suppressed at the client's terminal, it is processed according to the RTCP level. If the report is blocked at the client, the terminal will have to remove certain RTCP reports. RTCP reports are considered temporary, which are service and access network dependencies, and may be subject to negotiations between the source and destination and / or between the access network and destination. For example, a temporary RTP report may be generated when the loss rate exceeds a certain threshold. At that time, the RTCP report is used as an additional input to form the collected RTCP message.

Another option of the present invention is to suppress the transmission of RTCP reports to all multicast receivers in order to maintain anonymity between users. Usually, it is not of interest to the user receiving the information. In addition, this option reduces the downlink load on the network. Therefore, except for the transmitter report, the RTCP report is not transmitted in the downlink direction. This option is not shown in FIG. 4 because only one client is shown.

According to FIG. 5, an alternative for the determination of the distribution characteristic associated with a client is described below.

5 illustrates an alternative logical structure with a client in communication with the RNC. Moreover, the communication path goes to a so-called service node where feedback messages collected over the wireless and core networks are generated taking into account the network feedback received from the RNC. It means the functionality to obtain the necessary quality information at the cell level that physically partitions the RTCP report from the node compiling and transmitting. RTCP receiver reports are not sent from the mobile terminal client. The service node may be a special node or a function implemented in, for example, a GGSN or multimedia resource function (MRF), where the service node outside the mobile terminal core generates an RTCP receiver report. RTCP receiver reports may be sent per RNC or per cell.

Furthermore, the provision of per cell or per RNC RTCP report also increases the periodicity of the quality feedback information and allows the transmitter to adapt more quickly to changing conditions. The RTCP reporting interval may depend on the number of participants in the session.

The differently described solutions for different scenarios are described in more detail below.

One of the possible scenarios is a broadcast scenario characterized by radio access set-up with no uplink. This means that multicast datagrams are sent in the downlink direction and no client response is sent back. The lack of a return channel prevents RTCP feedback from being sent back from the client. An RTCP message may be generated, but there is no medium to convey it.

The idea for the broadcast scenario is that an RTP Control Protocol (RTCP) message is generated at the network node, for example, the RNC for WCDMA, which is basically a logical location for generating an RTCP report. . A new RTCP receiver report is generated based on radio related information. Therefore, the function of generating and transmitting an RTCP receiver report and the data collection function can be divided.

For the purpose of communication, the RTP Control Protocol (RTCP) defines several different RTP Control Protocol (RTCP) messages. In the following, one way of generating a collected message utilizing an RTCP message is described.

The RTP control protocol (RTCP) defines a transmitter report (SR), a receiver report (RR), a source description item (SDES), a bi-message (BYE), and an application specific function (APP). The messages can be bundled to form a so-called compound message. Especially for the present invention, a receiver report that needs to be received by a transmitter is important to adapt to changes in bandwidth conditions. Such receiver reports are proposed to be generated at the RNC based on the knowledge that the RNC has about the link conditions of one or more cells. The RNC can generate one message for each cell, that is, it is responsible for forming a single message for all.

Several other fields of the receiver report (RR) message are described below as defined in RFC 1884.

SSRC_n (source identifier) having 32 bits is the SSRC identifier of the source to which the information of this received report block belongs.

The lost field fraction with 8 bits is taken from the lost source SSRC_n since the preceding transmitter report (SR) or receiver report (RR) packet is represented and transmitted as a fixed point number. Describes the fraction of time transfer protocol (RTP) data packets.

The field cumulative number of lost packets with 24 bits is the total number of real-time transfer protocol (RTP) data packets from the source SSRC_n that have been lost since the start of reception.

The highest sequence number extended for the field. The 32 received bits are reused. The lower 16 bits extend the sequence number and corresponding count of the highest sequence number and sequence number cycle received in the real-time transfer protocol (RTP) data packet from the source SSRC_n.

There is also an arrival interval jitter field with 32 bits. Estimation of the statistical variable of RTP data packet arrival interval time is measured in timestamp and represented as an unsigned integer. Interval jitter is defined to be the average deviation (flexible absolute value) of the difference in the packets away from the receiver compared to the transmitter for a pair of packets.

The field of the last SR Timestamp (LSR) with 32 bits describes the most recent RTP Control Protocol (RTCP) Transmitter Report (SR) packet from the source SSRC_n. If the transmitter report SR has not yet been received, the field is set to zero.

The delay since last SR with 32 bits (DLSR) is a delay expressed in units of 1/65536 seconds between receiving the last transmitter report (SR) packet from the source SSRC_n and sending this reception report block. If a transmitter report (SR) packet has not yet been received from SSRC_n, the delay since last SR (DLSR) field is set to zero.

The value for the entry of the receiver report RR needs to be set for the purposes of the present invention for generating the collected feedback message.

The first known field is the simple transmitter ID. For the second field, which is the fraction of the lost packet, there are several alternatives. Appropriate values may be estimated by the RNC according to the current cell situation, such as radio resource usage, interference, etc., or according to the reliability level selected for transmission in the cell, as seen by the RNC. The third field, which is the cumulative number of packet losses, needs to be selected according to the concept used in the preceding field to avoid inconsistencies. For example, if the loss fraction is based on the packet loss seen by the RNC, they can also be used well in this entry. The highest sequence number received may be one of the highest that the RNC is shown. Interval jitter may be based on the jitter observed by the estimated values taken into account by the RNC or whether the ARQ or iterative coding or FEC is used to guarantee a certain degree of reliability. The last transmitter report (SR) timestamp can be obtained without modification from the transmitter report received from the transmitter. If the transmitter report has not yet been received, the field is set to zero. Last field Since last SR last delay (DLSR) may remain unmodified or further enhancement may be introduced. For example, in order to provide a better round trip time RTT estimate for the transmitter, it is proposed to reduce the delay value by one radio access RTT. In order to further adapt the delay value to compensate for the access network delay, the delay value may be reduced by, for example, two RTTs. Despite these rare examples, the aspects of the present invention cannot be limited.

The following scenario, a multicast scenario, is shown below.

Multicast scenarios differ primarily from broadcast scenarios in that a return channel can be used. This enables end-to-end RTP control protocol (RTCP) signals, due to the problems shown, ie the overload of radio resources when all clients send reports, an RNC for the intermediate network portion, preferably WCDMA. Is proposed to generate an RTCP message. In the following, two current possible embodiments are described.

In the first embodiment, the generated RTCP message of the client is discarded at the terminal of the client and originated from the scratch of an intermediate node such as RNC. According to the Real-Time Transfer Protocol (RTP) specification, it is currently possible for a client to indicate that a source for which RTCP receiver reporting cannot be used. Upon receipt of this information, the client's feedback message is discarded or otherwise generated.

In the second embodiment, it can be seen that the generated RTCP message of the client is transmitted over the air interface in the intermediary network portion but is modified in the network portion according to the specific principles described below. The RTCP message interval for the RTP message from the client may be greater than the RTCP message interval for the RTCP message from the intermediate node to the transmitter. A client may, for example, send an RTCP message only when a particular value is out of range, when the event is driven.

The input for setting various other fields of the receiver report (RR) message is the same as in the broadcast scenario. The following principles may be followed when setting fields in a receiver report (RR) message for multicast. The first principle that can be applied when using the common transport channel of WCDMA is that there will always be some receivers with poor channel conditions that suffer from many packet losses while the others will get good quality. In this case, the RNC may shield poor receiver reports to maintain quality for good users. The second principle can be applied if the RNC detects an overload of the cell and wants to reduce the bit rate according to the common channel used for the multicast / broadcast service, which can be applied to the multicast server to signal this to the multicast server. RTCP) reports are available. This may increase the measured packet loss rate of the report or reduce the highest sequence number received. This may be faster than end-to-end signals because of air interface latency and because per user, RTCP reporting has speed for many user groups.

In the following, a general mechanism common to the above-described scenarios is described.

As already mentioned, the collected RTCP feedback messages are generated in the intermediate network part. In the above description, RTCP report generation is done at the RNC. In general, this report generation and all related functionality are logical functions that may also exist on other network entities such as multicast / broadcast servers, MB-SCs. A dedicated protocol can be used to convey the relevant information from the RNC to the MB-SC in this case.

In a preferred embodiment of the present invention, user anonymity will be guaranteed. Unlike some multicast applications of the fixed Internet, such as audio and video-conferencing, mobile terminal users usually form an anonymous community. Users of mobile networks viewing the same video clip will not be interested in knowing the names of other viewers, nor will they be interested in revealing their identification. RTP control protocol (RTCP) messages, in particular receiver report (RR) and source description item (SDES) messages, conforming to the standard will include the identification of the user, for example in the form of an e-mail address. Accordingly, the present invention proposes to send an RTCP message generated to an intermediary node and send it back to a real-time transport protocol (RTP) stream transmitter.

With the generation of the RTCP report collected, the number of destinations to which the RTCP report is applied is added to the report. This information is then potentially considered by the source in case of multicast stream adaptation. It means that the source can adapt to this destination if the collected RTCP report covers multiple destinations. If only 10 destinations are covered in a session that includes multiple destinations, it would be better to switch the client to a unicast session instead.

In the following, two embodiments of the present invention are described. The feedback message collected in the first embodiment is generated at the intermediary node based on the RTCP report per mobile terminal as described in accordance with FIG. 6.

6 shows a multicast source transmitting real-time transport protocol (RTP) flows, downstream multicast traffic, and corresponding RNCs to clients with their mobile terminals through intermediary nodes. The intermediate node generates an RTCP receiver report and sends them to the multicast source as feedback. The feedback is generated in consideration of user and cell information received from the RNC.

To distinguish between several multicast sources, each receiver report (RR) packet is addressed by the source's SSRC. Therefore, the intermediary node must process and forward downstream-mulicast traffic from the source to the receiver and extract the SSRC of the multicast source. SSRC needs to address the upstream RTCP receiver report packet generated on the intermediate node. The number of mobile terminals per cell plus reception condition per terminal is provided by the RNC.

The intermediate node must assign an SSRC identifier for each client's terminal. The intermediary node must assign SSRC for each client's terminal. In addition to the SSRC, the intermediary node must also provide an SDES CNAME item for each client. There are several options for selecting a CNAME for an individual user. In the case of an anonymous participant, the SDES CNAME item is randomly selected when the source does not obtain an explicit CNAME. For example, it could be <random-number> @host. CNAME must be unique. In the case of a non-anonymous CNAME, the operator may predetermine the username, for example with phonenumber @ domain or the user specifies the CNAME of the reference database. Therefore, the intermediary node must maintain a list for the client terminal per cell plus the relevant SSRC assigned by the intermediary node and the CNAME. Maybe intermediary node functionality is included in the BM-SC or GGSN. The contents of each RTCP packet are generated as described in the previous chapter.

In the case of a very large group of users spread over a large number of cells, the intermediary node will send RTCP packets per cell, not per client. It is very similar that each cell servers approximately the same amount of group members. This embodiment is described in FIG. 7, which describes a fact consistent with FIG. 6. The difference is that the intermediary node generates a feedback message per cell.

In this case, the intermediary node assigns valid SSRC and CNAMEs for each cell containing group members. The number of outgoing RTCP packets is reduced. The transmission interval of the RTCP packet and the response time of the multicast source are reduced by being transmitted for each cell RTCP packet.

Additional RTP control protocol (RTCP) packet types may be introduced to weight RTP receiver reports according to the number of users in the cell. This RTP packet type must split an RTCP composite packet whenever this RTCP packet contains a receiver report for one or more members.

The present invention delivers a solution for a radio and multicast characteristic RTP control protocol (RTCP) that takes into account the characteristics of the wireless network and improves the overall quality of service. Other information from lower layer protocols, as is already known in RNC, may be considered in the report to further optimize the quality of service. However, there is a part of the present invention for delivering additional radio related information to the source. The other is that the RNC considers the information and makes an adaptation proposal to the source. Since there is a wireless network that translates this information into a known adaptation proposal for the source, the source does not need to have information about the wireless network.

Claims (23)

A method for adapting to multi-user multimedia data in a communication system having a server and an intermediate network portion for providing multi-user multimedia data to a client, the method comprising: The intermediate network portion provides information in accordance with the communication between the server and the client and the method comprises: Sending a data stream from the server to the client, Determining a distribution characteristic associated with the client, Generating a feedback report collected in accordance with a client reception condition of the data stream, taking into account the distribution characteristic, in the intermediary network part, the feedback report comprising information relating to a collection fashion; Sending the collected feedback report to the server, Adapting the transmission of said data stream from said server to said client in accordance with said collected feedback report, wherein said multiple communication system having a server and an intermediary network portion providing multi-user multimedia data to said client. A method for adapting to user multimedia data. The method of claim 1, And said distributed characteristic relates to a geographic area comprising a group of clients. A method for adapting to multi-user multimedia data in a communication system having a server and an intermediary network portion for providing the client with multi-user multimedia data. The method of claim 2, Wherein said geographic area is covered by one or more cells of a wireless communications network, wherein said server provides a multi-user multimedia data to a client and a part of an intermediary network portion. The method of claim 1, And said distributed characteristic relates to a predetermined multicast group structure. A method for adapting to multi-user multimedia data in a communication system having a server and an intermediate network portion for providing multi-user multimedia data to a client. The method according to any one of claims 1 to 4, And said distributed characteristic relates to information received from radio resource management. A method for adapting to multi-user multimedia data in a communication system having a server and an intermediate network portion for providing multi-user multimedia data to a client. The method of claim 5, Information received from the radio resource management is transmitted frequently or event-centricly for adapting to multi-user multimedia data in a communication system having a server and an intermediary network portion providing the multi-user multimedia data to a client. Way. The method according to any one of claims 1 to 4, And wherein said distributed characteristic relates to information received from said client. A method for adapting to multi-user multimedia data in a communication system having a server and an intermediate network portion for providing multi-user multimedia data to a client. The method of claim 7, wherein Information received from the client is transmitted frequently or event-centricly, wherein the server provides multi-user multimedia data to the client and a method for adapting to multi-user multimedia data in a communication system having an intermediary network portion. The method according to any one of claims 1 to 4, A feedback report from the client is suppressed at the network terminal. The method according to any one of claims 1 to 9, The information received from the client affects information from the radio resource management. Adapting to multi-user multimedia data of a communication system having a server and an intermediary network portion providing the multi-user multimedia data to the client. Way. The method of claim 1, The information about the collection fashion includes a plurality of clients to which the collected feedback report is applied, the multi-user multimedia data of a communication system having a server and an intermediary network portion providing the multi-user multimedia data to the client. How to adapt. The method of claim 1, The additional information about the collection fashion includes the wireless characteristics of the access network in which the client resides, the multi-user multimedia data of a communication system having a server and an intermediary network portion providing the multi-user multimedia data to the client. How to adapt. The method according to any one of claims 1 to 12, The additional information about the collection fashion includes information about the adaptation method for adapting to multi-user multimedia data of a communication system having a server and an intermediary network portion providing the multi-user multimedia data to a client. Way. The method of claim 6 or 8, Negotiation is performed according to a frequency of a feedback report from the client and / or the radio resource management to the intermediate node, wherein the server and / or part of a communication system having an intermediate network portion providing multi-user multimedia data to the client. Method for adapting to user multimedia data. The method according to any one of claims 1 to 14, The terminal adapts to the multi-user multimedia data of a communication system having a server and an intermediary network portion for providing a multi-user multimedia data to a client, the terminal receiving the data stream and suppressing transmission of a feedback report from another terminal. How to make it. The method according to any one of claims 1 to 15, The generated and collected feedback report includes the fraction of lost packets provided by the intermediary node according to current delivery conditions, the highest sequence number at which the intermediary node is received, and the arrival interval jitter provided by the intermediary node. And a server for providing multi-user multimedia data to a client and a multi-user multimedia data in a communication system having an intermediate network portion. The method according to any one of claims 1 to 16, By receiving the collected feedback report, the source has a server and an intermediary network portion for providing multi-user multimedia data to the client, wherein the report is included in the report taking into account the percentage of the client to which the feedback is applied. A method for adapting to multi-user multimedia data of a communication system. The response may be to inform the client of a new channel or to adapt the stream, for example to reduce the bit-rate or switch to a more reliable codec. Can) The method according to any one of claims 1 to 14, The generation of the collected feedback report and the determination of the distributed characteristics associated with the client are performed on the same node that is an intermediary network part or divided among several other nodes forming the intermediary network part. A method for adapting to multi-user multimedia data in a communication system having a server and intermediate network portion providing user multimedia data. The method according to any one of claims 1 to 18, The server and mediation for providing multi-user multimedia data to the client, characterized in that the transmission of the data stream is carried out by a real-time transmission protocol (RTP) having a control protocol RTP control protocol (RTCP) for reporting feedback. A method for adapting to multi-user multimedia data of a communication system having a network part. A part of an intermediary network adapted to perform adaptation of said multi-user data stream in a communication system having a server for providing a multi-user data stream to a client. The intermediate network portion is configured to provide information according to the communication between the server and the client and the intermediate network portion is Means for delivering a data stream from the server to the client, Means for determining distribution characteristics associated with the client, Means for generating a feedback report collected in accordance with the reception conditions of the client of the data stream, the feedback report comprising additional information about the collection fashion, Means for transmitting said collected feedback report to said server, adapted to perform adaptation of said multi-user data stream in a communication system having a server providing a multi-user data stream to a client. Mediation network part. The method of claim 20, Part of an intermediary network adapted to perform adaptation of said multi-user data stream in a communication system having a server providing the client with a multi-user data stream comprising all means implemented in the same network node. The method of claim 20, Means for determining a distribution characteristic associated with the client and means for generating a collected feedback report that is partitioned among several different nodes. Part of an intermediary network adapted to perform adaptation of said multi-user data stream in a system. The method of claim 22, Means for receiving said externally determined distributed characteristic associated with said client, adapted to perform adaptation of said multi-user data stream in a communication system having a server providing a multi-user data stream to a client. Mediation network part.