EP1349342A1 - Procédé, unité de sorties, terminal, et produits de programmes informatiques de reconstruction d' un flux de données continu dans un point de reception d'un réseau à commutation de paquets - Google Patents

Procédé, unité de sorties, terminal, et produits de programmes informatiques de reconstruction d' un flux de données continu dans un point de reception d'un réseau à commutation de paquets Download PDF

Info

Publication number
EP1349342A1
EP1349342A1 EP02360111A EP02360111A EP1349342A1 EP 1349342 A1 EP1349342 A1 EP 1349342A1 EP 02360111 A EP02360111 A EP 02360111A EP 02360111 A EP02360111 A EP 02360111A EP 1349342 A1 EP1349342 A1 EP 1349342A1
Authority
EP
European Patent Office
Prior art keywords
packet
estimation
data
delay
value
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
EP02360111A
Other languages
German (de)
English (en)
Inventor
Heidrun Grob-Lipski
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel CIT SA
Alcatel SA
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 Alcatel CIT SA, Alcatel SA filed Critical Alcatel CIT SA
Priority to EP02360111A priority Critical patent/EP1349342A1/fr
Priority to US10/397,168 priority patent/US7889653B2/en
Publication of EP1349342A1 publication Critical patent/EP1349342A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • 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/80—Responding to QoS
    • 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/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6481—Speech, voice
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6489—Buffer Management, Threshold setting, Scheduling, Shaping
    • 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

Definitions

  • This invention relates to a method for reconstructing non-continuous packetized data of a continuous data stream like streamed media, voice, audio, or video from a data connection into a continuous data stream at the receiving point of a packet-based network as well as, an output unit, a terminal, and computer program products therefore.
  • the QoS requirements at network level are typically specified in terms of bounds on worst-case end-to-end delay on the worst-case packet loss rate and on the worst-case delay jitter for packets of the connection. Other parameters may be specified as well, such as deadline miss rate.
  • the desired delivery time for each message across the network is bounded by a deadline, a specific maximum delivery delay. This delay bound is an application-layer, end-to-end timing constraint.
  • delay jitter which is the variation in delay experienced by packets in a single connection, is a critical performance metric. For example, in video transmission, jitter may cause some frames to arrive early, and others to arrive late. Although the transmission of all frames satisfies the deadline requirement, the displayed movie may appear jittery. Same applies to streamed audio data.
  • Buffers at the receiver can be used to control delay jitter.
  • the amount of buffer space required can be determined from the peak rate and the delay jitter of the delivery process and can be quite large for a network with no control of delay.
  • Streamed data is a data sequence that is transmitted and processed continuously. Streaming is the process of continuously appending data to a data stream.
  • a packet is a piece of data consisting of a header and a payload information. Packetizing is the process of decomposing data into a set of (small) packets, where the header is used to store information for reconstruction, e.g. a sequence number.
  • a data channel is a connection between two network units that is able to transport data. Delay is the time between sending and receiving a packet. Delay jitter is the variation in delay. Packet loss is an infinite delay.
  • a common used technique for streamed data is to use a buffer at the receiver for reducing delay jitter and packet loss against an increased overall delay.
  • a buffer at the receiver for reducing delay jitter and packet loss against an increased overall delay.
  • Especially real-time streamed data like video or audio streams, needs to be on-line processed, i.e., with small delay and small jitter delay.
  • a well known algorithm to solve this problem is to buffer streamed data and to replay the buffer at a constant speed to absorb delay variations and play-out packets at fixed deadline, called jitter absorption. Packets received after deadline are discarded.
  • a more sophisticated algorithm is to monitor delay and/or delay variation and adapt play-out time accordingly, called jitter adaptation. An application might then slow down play-out when delay increases to avoid loss and speed up play-out when delay decreases to reduce delay.
  • the present invention is a method for reconstructing non-continuous packetized data of a continuous data stream like streamed media, voice, audio, or video from a data connection into a continuous data stream at the receiving point of a packet-based network, comprising the steps of
  • the essential idea of the invention is iterative gathering network observations for a statistical prediction of network behavior, and adapting iterative said converting method according to said prediction.
  • the present invention uses a continuous optimization for adapting the parameters of a conversion method. This optimization decomposes into three steps. Continuously gathering network observations, i.e. quality of service measurements, deriving a statistical prediction from these network observations, and adapting the parameters of the conversion method according to said prediction.
  • Figure 1 shows of a network B1 two data channels B2, an output unit B3, and two terminals, a computer terminal B4 and a telephone terminal B5.
  • the terminal B4 has an output unit B3.
  • This output unit B3 is connected via a data channel B2 with a network B1.
  • the telephone terminal B5 is as well connected with the network B1 via a data channel B2.
  • Both terminals B4, B5 in the role of a receiver, are connected with the network B1 via data channels B2.
  • the terminals receive packets over the data channels and these packets contain streamed data, which has to be reconstructed.
  • output unit B3 To be able to reconstruct the data stream, there might be a special hardware, called output unit B3, that alternatively might be integrated in the terminal.
  • the terminal and the output unit are assumed to be controlled by a computer program.
  • Figure 2. shows a control entity A1, a buffer queue A2, an input channel A3, an output stream A4, an input packet sequence A5, an output data stream A6 and an illustration of two time intervals A7 between two consecutive packets also known as packet inter-arrival times.
  • the control entity A1 controls the buffer queue A2, i.e. when the queue has to be emptied and filled.
  • the buffer queue A2 is connected with the input channel A3 transporting the input packet sequence A5.
  • the input packet sequence A5 consists of a sequence of packets A5, where each packet having a packet sequence number 15,16, ..., 20. This input packet sequence A5 needs not coinciding with the packet number sequence as illustrated in the drawing.
  • the figure does not show the packet representation, i.e. header, payload, etc.
  • the buffer queue A2 is also connected with the output stream A4 transporting the ordered continuous output data stream A6.
  • the output stream is ordered by packet numbers and the time interval between two consecutive packets disappears, by using the previously buffered reservoir.
  • the output stream data carries data from packets 1,2,3,4,5
  • the buffer queue A2 stores packets 6, 7, 8, 9, 10, 11, 12, 13, and the input channel data A5 consists of the packets 15, 14, 16, 17, 19, 18, 20.
  • the figure illustrates the functionality of reconstructing a data stream.
  • the arriving packets, each having its number, are translated into an ordered continuous data stream where the data is ordered by the packet numbers and the time interval between the content of two consecutive packets disappears.
  • the network might have additional characteristics, e.g. an asserted delay bound that should be taken into account when implementing the described functionality.
  • there is no packet loss In case of packet loss additional strategies have to be considered beside buffering, e.g., reconstruction of packet information on the application layer or depending if network resources and time are available an additional request for re-transmission.
  • Figure 3 shows a use case diagram according to the UML notation, from the 'Unified Modeling Language User Guide', G. Booch, J. Rumbaugh, I. Jacobson, Addison-Wesley, Reading MA, 1999, pages 233 - 236, containing the actors "Network” and “Application”, as well as a use case “Converter” and a use case “Control”.
  • the "Network” is associated with the “Converter” by "Data channel”
  • the "Application” is associated with the "Converter” by "Data stream”.
  • the "Converter” is extended by the "Control”.
  • the diagram shows the problem context, namely the data channel “Data channel” supporting the jittered packet data stream shown in Figure 2, and a application “Application” requesting the reconstructed continuous streamed data.
  • This reconstruction is performed by a controlled converter “Converter” extended by “Control”.
  • the control mechanism is explicitly stated. It might be hidden by other use cases as side effects, e.g. a scheduler integrated in an operating system.
  • Figure 4. shows a class diagram according to the UML Notation, from the 'Unified Modeling Language User Guide', G. Booch, J. Rumbaugh, I. Jacobson, Addison-Wesley, Reading MA, 1999, pages 105 - 108, containing the data types "Channel”, “Stream”, and “PriorityQueue”; the processes “Receive” and “Stream”; and a class “Estimation”.
  • “Channel” provides the two methods “End” and “Fetch”.
  • “Stream” provides the two methods “Append” and "Read”.
  • “PriorityQueue” provides four methods "Add”, “Get”, “IsEmpty”, and "Size”.
  • the diagram shows an architecture for streamed data reconstruction.
  • This architecture has a framework character. It is designed for illustration purposes. It allows to substitute the estimation and to simplify the description by abstraction.
  • An architecture of a realization is influenced by the complete product design.
  • the architecture consists of three abstract data types, a channel, a stream and a priority queue, as well as two processes, “Receive” and "Stream”.
  • the priority queue is chosen to illustrate the abstract buffering mechanism. It is not necessary to use abstract data types. For instance, a often used technique instead of a priority queue is a straight forward array implementation of a buffer queue.
  • the data type "Channel” is aggregated by the process “Receive”.
  • the data type “Stream” is aggregated by the process “Stream”.
  • the data type "PriorityQueue” and the class “Estimation” are both associated to both processes “Receive” and "Stream”.
  • the method “End” of the data type “Channel” returns the Boolean true when the last packet of the packet sequence has arrived, the Boolean false otherwise.
  • the method “Fetch” returns the next received packet.
  • the method “Append” of the data type “Stream” appends the argument to the end of this stream.
  • the method “Read” reads the head of this stream (destructive).
  • the method “Add” of the data type “PriorityQueue” enters the argument into this priority queue.
  • the method “Get” returns the least element of this priority queue.
  • the method “isEmpty” returns the Boolean true if this priority queue contains no element, the Boolean false otherwise.
  • the method “Size” returns the number of elements contained in this priority queue.
  • the method “Measure” of the class “Estimation” collects network performance information and updates network characteristics accordingly.
  • the method “Predict” returns values for controlling the behavior of the two processes.
  • the two processes are controlled by the class “Estimation” that measures network behavior and derives network performance predictions.
  • the two processes “Receive” and “Stream” use this prediction in order to adapt their behavior, e.g. the use of the buffer queue or the stream speed etc.
  • Figure 5 shows a program implementing the architecture for streamed data reconstruction of Figure 4.
  • the abstract notation for the program consists of a declaration part for variables and types, labeled by 'DECLARATION' and an implementation part labeled by 'IMPLEMENTATION'.
  • the variable declaration part consists of three objects:
  • the type declaration part consists of three data types:
  • the process iterative reads a packet from the input channel, update the performance statistic of the network and buffers the packet, until the last packet is arrived.
  • the process "Stream” consists of a main loop, framed by 'WHILE' and 'END WHILE', with the terminating condition 'NOT (Input.End() AND Buffer.isEmpty())' and a body consisting of the statement 'Estimation.Predict(BufferSize, DelayTime)' followed by a sequence of further while loops.
  • the first while loop, framed by 'WHILE' and 'WAIT END WHILE' has the terminating condition 'Buffer.Size() ⁇ BufferSize' waits until the buffer is filled according to the predicted value Buffer.Size.
  • the kernel of the described program and the control of the processes and the buffer is the class "Estimation".
  • This class contains the variable "meanDelay”. In general this class contains variables for measured network characteristics.
  • the class "Estimation” consists of a set of variables for the statistical observations and two methods,
  • Figure 6. shows a program implementing a class Estimation introduced in Figure 5.
  • the class "Estimation” is framed by 'CLASS Estimation' and 'END CLASS Estimation' and contains five variables, three reals “T”, “sr”, and “tr”, as well as two integers “R” and “n”, and two methods.
  • Figure 7 shows three diagrams, labeled by O1, O2, and O3.
  • the x-axis of each diagram is the time and the Y-axis are packets.
  • Diagram O1 shows encoding and packetisation
  • diagram O2 shows transportation through a network
  • diagram O3 shows the stream resuming at the receiver.
  • the figure depicts an encoding - transmission - decoding scenario.
  • Diagram O1 consists of a packet P (1,1) and two occurrences of packet P (2,1) .
  • Diagram O2 consists of a waiting packet W (2,1) and two total service time intervals N stag T S for each packet
  • Diagram O3 consists of a de-jittering delay T jit and a decoding delay T dec .
  • the diagrams are connected via three dashed arrows showing a path of packet P (2,1) .
  • the horizontal double arrows A 2 shows a time interval until packet P (2,1) arrives
  • the horizontal arrow W 2,1 shows a waiting time interval of packet P (2,1) .
  • a horizontal arrow N stag T S shows a service time interval of P (2,1)
  • a horizontal arrow d 2,1 shows a delay of packet P (2,1) .
  • Assumptions for the shown scenario are identical encoding (e.g.
  • Negative-exponentially distributed connection inter-arrival time A 2 is assumed at the encoder. Shown in diagram O2 a packet-based network delays discontinuously packets with a deterministic service time N stag T S . No priorities, no re-transmission, no overtaking, no change in routing, only real-time traffic, and no disturbing data traffic is assumed.
  • the packet P (2,1) is traced through the described scenario. At the sender this packet is created after the time A 2 starting from the creation event of the preceding packet P (1,1) . When the first packet is processed the packet P (2,1) enters the network. There it waits for the time W 2,1 . When the waiting time is passed the network transports the packet within time N stag T S to the receiver. At the receiver it is buffered for a time T jit and decoded within a time T dec .
  • the following section contains an example application for a stream transmission scenario where a size of a file to stream is known and a network that delays equally sized packets equally. Then considering the following intermediate scenario enabling one to determine the optimal buffer size for continuos streaming, i.e., the following three events coincide: buffer is empty, the file is completely transmitted, and the buffer is completely streamed. Because of the deterministic delay assumption there is no need for prediction. But the example shows the dependence of the scenario parameters and illustrates the adaptive buffer functionality. In an intermediate scenario there is a rest of the stream to transmit at the sender, called rest, of size R, a buffered stream, called buffer, of size B and a played stream at the sender.
  • the transmission rate tr is 1 / T
  • the stream rate is a constant, say sr.
  • the transmission time for the rest is R / tr
  • the time for streaming the rest and buffer is (R+B) / sr .
  • T(n) The mean delay T(n) for n transmitted packets each having its own delay t i is the sum delay t 1 + t 2 + ... + t n divided by n.
  • T(n + 1) (n * T(n) + t n + 1 ) / (n + 1).
  • the above discussion is illustrated as an implementation of class 'Estimation' shown in Figure 6.
  • the statistical model can be enhanced by observable properties of the network like packet routing, traffic, or network topology, and of the stream content itself, like length pauses and talk spurts in the case of voice data streams, as well as past transmissions or even past connections.
  • the following section describes a more complex application for the special case of reducing delay jitter for a packetized voice network, with minimal delay, i.e., small queues in the context and with the assumptions of Figure 6.
  • a set of recursive measurement and prediction equations, based on multiple probabilistic models is developed illustrating the claimed method.
  • the main assumptions are a constant inter-arrival time for the packets at the network during active voice, but no constant inter-departure time when arriving at the receiver.
  • T enc,P,dec N F T F + T LA + T enc + T dec
  • D N stag T S + W N
  • dejittering delay T jit .
  • the initial values for the statistical model are:
  • the following list contains the set of values for initialisation and adaptation.
  • the delay of the r th packet produced from the i th connection during busy period m is denoted as d k m + i,r .
  • W k m +l,r denotes the waiting time of packet number k m + i,r.
  • I i -1 describes the total inter-arrival period from the begin of route busy period m until network arrival instant of the r th packet of the i th connection.
  • Y i -1 is the Erlang distributed time interval of i -1 negative-exponentially distributed successive call inter-arrival time intervals.
  • r denotes the relative total inter-arrival time of the r th packet produced from the i th call.
  • the negative-exponentially distributed encoder inter-arrival time of the l th connection is named A k m +l .
  • the "Measure” method for this example initializes the statistic observations by gathering the following values during call set-up
  • the quality of service restriction for streamed voice data are for packet loss requirement t D r ⁇ t D ref + T (0) / jit + ( r - ref ) N F T F and for delay requirement d r + T (0) / jit ⁇ d E2E .
  • the waiting time summarises the complete busy period until packet number k m + i ,.
  • the total number of network packet arrivals from the begin of the busy period m until service begin of the observed packet is q k m + i,r .
  • connection j 2, ..., i
  • the amount of additional packets from calls arriving after the observed connection i until network arrival instant of packet number r is Number of additional packet arrivals of previous connections between i th connection arrival instant and network arrival instant of packet r from connection i is
  • the mean delay of an arbitrary packet is
  • Average minimum amount of additional packets from previous connections at network arrival instant of packet number r is and of an arbitrary packet
  • Mean total inter-arrival time of an arbitrary packet is and for the i th call: and for the r th packet:

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
EP02360111A 2002-03-28 2002-03-28 Procédé, unité de sorties, terminal, et produits de programmes informatiques de reconstruction d' un flux de données continu dans un point de reception d'un réseau à commutation de paquets Withdrawn EP1349342A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP02360111A EP1349342A1 (fr) 2002-03-28 2002-03-28 Procédé, unité de sorties, terminal, et produits de programmes informatiques de reconstruction d' un flux de données continu dans un point de reception d'un réseau à commutation de paquets
US10/397,168 US7889653B2 (en) 2002-03-28 2003-03-27 Method, output unit, and terminal for reconstructing non-continuous packetized data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP02360111A EP1349342A1 (fr) 2002-03-28 2002-03-28 Procédé, unité de sorties, terminal, et produits de programmes informatiques de reconstruction d' un flux de données continu dans un point de reception d'un réseau à commutation de paquets

Publications (1)

Publication Number Publication Date
EP1349342A1 true EP1349342A1 (fr) 2003-10-01

Family

ID=27798944

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02360111A Withdrawn EP1349342A1 (fr) 2002-03-28 2002-03-28 Procédé, unité de sorties, terminal, et produits de programmes informatiques de reconstruction d' un flux de données continu dans un point de reception d'un réseau à commutation de paquets

Country Status (2)

Country Link
US (1) US7889653B2 (fr)
EP (1) EP1349342A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1678577A2 (fr) * 2003-10-29 2006-07-12 Nokia Corporation Methode et appareil assurant une gestion adaptative aisee de paquets ayant un contenu ordonne dans le temps dans un terminal de reception

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7822073B2 (en) * 2005-11-03 2010-10-26 George Mason Intellectual Properties, Inc. Packet flow side channel
US9236039B2 (en) 2013-03-04 2016-01-12 Empire Technology Development Llc Virtual instrument playing scheme
US9794260B2 (en) * 2015-08-10 2017-10-17 Yoti Ltd Liveness detection
US11503506B2 (en) * 2016-09-08 2022-11-15 Nec Corporation Base station device, wireless communication control method, and recording medium having base station control program stored therein
US11336683B2 (en) * 2019-10-16 2022-05-17 Citrix Systems, Inc. Systems and methods for preventing replay attacks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001033787A1 (fr) * 1999-10-29 2001-05-10 Array Telecom Corporation Procede, systeme et produit de programme informatique pour gerer les gigues
US6259677B1 (en) * 1998-09-30 2001-07-10 Cisco Technology, Inc. Clock synchronization and dynamic jitter management for voice over IP and real-time data

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4771250A (en) * 1987-08-13 1988-09-13 United States Of America As Represented By The Administrator, National Aeronautics And Space Adminstration Digital phase-lock loop having an estimator and predictor of error
US5623483A (en) * 1995-05-11 1997-04-22 Lucent Technologies Inc. Synchronization system for networked multimedia streams
US6304551B1 (en) * 1997-03-21 2001-10-16 Nec Usa, Inc. Real-time estimation and dynamic renegotiation of UPC values for arbitrary traffic sources in ATM networks
US6985501B2 (en) * 2000-04-07 2006-01-10 Ntt Docomo, Inc. Device and method for reducing delay jitter in data transmission
US7177271B2 (en) * 2001-09-21 2007-02-13 Microsoft Corporation Method and system for managing admission to a network
US7079486B2 (en) * 2002-02-13 2006-07-18 Agere Systems Inc. Adaptive threshold based jitter buffer management for packetized data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6259677B1 (en) * 1998-09-30 2001-07-10 Cisco Technology, Inc. Clock synchronization and dynamic jitter management for voice over IP and real-time data
WO2001033787A1 (fr) * 1999-10-29 2001-05-10 Array Telecom Corporation Procede, systeme et produit de programme informatique pour gerer les gigues

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AGRAWAL P ET AL: "Use of statistical methods to reduce delays for media playback buffering", MULTIMEDIA COMPUTING AND SYSTEMS, 1998. PROCEEDINGS. IEEE INTERNATIONAL CONFERENCE ON AUSTIN, TX, USA 28 JUNE-1 JULY 1998, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 28 June 1998 (1998-06-28), pages 259 - 263, XP010291583, ISBN: 0-8186-8557-3 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1678577A2 (fr) * 2003-10-29 2006-07-12 Nokia Corporation Methode et appareil assurant une gestion adaptative aisee de paquets ayant un contenu ordonne dans le temps dans un terminal de reception
EP1678577A4 (fr) * 2003-10-29 2007-05-30 Nokia Corp Methode et appareil assurant une gestion adaptative aisee de paquets ayant un contenu ordonne dans le temps dans un terminal de reception
US7457282B2 (en) 2003-10-29 2008-11-25 Nokia Corporation Method and apparatus providing smooth adaptive management of packets containing time-ordered content at a receiving terminal

Also Published As

Publication number Publication date
US7889653B2 (en) 2011-02-15
US20030185246A1 (en) 2003-10-02

Similar Documents

Publication Publication Date Title
Aras et al. Real-time communication in packet-switched networks
Jha et al. Engineering Internet QoS
Laoutaris et al. Intrastream synchronization for continuous media streams: A survey of playout schedulers
Little et al. Multimedia synchronization protocols for broadband integrated services
Salehi et al. Supporting stored video: Reducing rate variability and end-to-end resource requirements through optimal smoothing
Ramanathan et al. Feedback techniques for intra-media continuity and inter-media synchronization in distributed multimedia systems
US8769591B2 (en) Fast channel change on a bandwidth constrained network
AU2008330261B2 (en) Play-out delay estimation
Ishibashi et al. A comparative survey of synchronization algorithms for continuous media in network environments
TW200536310A (en) Packet scheduling for multimedia streaming based on priorities and buffer status
WO2001033787A1 (fr) Procede, systeme et produit de programme informatique pour gerer les gigues
Anderson Meta-scheduling for distributed continuous media
Xie et al. Adaptive multimedia synchronization in a teleconference system
Guo SRR: An O (1) time-complexity packet scheduler for flows in multiservice packet networks
Gibbon et al. The use of network delay estimation for multimedia data retrieval
Rexford et al. A smoothing proxy service for variable-bit-rate streaming video
Crutcher et al. The networked video jukebox
US7889653B2 (en) Method, output unit, and terminal for reconstructing non-continuous packetized data
Le Boudec et al. Optimal smoothing for guaranteed service
Feng Applications and extensions of the imprecise-computation model
Nahrstedt Quality of service in networked multimedia systems
Kim et al. A TMO-based software architecture for distributed real-time multimedia processing
Ingvaldsen et al. Determining the causes of end-to-end delay in CSCW applications
Baldi et al. Distortion-aware video communication with pipeline forwarding
McMahon et al. Investigation and modeling of traffic issues in immersive audio environments

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

17P Request for examination filed

Effective date: 20021128

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20031121

AKX Designation fees paid

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

17Q First examination report despatched

Effective date: 20031121

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ALCATEL LUCENT

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: 20091001