EP1432196A1 - Méthode de compression pour le trafic de commande dans la transmission de données média - Google Patents

Méthode de compression pour le trafic de commande dans la transmission de données média Download PDF

Info

Publication number
EP1432196A1
EP1432196A1 EP02028632A EP02028632A EP1432196A1 EP 1432196 A1 EP1432196 A1 EP 1432196A1 EP 02028632 A EP02028632 A EP 02028632A EP 02028632 A EP02028632 A EP 02028632A EP 1432196 A1 EP1432196 A1 EP 1432196A1
Authority
EP
European Patent Office
Prior art keywords
packet
packets
report
sender
context parameters
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02028632A
Other languages
German (de)
English (en)
Inventor
Xiaoyuan Gu
Rolf Hakenberg
Akihiro Miyazaki
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Priority to EP02028632A priority Critical patent/EP1432196A1/fr
Priority to CNA2003101180747A priority patent/CN1510881A/zh
Priority to US10/728,089 priority patent/US20040165527A1/en
Priority to JP2003411965A priority patent/JP2004208292A/ja
Publication of EP1432196A1 publication Critical patent/EP1432196A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the present invention is related to a compression method for RTCP traffic in media data transmission sessions.
  • the method is intended to be employed in real-time or near real-time data packet transmission in an Internet Protocol (IP) network using a real-time protocol (RTP) for media data delivery and Real-time Control Protocol (RTCP) for controlling media delivery.
  • IP Internet Protocol
  • RTP real-time protocol
  • RTCP Real-time Control Protocol
  • Each of the protocols, RTP or RTCP is allocated a fraction of the available session bandwidth according to the specifications given in RFC 1889.
  • the Real-time Transport Protocol as defined in RFC 1889, is the de-facto standard that provides end to end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. It is augmented by the Real-time Control Protocol (RTCP) to allow monitoring the Quality of Service (QoS) of data delivery in a manner scalable to large multicast networks and to provide minimal control and identification functionality. RTP does not address resource reservation and does not guarantee Quality of Service (QoS) for real-time services.
  • RTCP Real-time Control Protocol
  • RTP restricts the control traffic using two rules: First, it is recommended that 5% of the session bandwidth is allocated to RTCP traffic and it is shared by all participants in a session. Second, the minimum report interval for the transmission of feedback is recommended to be five seconds. All receivers in a session are using their own fraction with this 5% to calculate their report interval.
  • the RTCP report interval T defines the time interval between two RTCP data packets from a source that has to be met. This interval depends to a large extent on the average RTCP packet size.
  • IP based real-time multimedia application introduce a large Layer-3, Layer-4 and upper layer header overhead due to usually small payload sizes of single packets in a real-time data flow.
  • header compression represents an essential prerequisite for the mobile Internet, i.e., whenever an IP based mobile end device has to communicate with an IP based infrastructure.
  • Robust Header Compression (ROHC) as defined in RFC 3095 is the state-of-the-art header compression scheme standardised by the IETF. It provides a complex framework that allows to fine tune compression efficiency versus robustness against link errors based on different link conditions.
  • the protocol works by maintaining states at both end points of the first hop or last hop wireless link and by removing the redundancy of the packet headers and by encoding the information in an efficient way.
  • the states of the compressor at the transmitting end (or endpoint) and the decompressor at the receiving end are also referred to as "context".
  • the context contains relevant information from previous headers in the packet stream, such as static fields and possible reference values for compression and decompression. Additional information describing the packet stream may be also part of the context, for example information about how the IP Identifier field changes and the typical inter-packet increase in sequence numbers or timestamps.
  • Video streaming over the mobile Internet as one of the key applications using RTP/RTCP is gaining the momentum.
  • the lossy behaviour and long round trip time in wireless links makes the deployment of this kind of applications challenging enough.
  • inter-frame video compression algorithms like MPEG-4 exploiting temporal correlations between the frame to achieve extremely high compression gain, but they also suffer from the well-known propagation of errors effect, since errors of a reference frame propagate to all the dependent different frames.
  • the object of the present invention is to optimise the bandwidth efficiency for RTCP traffic and the to reduce the RTCP report/feedback interval.
  • the shared session bandwidth fraction for RTCP among all participants in a session and for bi-directional operation is limited. Spectrum efficiency is vital in sparse and expensive wireless links. Therefore how to use this limited bandwidth efficiently represents a need for applications deploy RTP via wireless links.
  • the presented method aims at maximum exploiting bandwidth efficiency for RTCP traffic for these usages without exceeding the available RTCP bandwidth fraction.
  • the RTCP report interval is the period between two consecutive reports from the same receiver for within the same session. It is affected by latency from two aspects.
  • RTCP report latency is the period between a packet loss is detected at the receiver and a report/feedback is sent, and the latency due the round-trip-time (RTT) of the link. While the latter is hard to avoid, the report latency can be exploited for optimisation.
  • the endpoints in a data transmission according to the present invention maintain the content (state) of the compressor and decompressor. Due to the structure maintained in the context, repairing and recovering of out-of-sync context at the decompressor is possible. Further, it is possible to dynamically define packet formats and the compressor's and decompressor's context.
  • the compression method initialises the context of the control traffic flow by initially transmitting context parameters to the receiving endpoint. If necessary, the context is updated during the session using smaller sized packets (compressed control packets). Latter packets are used in case a partial context update is performed. It is also possible to update the context periodically using the initialisation packet.
  • Context parameters can be categorized into static and dynamic parameters. Static context parameters are either a-priori known parameters or parameters not changing during a session. Dynamic context parameters, which are parameters changing during a session, are transmitted in newly defined packets or compressed control packets to the receiving end.
  • At least one initialisation packet comprising these context parameters is transmitted to the receiving nodes.
  • the comprised parameters include static information, these information only have to be transmitted once. Therefore the total traffic volume to be transmitted can be significantly reduced.
  • Dynamic context parameters are transmitted for example in control protocol specific packets (compressed control packets). Refresh packets allow the packet source to update context information at a receiving node. Control packets correspond mainly to those known from the standard RTCP protocol.
  • compressed control packets are changed in their packet structure, such that their content's size (in bits) can be significantly reduced and new packets such as initialisation packets and refresh packets are introduced.
  • new packets such as initialisation packets and refresh packets are introduced.
  • the total average packet size of the control protocol's control packets can be significantly reduced in comparison to the standard RTCP protocol.
  • RTCP source description packets and RTCP bye packets As the content of RTCP source description packets and RTCP bye packets is not frequently changing or does not occur often during a session, the corresponding source description packet and bye packet in the control protocol will not be compressed in the disclosed method, though it is possible to perform compression of theses packets by using the compression and decompression mechanism described herein. Both packets have a similar format as the corresponding RTCP packets.
  • At least one initialisation packet is formed from these static context parameter and, if needed, from initialisation values for dynamic context parameters before they are transmitted.
  • Refresh packets are formed from dynamic context parameters before the same are transmitted.
  • dynamic context parameters are further categorised into occasionally changing context parameters, context parameters of random character, counter-like context parameters, frequently changing context parameters and context parameters that regularly change by a fixed delta.
  • the parameters can be compressed by encoding to reduce their size before incorporating them into control data packets.
  • counter-like context parameters, frequently changing context parameters and context parameters that regularly change by a fixed delta can be encoded using least-significant-bit (LSB) encoding.
  • LSB least-significant-bit
  • LSB least-significant-bit
  • the standard RTCP protocol uses the following packets to control a media data transmissions stream in a real-time or near real-time environment: Sender reports for transmitting and receiving static's from participants that are active senders in a media data transmission session, receiver reports for receiving static's from participants that are not active senders, source description items for describing the sending source, bye packets for indicating the end of participation of a former participant and application-defined (APP) packets for transmitting applications specific data.
  • APP application-defined
  • the fields in the packet structure are analysed first.
  • all fields in RTCP packets can be categorised in static context parameters, that are fields expected to be constant throughout the lifetime of the packet stream (session), and dynamic context parameters, that are fields that are expected to vary in some way, for example randomly, within a limited value set or range or in some other manner.
  • the dynamic context parameters may be further categorised as follows: Occasionally changing context parameters, context parameters of random character, counter like context parameters, frequently changing context parameters and context parameters that regularly change by a fixed delta.
  • the occasionally changing context parameters are those fields occasionally change but revert to their original value after a limited number of packets.
  • those value or fields are the reception report count (RC) that indicates the number of report blocks in the packet, the source count (SC) fields that indicate the number of synchronization sources or contributing sources in a source description packet or identifying the number of synchronization sources or contribution sources in a by packet, payload type (PT) fields that identify the individual packet type, source description (SDES) items comprising information to describe packet sources properties and sub type fields in application-defined (APP) packets allowing a set of application-defined (APP) packets to be defined under one unique name.
  • RC reception report count
  • SC source count
  • PT payload type
  • SDES source description
  • Frequently changing context parameters comprise those parameters that are normally either constant or have values deducible from some other fields but that frequently diverge from this behaviour. Therefore, there must be an effective way to update the frequently changing context parameter at the receivers or senders end.
  • the mentioned refresh packets can be used in such a case or the respective fields are sent as they are in the newly defined control packets.
  • Fields that have to be frequently updated comprise the RTP time stamp, fields that are indicating the delay since the sender report received last (delay since last sender report), the time stamp of the last sender report, inter-arrival jitter fields that indicate an estimate of these statistical variance of the RTP data packet inter-arrival time and the length field of the RTCP packets.
  • a further category of dynamic context parameters are packets of random character. Examples for those parameters are the RTCP fraction loss in the bit map mask (BLP) of RTCP APP packet as specified by J. Ott et al. in "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", Internet Draft, Oct. 2002. As those fields are completely random they are included as they are in all compressed packet headers.
  • BLP bit map mask
  • the next category of dynamic context parameters are the counter-like context parameters.
  • Those parameters are fields that behave like a counter with a fixed delta between the different counter values for all RTCP packets. The only requirement on the transmission encoding of those fields is that packet losses between the compressor on the senders end and the decompressor on the receivers end must be tolerable. If several of those fields exist, all those fields can also be communicated together. Such parameters can also used to interpret the values of frequently changing context parameters.
  • the last category of dynamic context parameters comprises those context parameters that regularly change by a fixed delta. Those fields usually increase by a fixed delta in succeeding packets. Thus, those fields are correlated with one another. In this context it is advisable to initiate the field's value using an initialisation packet and then updating the field by transmitting their increment.
  • RTP time stamp An example for a context parameter that regularly changes by a fixed delta is the RTP time stamp.
  • a third category besides the static and the dynamic context parameters can be determined. So-called well-known or a priori known fields within the standard RTCP packets may be either transmitted during initialisation or are omitted. An example for an a-priori known context parameter is the RTCP version field.
  • context parameters can be, for example, performed by referencing tables used for packet and header compression. It would also be possible to dynamically categorise the context parameters within the suggested new RTCP compression method.
  • LSB least-significant-bit
  • the control protocol's packets are formed.
  • the packet format of an initialisation packet is shown in figure 1.
  • the packet contains static context parameters such as a padding flag, a synchronization source of the sender and the source, and a contributing source field in the "static chain” field of the packet.
  • the "static chain” field is thereby variable in its length as well as the "dynamic chain” field of the packet.
  • Also incorporated in the initialisation packet are the source count and reception report count, a payload type identification, one or more SDES items and a subtype field for application-defined (APP) packets.
  • APP application-defined
  • the occasionally context parameters can be also integrated in the formed initialisation packet using their initial value. These initialisation values of the occasionally changing context parameters are located in the "dynamic chain" field of the initialisation packet.
  • the compressed initialisation packet comprises a context ID (CID, "Add-CID octet”) that identifies the state of the decompressor to be used at the packet receiving end to decompress the initialisation packet at the beginning of the packet, a packet identifier ("1111110D”) to enable the packet receiver to identify the packet type, profile information ("Profile”) for the sender's profile, cyclic redundancy check field (“CRC”) for checking data integrity of the initialisation packet, a static information chain (“Static chain”) comprising static context parameters and finally dynamic information chain (“Dynamic Chain”) comprising dynamic context parameters, that have to be initialised once.
  • the latter correspond to the before-mentioned occasionally changing context parameters, such as the source count, the reception report count, the RTCP payload type, SDES items and the subtype field for application-defined (APP) packets.
  • FIG. 2 shows the packet format of a refresh packet.
  • the refresh packet comprises a context ID (CID, "Add-CID octet”) for identifying the state of the header-decompressor to be used at the packet receiving end to decompress the refresh packet, a packet identifier ("11111000”), profile information (“Profile”) of the packet sender, a cyclic redundancy check (“CRC”) field for checking data integrity of the refreshing packet and a dynamic information chain (“Dynamic Chain”) comprising the dynamic context parameters that have to be updated.
  • CID context ID
  • initialisation packet and the refresh packet may comprise up to two additional bytes following the packet identifier in case large context identifiers (CID) are used.
  • CID context identifiers
  • Figures 3 and 4 show a compressed version of the sender and receiver report packets and figure 5 shows a new compressed application-defined (APP) packet.
  • APP application-defined
  • the source description packets and the bye packets correspond to the standard packet format as suggested in RFC 1889. This is because those packets occur very rarely during a session such that they are compression would not reduce the average packet size of RTCP packets significantly.
  • the sender report packet comprises a packet header and at least a report block.
  • the report block/s can be followed by profile-specific extensions.
  • profile-specific extensions all fields that fall into one of the above mentioned categories can be also compressed using least-significant-bit encoding. Hence, the extension fields' size can be also reduced leading to a smaller packet size on average.
  • LSB Least Significant Bit
  • the header of the sender report packet comprises a packet identifier ("111") to identify the sender report packet type. Further, a reception report count field (“RC") is indicating the number of report blocks comprised in the compressed sender report packet. An active sender flag (“s”) indicates whether participant that forms the report block is an active sender or not. The cyclic redundancy check (“CRC”) field is used to check data integrity of the compressed sender report packet. A padding flag or bit (“P”) is indicating whether the sender report packet contains an additional padding field at the end of the packet. The additional padding field is not a part of the actual context parameters.
  • a least-significant-bit (LSB) encoded RTP time stamp (“LSB Scaled RTP Timestamp") is further comprised in the header.
  • An extension flag (“X") is indicating whether the packet comprises profile-specific extensions in a special extension field at the end of the packet.
  • the sender's packet count field is also least-significant-bit (LSB) encoded.
  • the sender's packet count field (“LSB Sender's Packet Count") in the header of the sender report packet indicates the total number of RTP packets the sender has transmitted in the time frame between the beginning of the media data transmission session and the generation of the respective sender report packet.
  • the header of the sender report packet comprises a field for the sender octet count indicating the total number of payload octets transmitted in RTP data packets by the sender in the time frame between the beginning of the session and the generation of the sender report packet.
  • the field is least-significant-bit (LSB) encoded to reduce the size of the packet header.
  • this field is split into two parts (“LSB sender Octet Count Part1" and "LSB SOC P2"), the 5 th byte of the packet and the five first bits of the 6 th byte of the packet contain the sender's octet count.
  • the at least one report block, in the sender report packet comprises the following fields:
  • a fraction lost field (“fraction lost”) that indicates the number of packets lost divided by the number of packet accepted to be received, a cumulated loss field (“cummu. loss”) indicates the cumulated number of packets lost during transmission.
  • the cumulated loss field is least-significant-bit (LSB) encoded as the remaining fields of the report block.
  • a sequence number cycle field (“LSB SN Cycle”) is indicating the sequence number cycle of the extended highest sequence number of received packets.
  • the highest sequence number field (“LSB Highest SN”) indicates the highest sequence number received by the sender of the sender report packet.
  • the inter-arrival jitter field (“intera. jitter”) comprises an estimation value of the statistical variance of the RTP data packet inter-arrival time.
  • RTP time stamp field (“LSB TS last SR”) indicating the time since the last sender report has been sent.
  • a field (“LSB DLS”) for indicating the delay since the last compressed RTCP sender report is also included.
  • a single report block is four bytes long (bytes seven to ten shown in the figure). As indicated in the figure, multiple report blocks may be comprised by a single sender report.
  • the receiver report packet comprises a header (bytes one to three) and at least one report block, which is similar to the report block described before.
  • the compressed receiver report packet as well as the compressed sender report packet may also comprise profile-specific extensions at their end, indicated by an extension flag ("x") in the packet header.
  • the header of the receiver report packet comprises a packet identifier ("111") to identify the receiver report packet type thus that the receiving end may recognize the compressed version of the receiver report.
  • a reception count field (“RC") indicates the number of report block comprised in the receiver report packet.
  • a receiver report packet may comprise several report blocks following the respective packet header.
  • An active sender indication flag indicates the status of the session participant who generated the respective report block. Further, a cyclic redundancy check field is included to verify data integrity. A padding flag (“P”) is indicating whether the receiver report packet contains an additional padding field at the end of the receiver report packet. The additional padding field is not part of the actual context parameters. Lastly, a length field (“LSB Length RR”) is included in the header of the receiver report packet to indicate the lengths of the compressed RTCP receiver report in least-significant-bit (LSB) encoded format.
  • LSB Length RR is included in the header of the receiver report packet to indicate the lengths of the compressed RTCP receiver report in least-significant-bit (LSB) encoded format.
  • an application-defined (APP) packet format is shown in figure 5.
  • the user of the suggested compressed application-defined (APP) packet format only applies in case the enhanced RTCP feedback as suggested by Ott et al. is used. Therefore, the packet specification is rather application-specific - as its name indicates - than a general approach.
  • the compressed application-defined (APP) packet format comprises a packet identifier ("111") for identifying the compressed application-defined (APP) packet type.
  • a feedback type field (“FMT”) is indicating the feedback type provided in this packet. Further, the length of the packet is indicated in the feedback length field ("LSB Feedback Length”). This field is least-significant-bit (LSB) encoded.
  • a bitmask field (“BLP”) is indicated last packets. The first bit is the BLP field (bitmask field) allows reporting loss to any of the RTP packet immediately following an RTP packet indicated by a packet identifier.
  • the feedback type field (FMT) is indicating a generic acknowledgement
  • the above suggested compressed control packets as well as the two newly introduced packet formats (initialisation packet and refresh packet) are intended to reduce the overall average packet size of control protocol's packets, allowing to reduce the report interval T.
  • the data volume is reduced by sending static context parameters in the initialisation packets "in advance" as well as to initialise occasionally changing context parameters.
  • the refresh packets are used to do so.
  • most of the control packet fields are encoded, such that their size is further reduced.
  • the suggested header and data compression mechanisms deal only with the RTCP header and data part and not the lower layer UDP/IP headers. Therefore, compared to header compression scheme like suggested in RPF 3095, which is generally applicable to the last hop or first hop point-to-point link, the approach described herein can be applied end-to-end.
  • the intermediate hops along the way to a packet's do not need to care about the compressed control packets, as they see them either as Layer-3 IP packet data or as Layer-4 transport layer packet data. No additional overhead for the intermediate hosts will be introduced. However, if used together with Robust Header Compression for lower layers' headers in first/last hop wireless links, even more bandwidth can be saved.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
EP02028632A 2002-12-20 2002-12-20 Méthode de compression pour le trafic de commande dans la transmission de données média Withdrawn EP1432196A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP02028632A EP1432196A1 (fr) 2002-12-20 2002-12-20 Méthode de compression pour le trafic de commande dans la transmission de données média
CNA2003101180747A CN1510881A (zh) 2002-12-20 2003-11-20 控制通信量压缩方法
US10/728,089 US20040165527A1 (en) 2002-12-20 2003-12-05 Control traffic compression method
JP2003411965A JP2004208292A (ja) 2002-12-20 2003-12-10 制御トラフィック圧縮方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP02028632A EP1432196A1 (fr) 2002-12-20 2002-12-20 Méthode de compression pour le trafic de commande dans la transmission de données média

Publications (1)

Publication Number Publication Date
EP1432196A1 true EP1432196A1 (fr) 2004-06-23

Family

ID=32338076

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02028632A Withdrawn EP1432196A1 (fr) 2002-12-20 2002-12-20 Méthode de compression pour le trafic de commande dans la transmission de données média

Country Status (4)

Country Link
US (1) US20040165527A1 (fr)
EP (1) EP1432196A1 (fr)
JP (1) JP2004208292A (fr)
CN (1) CN1510881A (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2490212A (en) * 2011-04-08 2012-10-24 Samsung Electronics Co Ltd Frame strucutre and signalling for wireless broadcast system
EP2555510A2 (fr) * 2010-04-01 2013-02-06 LG Electronics Inc. Appareil d'émission de signal de diffusion, appareil de réception de signal de diffusion, et procédé d'émission-réception de signal de diffusion dans un appareil d'émission-réception de signal de diffusion

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7743164B2 (en) * 2004-02-13 2010-06-22 Alcatel-Lucent Usa Inc. Method and apparatus for transmitting frequency shift key data in a packetized format
CN101790235B (zh) * 2004-03-12 2012-05-23 三星电子株式会社 宽带无线通信系统中减小突发分配信息大小的方法和装置
CN1315307C (zh) * 2004-08-05 2007-05-09 北京航空航天大学 一种利用Mbus通讯中间件来进行传输的方法
US7870590B2 (en) * 2004-10-20 2011-01-11 Cisco Technology, Inc. System and method for fast start-up of live multicast streams transmitted over a packet network
EP1686732B1 (fr) * 2005-01-28 2007-10-31 Siemens Aktiengesellschaft Procédé et système de transmission d'unités de données de protocole
US8169891B2 (en) * 2005-03-31 2012-05-01 Agere Systems Inc. Apparatus and method for handling lost cells in a communications system
US7864701B2 (en) * 2005-03-31 2011-01-04 Intel Corporation Apparatus, system and method capable of decreasing management frame size in wireless networks
US7680047B2 (en) * 2005-11-22 2010-03-16 Cisco Technology, Inc. Maximum transmission unit tuning mechanism for a real-time transport protocol stream
US7965771B2 (en) 2006-02-27 2011-06-21 Cisco Technology, Inc. Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US8218654B2 (en) 2006-03-08 2012-07-10 Cisco Technology, Inc. Method for reducing channel change startup delays for multicast digital video streams
US20070263824A1 (en) * 2006-04-18 2007-11-15 Cisco Technology, Inc. Network resource optimization in a video conference
US8326927B2 (en) * 2006-05-23 2012-12-04 Cisco Technology, Inc. Method and apparatus for inviting non-rich media endpoints to join a conference sidebar session
US7796532B2 (en) * 2006-05-31 2010-09-14 Cisco Technology, Inc. Media segment monitoring
EP1890408A3 (fr) * 2006-08-18 2011-10-12 Samsung Electronics Co., Ltd. Procédé et appareil pour le rapport d'un taux de réception d'un service de diffusion en continu par un terminal dans un système de diffusion mobile et système correspondant
US8358763B2 (en) * 2006-08-21 2013-01-22 Cisco Technology, Inc. Camping on a conference or telephony port
US20080049635A1 (en) * 2006-08-25 2008-02-28 Sbc Knowledge Ventures, Lp Method and system for determining one-way packet travel time using RTCP
US8031701B2 (en) 2006-09-11 2011-10-04 Cisco Technology, Inc. Retransmission-based stream repair and stream join
US7847815B2 (en) * 2006-10-11 2010-12-07 Cisco Technology, Inc. Interaction based on facial recognition of conference participants
US7693190B2 (en) * 2006-11-22 2010-04-06 Cisco Technology, Inc. Lip synchronization for audio/video transmissions over a network
US8121277B2 (en) * 2006-12-12 2012-02-21 Cisco Technology, Inc. Catch-up playback in a conferencing system
DK2122999T3 (en) * 2007-01-18 2016-06-06 ERICSSON TELEFON AB L M (publ) Sharing rtcp-bandwidth between compound and non-composite rtcp- packages
US8769591B2 (en) 2007-02-12 2014-07-01 Cisco Technology, Inc. Fast channel change on a bandwidth constrained network
US20080253369A1 (en) * 2007-04-16 2008-10-16 Cisco Technology, Inc. Monitoring and correcting upstream packet loss
WO2008129408A2 (fr) * 2007-04-23 2008-10-30 Nokia Corporation Utilisation d'informations de rétroaction de sessions multimédia
CN101127712B (zh) * 2007-08-20 2011-05-25 中兴通讯股份有限公司 一种解决rtp会话中同步源标识冲突的方法
US8289362B2 (en) * 2007-09-26 2012-10-16 Cisco Technology, Inc. Audio directionality control for a multi-display switched video conferencing system
US20090135735A1 (en) * 2007-11-27 2009-05-28 Tellabs Operations, Inc. Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems
US20090135724A1 (en) * 2007-11-27 2009-05-28 Tellabs Operations, Inc. Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems
US7975071B2 (en) * 2008-01-18 2011-07-05 Microsoft Corporation Content compression in networks
US8787153B2 (en) 2008-02-10 2014-07-22 Cisco Technology, Inc. Forward error correction based data recovery with path diversity
US8559463B2 (en) * 2008-02-20 2013-10-15 General Dynamics C4 Systems, Inc. Systems and methods for providing efficient bandwidth utilization in packet switched networks
US9426213B2 (en) * 2008-11-11 2016-08-23 At&T Intellectual Property Ii, L.P. Hybrid unicast/anycast content distribution network system
JP5245761B2 (ja) * 2008-11-26 2013-07-24 富士通株式会社 送信装置、受信装置、送信方法及び受信方法
JP5066064B2 (ja) * 2008-11-28 2012-11-07 日本放送協会 一方向伝送路に用いる送信端末、受信端末及び伝送システム
US20110016313A1 (en) * 2009-07-15 2011-01-20 Qualcomm Incorporated HEADER COMPRESSION FOR TUNNELED IPsec PACKET
US9083708B2 (en) 2010-05-17 2015-07-14 Microsoft Technology Licensing, Llc Asymmetric end host redundancy elimination for networks
JP5565121B2 (ja) * 2010-06-09 2014-08-06 ソニー株式会社 通信処理装置、通信処理システム、通信処理方法及びプログラム
CN102036307B (zh) * 2010-12-17 2016-04-13 中兴通讯股份有限公司 鲁棒性头压缩中提高上下文更新报文健壮性的方法和装置
CN102594776B (zh) * 2011-01-11 2016-08-03 中兴通讯股份有限公司 一种同步源标识更新的方法、装置和系统
US8966179B1 (en) * 2012-09-10 2015-02-24 Google Inc. Volatile memory storage for private web browsing
US9100698B2 (en) * 2012-10-26 2015-08-04 Motorola Solutions, Inc. Systems and methods for sharing bandwidth across multiple video streams
US8964736B1 (en) 2012-11-27 2015-02-24 Sprint Communications Company L.P. RTP streaming with dynamic packet format modification
US9948565B2 (en) 2013-08-19 2018-04-17 Instart Logic, Inc. Method and implementation of zero overhead rate controlled (ZORC) information transmission via digital communication link
TWI656765B (zh) * 2017-06-01 2019-04-11 財團法人資訊工業策進會 傳輸系統及傳輸方法
JP2022523564A (ja) 2019-03-04 2022-04-25 アイオーカレンツ， インコーポレイテッド 機械学習を使用するデータ圧縮および通信
US11330665B2 (en) * 2020-01-09 2022-05-10 Qualcomm Incorporated Increasing throughput efficiency in a PDCP channel with ROHC TCP profile

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1187417A1 (fr) * 2000-09-07 2002-03-13 Matsushita Electric Industrial Co., Ltd. Procédé et dispositif de trasmission de paquets de données
WO2002029991A1 (fr) * 2000-10-05 2002-04-11 Provisionpoint Communications, Llc Encapsulation de paquets groupes et systeme et procede de compression
EP1204258A2 (fr) * 2000-11-06 2002-05-08 Matsushita Electric Industrial Co., Ltd. Procédé, dispositif et programme pour compression d'en-tête

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6219045B1 (en) * 1995-11-13 2001-04-17 Worlds, Inc. Scalable virtual world chat client-server system
WO1998042132A1 (fr) * 1997-03-17 1998-09-24 Matsushita Electric Industrial Co., Ltd. Procede de traitement, transmission et reception de donnees d'images dynamiques et dispositif connexe
US6967964B1 (en) * 2000-10-03 2005-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Context identification using header compression key at link layer
FI118244B (fi) * 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
US7327708B2 (en) * 2002-04-25 2008-02-05 Inet Technologies, Inc. Multimedia traffic optimization
US20040066779A1 (en) * 2002-10-04 2004-04-08 Craig Barrack Method and implementation for context switchover
US8068515B2 (en) * 2005-06-22 2011-11-29 Cisco Technology, Inc. Faster multimedia synchronization of broadcast streams using router caching of RTCP packets

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1187417A1 (fr) * 2000-09-07 2002-03-13 Matsushita Electric Industrial Co., Ltd. Procédé et dispositif de trasmission de paquets de données
WO2002029991A1 (fr) * 2000-10-05 2002-04-11 Provisionpoint Communications, Llc Encapsulation de paquets groupes et systeme et procede de compression
EP1204258A2 (fr) * 2000-11-06 2002-05-08 Matsushita Electric Industrial Co., Ltd. Procédé, dispositif et programme pour compression d'en-tête

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BORMANN C ET AL: "Request for Comments 3095, Robust header compression (ROHC), framework and four profiles: RTP, UDP, ESP and uncompressed", NETWORK WORKING GROUP REQUEST FOR COMMENTS, July 2001 (2001-07-01), pages 1 - 168, XP002220600 *
PRICE R, ET AL.: "Robust SCTP/IP Compression Using EPIC", IETF INTERNET DRAFT, 23 February 2001 (2001-02-23), pages 1 - 10, XP002240542, Retrieved from the Internet <URL:www.globecom.net/ietf> [retrieved on 20030508] *
SCHULZRINNE H ET AL.: "RTP: A transport protocol for Real-Time Applications, draft-ietf-avt-rtp-new-11.txt", IETF INTERNET DRAFT, 20 November 2001 (2001-11-20), pages 1 - 103, XP002239850, Retrieved from the Internet <URL:www.ietf.org> [retrieved on 20030430] *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2555510A2 (fr) * 2010-04-01 2013-02-06 LG Electronics Inc. Appareil d'émission de signal de diffusion, appareil de réception de signal de diffusion, et procédé d'émission-réception de signal de diffusion dans un appareil d'émission-réception de signal de diffusion
EP2555510A4 (fr) * 2010-04-01 2015-04-01 Lg Electronics Inc Appareil d'émission de signal de diffusion, appareil de réception de signal de diffusion, et procédé d'émission-réception de signal de diffusion dans un appareil d'émission-réception de signal de diffusion
US9143271B2 (en) 2010-04-01 2015-09-22 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcast signal receiving apparatus, and broadcast signal transceiving method in a broadcast signal transceiving apparatus
US9300435B2 (en) 2010-04-01 2016-03-29 Lg Electronics Inc. Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, and broadcast signal transceiving method in a broadcast signal transceiving apparatus
EP3010160A1 (fr) * 2010-04-01 2016-04-20 LG Electronics Inc. Train de données ip-plp comprimé avec ofdm
US9432308B2 (en) 2010-04-01 2016-08-30 Lg Electronics Inc. Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, and broadcast signal transceiving method in a broadcast signal transceiving apparatus
US9490937B2 (en) 2010-04-01 2016-11-08 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcast signal receiving apparatus, and broadcast signal transceiving method in a broadcast signal transceiving apparatus
US10111133B2 (en) 2010-04-01 2018-10-23 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcast signal receiving apparatus, and broadcast signal transceiving method in a broadcast signal transceiving apparatus
US10123234B2 (en) 2010-04-01 2018-11-06 Lg Electronics Inc. Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, and broadcast signal transceiving method in a broadcast signal transceiving apparatus
GB2490212A (en) * 2011-04-08 2012-10-24 Samsung Electronics Co Ltd Frame strucutre and signalling for wireless broadcast system
GB2490212B (en) * 2011-04-08 2013-06-26 Samsung Electronics Co Ltd Frame structure and signalling for wireless broadcasting system

Also Published As

Publication number Publication date
US20040165527A1 (en) 2004-08-26
JP2004208292A (ja) 2004-07-22
CN1510881A (zh) 2004-07-07

Similar Documents

Publication Publication Date Title
EP1432196A1 (fr) Méthode de compression pour le trafic de commande dans la transmission de données média
CA2429571C (fr) Procede et systeme de transmission de paquets de donnees sans en-tetes via une liaison sans fil
KR101054598B1 (ko) 무선 네트워크의 다중-사용자 서비스를 위한 리포팅
RU2305908C2 (ru) Адаптивный способ оценивания скорости передачи мультимедийных данных
KR100663586B1 (ko) 헤더 압축에 의한 패킷 데이터의 송신 방법 및 장치
CN105743924B (zh) 无线ip网络中进行有效多媒体传递的方法和基站
US20040264433A1 (en) Wireless communication arrangements with header compression
JP2005509381A6 (ja) ヘッダ圧縮を行う無線通信装置
KR20050058371A (ko) 확장 헤더 압축
JP2005515651A (ja) 既知のパターンで変化するフィールドの削除を含むペイロードヘッダ抑制
JP4856251B2 (ja) 無線通信ネットワークにおけるヘッダの抑制
CN101567758B (zh) 用于控制发送速率的数据发送装置和方法
EP1533969A1 (fr) Rapport de pertes pour des services de transmission en continu à commutation par paquets en utilisant loss RLE report blocks
Fortuna et al. Header compressed VoIP in IEEE 802.11
Koistinen Protocol overview: RTP and RTCP
EP1773012A1 (fr) Procédé et dispositif pour le transport de services en mode circuit dans un réseau de transport en mode paquet
Kidston et al. Multihop multicast header compression in manets
Zhao et al. Cross-layer adaptive rate control for video transport over wireless ad hoc networks
Perkins Sending RTP Control Protocol (RTCP) feedback for congestion control in interactive multimedia conferences
Chen et al. Enhancing CRTP by retransmission for wireless networks
Lakkakorpi Voice in Packets: RTP, RTCP, Header Compression, Playout Algorithms, Terminal Requirements and Implementations
Naidu et al. Implementation of header compression in 3GPP LTE
KR101384125B1 (ko) 통신 시스템에서 맥 계층의 서비스 품질 파라미터 생성장치 및 방법
Perkins RFC 9392: Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences
Seeling et al. IP Overhead Considerations for Video Services

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO

17P Request for examination filed

Effective date: 20040825

17Q First examination report despatched

Effective date: 20040916

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SI SK TR

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

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

18D Application deemed to be withdrawn

Effective date: 20050127