`
`(12)
`
`(cid:6)(cid:27)&(cid:11)(cid:11)(cid:12)(cid:18)(cid:18)(cid:18)(cid:20)(cid:17)(cid:20)(cid:23)(cid:12)(cid:6)
`EP 1 777 969 A1
`
`(11)
`
`(43) Date of publication:
`25.04.2007 Bulletin 2007/17
`
`EUROPEAN PATENT APPLICATION
`(51) Int Cl.:(cid:3)
`H04N7/46(2006.01)
`
`(21) Application number: 05256302.0
`
`(22) Date of filing: 10.10.2005
`
`(84) Designated Contracting States:
`AT BE BG CH CY CZ DE DK EE ES FI FR GB GR
`HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI
`SK TR
`Designated Extension States:
`AL BA HR MK YU
`
`(71) Applicant: BRITISH TELECOMMUNICATIONS
`public limited company
`London EC1A 7AJ (GB)(cid:3)
`
`(72) Inventor: The designation of the inventor has not
`yet been filed
`
`(74) Representative: Lloyd, Barry George William et al
`BT Group Legal
`Intellectual Property Department
`PP C5A
`BT Centre
`81 Newgate Street
`London EC1A 7AJ (GB)(cid:3)
`
`(54)
`
`Adaptive video transmission with variable frame rate
`
`(57)
`Video signals are sent via a network, such as
`an internet protocol network, the bandwidth of which var-
`ies with time. The amount of data to be sent is controlled
`by varying the frame rate. This is achieved by (a) meas-
`
`uring the transmission capacity to the receiver; (b) deter-
`mining the rate of change of transmission capacity; and
`(c) adjusting the transmitted video frame rate as a func-
`tion of the said rate of change.
`
`Printed by Jouve, 75001 PARIS (FR)
`
`EP1 777 969A1
`
`ERICSSON EXHIBIT 1011, Page 1
`
`
`
`1
`
`EP 1 777 969 A1
`
`2
`
`Description
`(cid:3)[0001] The present invention is concerned with the
`transmission of video signals via a network.
`(cid:3)[0002]
`In the future, the next generation communica-
`tion environment is envisaged as allowing users to roam
`freely and to communicate with each other at any time
`and any place [1]. Client devices with different capabili-
`ties, which range from low power mobile phones to high
`performance workstations, may be used for communica-
`tions. Users will be interconnected by networks with var-
`ious capacities, with packet loss rates that range from
`almost lossless transmission to quite error prone envi-
`ronments. The rapid development of the client device
`industry and the proliferation of network access technol-
`ogies is expected to result in the extensive growth of
`bandwidth-(cid:3)intensive real-(cid:3)time multimedia internetwork-
`ing applications (e.g. voice over IP, video streaming, vid-
`eo conferencing and so on).
`(cid:3)[0003] Real-(cid:3)time multimedia transmission over a var-
`iable bandwidth network environment requires a strict
`guarantee of network bandwidth and of several other
`quality of service (QoS) parameters, such as end-(cid:3)to-(cid:3)end
`delay, delay variation and packet loss. Unfortunately,
`most of the current QoS mechanisms in existing networks
`(such as wireless and mobile networks) do not provide
`such guarantees. In dynamic and unpredictable network
`environments, due to diverse forms of mobility and inter-
`ference at the air interface, it gives rise to varying band-
`width and dynamically changing error rates [2]. This fur-
`ther intensifies the challenge for consistent provision of
`QoS. Traditional QoS mechanisms (e.g. Integrated Serv-
`ices and Differentiated Services), which are typically de-
`signed for wired networks, assume a fixed network to-
`pology and a fixed amount of available resources. These
`are inadequate to satisfy users’ QoS requirements or to
`utilize the system resources efficiently, especially in
`bandwidth-(cid:3)limited and error prone network environ-
`ments.
`(cid:3)[0004]
`In order to solve this, adaptive multimedia ap-
`plications are proposed. By implementing adaptive ap-
`plications, media quality can, in the case of bandwidth
`variation of network, be adapted appropriately. The band-
`width of the media stream can be scaled down to provide
`a degraded quality at the destination. In this invention,
`we are particularly interested in the implementation of
`video applications. Adaptive video applications use pro-
`tocols such as Real-(cid:3)Time Streaming Protocol (RTSP)
`and Real-(cid:3)Time Protocol (RTP), to adapt to changing net-
`work conditions using a number of techniques. These
`techniques include hierarchical encoding, efficient com-
`pression, bandwidth smoothing, rate shaping, error con-
`trol, and adaptive synchronization. Feedback from lower
`networking layers can be used by the application layer
`and this helps to match the transmission to the available
`bandwidth as well as to increase the robustness of the
`video transmission. However, the perceived quality of
`video applications is being neglected. Variations of frame
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`2
`
`rates are proposed in some of these adaptive mecha-
`nisms [3] [4]. However, abrupt changes of frame rates
`can annoy users and hence have a severe impact on the
`perceived quality of such video applications.
`(cid:3)[0005] QoS provisioning is an important issue in real-
`time internetworking video applications. The dramatic
`fluctuation of network conditions further intensifies the
`problems of QoS provisioning. Under variable bandwidth
`network environments (such as users are moving from
`one network to another with different bandwidth capacity
`or network is being congested by heavy traffic), charac-
`teristics of video applications need to be adjusted in order
`to fit the requirements of the current operating network
`and also maintain the perceived QoS.
`(cid:3)[0006] An IBM document on QoS policies [5] clearly
`states that "the priority for smooth video is higher than
`the priority for frame quality". It points out that the impor-
`tance of smooth video is even more significant when us-
`ers are watching high motion videos (such as sports pro-
`grammes). Traditional adaptive frame rate variation
`mechanisms in video applications, which adjust the video
`requirements according to the rate supportable by the
`network, attempt to keep the quality of video constant by
`varying the frame rate. In these mechanisms, the per-
`ceived quality of video application is often degraded as
`frame rates are reduced to a much lower rate or being
`increased to a much higher rate in order to fit network
`conditions. The abrupt changes of frame rates (from high-
`er rate to lower rate and vice versa), which cause jerki-
`ness and unsteady video displays, annoy users who are
`expecting a smooth and continuous flow of video frames
`in real-(cid:3)time video applications. The users are able to no-
`tice the sudden change of frame rate in video transmis-
`sion. For example, a video application may be sending
`video at 25 frames per second (fps) during normal net-
`work condition and frame rate is reduced to 8fps when
`network congestion is detected; the frame rate is then
`increased to 15fps again when network conditions im-
`prove. This drastic fluctuation of frame rates will affect
`the smoothness of the video display and hence have a
`severe impact on perceived quality.
`(cid:3)[0007] References:(cid:3)
`1. T. Takebayashi et al, Approaches to User-(cid:3)Centric
`Computing System for Ubiquitous Solutions, Fujitsu
`Sci. Tech. J., 39, 2, December 2003, p.(cid:3)261-269.
`2. M. Naghshineh et al, End-(cid:3)to-(cid:3)End QoS Provision-
`ing in Multimedia Wireless/(cid:3)Mobile Networks Using
`an Adaptive Framework, IEEE Communication Mag-
`azine November 1997.
`3. J. Kim et al, TCP-(cid:3)Friendly Internet Video Stream-
`ing Employing Variable Frame-(cid:3)Rate Encoding and
`Interpolation, IEEE Transaction on Circuits and Sys-
`tems for Video Technology, Vol.(cid:3)10, NO.(cid:3)7, October
`2000.
`
`ERICSSON EXHIBIT 1011, Page 2
`
`
`
`3
`
`EP 1 777 969 A1
`
`4
`
`[4] W. Guetz et al., U.S. Patent 6,091,777.
`
`[5] IBM. Functions of mobile multimedia QoS control.
`http:(cid:3)//www.trl.ibm.com/(cid:3)projects/(cid:3)mmqos/(cid:3)system_
`e.htm.
`(cid:3)[0008] According to the present invention there is pro-
`vided a method of transmitting video over a network to a
`receiver, comprising repeatedly
`
`(a) measuring the transmission capacity to the re-
`ceiver;
`(b) determining the rate of change of transmission
`capacity;
`(c) adjusting the transmitted video frame rate as a
`function of the said rate of change.
`(cid:3)[0009] Other aspects of the invention are set out in the
`claims.
`(cid:3)[0010] Some embodiments of the invention will now
`be described, with reference to the accompanying draw-
`ings.
`(cid:3)[0011] The basic system operational view of our im-
`plementation is depicted in Figure 1. The figure shows
`one-(cid:3)way communication (sender-(cid:3)to-(cid:3)receiver), however,
`it can be implemented as a two-(cid:3)way communication ap-
`plication (client-(cid:3)to-(cid:3)client). Session Initiation Protocol
`(SIP) can be used to start a communication session be-
`tween two or more clients. Real-(cid:3)Time Protocol (RTP) and
`(cid:3)[0012] Real-(cid:3)Time Control Protocol (RTCP) can be
`used as underlying transport layer to send data packets
`and also control packets. In this implementation, Session
`Description Protocol (SDP) signalling can be used to re-
`set the parameters of a video conferencing session and
`send them to the receiving end.
`(cid:3)[0013] The video processor, which involves capture/
`display, encoder/(cid:3)decoder and transmitter/(cid:3)receiver, is
`mainly for media processing. The adaptation mechanism
`appears as a standalone module in the application. A
`scaling information database extracts and stores network
`statistical information (monitored periodically using a tim-
`er) and user profiles (set by users). The frame rate scaling
`module is the core mechanism which calculates a frame
`rate scaling factor based on information obtained from
`information database. A scaled frame rate will then be
`fed to the video processor for setting new video param-
`eters.
`(cid:3)[0014] Figure 2 illustrates how the different parameters
`influence the frame rate in the case of fluctuation in the
`network . To calculate the frame rate scaling factor, sev-
`eral parameters need to be taken into consideration.
`These parameters may include network statistics, RTCP
`feedback statistics and the user profile. The main con-
`tributor to the scaling factor is the network statistics,
`where the changes with time (D bandwidth/(cid:3)D
`t) are
`tracked.
`(cid:3)[0015] The sequence diagram (Figure 3) shows the
`activity flows of our implementation. The periodic adap-
`
`tive frame rate variation mechanism (shaded portion) is
`applied to avoid the situation that frame rate variation is
`only incurred when network congestion is detected. A
`timer is initiated for periodic network condition monitoring
`at the client end. The frame rate will be scaled based on
`the scaling factor extracted from scaling information as
`discussed previously. This will improve the perceived
`quality by giving a gradual change of frame rate and
`smooth playbacks of video throughout entire communi-
`cation.
`(cid:3)[0016] The control mechanism essentially comprises
`the following steps:(cid:3)
`
`(a) measurement, at intervals, of the network band-
`
`width B(cid:3)(ti);
`(b) determination of the gradient {B(cid:3)(ti) - B(cid:3)(ti-1))(cid:3)/(cid:3)(ti -
`ti-1);
`(c) determination of a scaling factor M, as a function
`of the gradient m;
`(d) determination of a new frame rate, multiplying
`the existing rate by the scaling factor - subject how-
`ever to the rate remaining within a range determined
`by preset maximum and minimum values..
`(cid:3)[0017]
`In more detail:(cid:3)
`
`(a) Bandwidth could be measured by any one of a
`number of conventional methods. If the communica-
`tion session is peer to peer within a similar subnet,
`say, in an enterprise scenario, the backhaul link of
`the connecting equipment could expose its band-
`width availability through its SNMP agent residing in
`that particular equipment. This could be queried via
`SNMP calls. On the other hand, in an environment
`when there are several nodes in the path of its com-
`munication, an application level implementation of
`measuring its delay and thus bottleneck within that
`particular path could be used. This would suggest
`bandwidth availability.(cid:3)
`Clearly it is important, in terms of reducing the risk
`of large changes in frame rate, to measure the band-
`width (and adjust the frame rate) at frequent intervals
`- that is to say, frequent in relation to the rate of
`change of network conditions. A typical rate might
`be every 10 seconds. It would be possible to meas-
`ure the bandwidth once per frame, but this is not
`preferred, in that it involves additional overheads. In
`theory the bandwidth could be measured more often
`than once per frame, but naturally the frame rate
`adjustment cannot occur more often than once per
`frame.
`(b) The gradient is determined by the formula given
`above. The use of the gradient rather than simply
`the absolute value of the bandwidth is significant be-
`cause it introduces an element of prediction into the
`assessment of bandwidth availability.
`(c) The determination of the scaling factor M as a
`function of the gradient m should be such that
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`3
`
`ERICSSON EXHIBIT 1011, Page 3
`
`
`
`5
`If m is large & positive, multiplier is >1;(cid:3)
`If m is small & positive, multiplier is > 1 (but smaller
`than when m is large);(cid:3)
`If m is 0, multiplier is 1;(cid:3)
`If m is small & negative, multiplier is <1;(cid:3)
`If m is large & negative, multiplier is <1 (but smaller
`than when m is small and negative.(cid:3)
`For example, a possible relationship for the situation
`where the bandwidth gradient is expected to vary
`over the range -50 to 50 kbit/s/s is: that M varies
`between 0.4 and 2.5. A simple, piecewise-(cid:3)linear im-
`plementation would be to specify that for m>0: M =
`1 + 0.03 m; for m=0: M = 1; and for m<0: M = 1 +
`0.012 m. However we prefer a nonlinear relationship
`in which frame rate changes are more extreme at
`the ends of the scale. Such a relationship would best
`be implemented by the use of a look-(cid:3)up table.
`(d) A typical limit range for frame rate might be from
`10 to 25 frames per second. Thus if the existing frame
`rate is fi then the new frame rate will be
`
`(cid:3)[0018] The user preferences referred to earlier could
`mean constraints on the level of adaptation that the user
`is prepared to live with in a congested network situation,
`i.e reaction time, image resolution resizing, colour depth.
`This could influence the extent for the need to switch to
`a lower frame rate.
`(cid:3)[0019]
`In order to achieve better perceived quality of
`real-(cid:3)time internetworking video application in variable
`bandwidth network environments, degradation of video
`quality needs to be occur gracefully. In the method we
`have described, an adaptive mechanism, which resides
`in the video application, allows smooth variation of frame
`rates under variable bandwidth network environments. It
`varies frame rates gradually and hence minimises the
`jerkiness and flickering of video displays. A gradual deg-
`radation or upgrade of video quality gives an illusion to
`users that there is only little change in video quality
`throughout the communication period. The variation in-
`curred is less aggressive and significant as compared
`with traditional frame rate variation mechanisms.
`(cid:3)[0020] The method improves the perceived QoS of re-
`al-(cid:3)time internetworking video applications by implement-
`ing smooth variation frame rate mechanism of adaptive
`video application. An adaptation mechanism resides in
`a real-(cid:3)time internetworking multimedia application to
`adapt video quality dynamically to changes in network
`conditions. Network conditions are absorbed and ana-
`lysed from time to time and network statistical analysis
`is then fed back to the video processor of the application.
`The application is then triggered to set the frame rate of
`the video to a requested rate based on the analysis of
`network conditions. The frame rate changes dynamically
`when network conditions vary - but not only when network
`
`EP 1 777 969 A1
`
`6
`
`congestion is detected. The degree of variation in frame
`rate depends on the degree of variation in network con-
`ditions (such as network utilization) and the variations of
`frame rates occur throughout the communication ses-
`sion. Hence, it prevents sudden changes in frame rate
`of the video transmission and helps to minimise the jerk-
`iness of video displays under variable bandwidth condi-
`tions. User preferences and profiles may also be taken
`into account when frame rate is being adjusted. This fur-
`ther improves user perceived QoS of the application.
`
`5
`
`10
`
`Claims
`
`15
`
`1. A method oftransmitting video over a network to a
`receiver, comprising repeatedly
`
`20
`
`25
`
`30
`
`(a) measuring the transmission capacity to the
`receiver;
`(b) determining the rate of change of transmis-
`sion capacity;
`(c) adjusting the transmitted video frame rate as
`a function of the said rate of change.
`
`2. A method according to claim 1 in which the frame
`rate is adjusted to equal the existing frame rate mul-
`tiplied by a factor which is a monotonically increasing
`function of rate of change of transmission capacity.
`
`3. A method according to claim 2 in which the factor is
`a nonlinear function of rate of change of transmission
`capacity.
`
`4. A method according to claim 3 in which the factor is
`obtained by means of a look-(cid:3)up table.
`
`35
`
`5. A method according to any one of the preceding
`claims in which the rate of change of transmission
`capacity is evaluated to determine whether an ad-
`justment of frame rate is necessary at regular inter-
`vals.
`
`40
`
`45
`
`50
`
`55
`
`4
`
`ERICSSON EXHIBIT 1011, Page 4
`
`
`
`EP 1 777 969 A1
`EP 1 777 969 A1
`
`Sender
`
`Receiver
`
`Analyser
`
`Scaling
`information |
`Database
`[
`
`Network
`
`Figure 1 Basic System Operational View
`
`
`
`
` Adaptation Mechanism
`
`Frame Rate Scaling Module
`
`
`NetworkStatistics
`
`
`
` Scaling Info.
`
`RTCP Statistics
`
`
`Database
`
`F(Z Scaling Info Db Params) UserProfile
`
`Capture Control
`
` Video Processor
`
`Figure 2
`
`5
`
`ERICSSON EXHIBIT 1011, Page 5
`
`ERICSSON EXHIBIT 1011, Page 5
`
`
`
`EP 1 777 969 A1
`EP 1 777 969 A1
`
`Video
`Processor
`
`Video
`
`Frame Rate
`Scaling
`
`Scaling
`Information
`
`
`
`[se][tom|(Sender) (Receiver) Module Database
`
`
` Processor|Senerdi Receiver
`
`
`!
`I
`I
`I
`
`||c
`
`SIP:INVITEfor video
`I
`|
`conferencing sessiog
`Check
`onferencingSessiog,
`|
`'
`availability for
`\
`SIP:OK
`'
`conferencing
`<———__
` :|_Starvidoosessioncofferencing Requestframd rate scaling factor || Requestscaling
`Start video conferencing session
`
`
`
`
`
`
`
`|
`{
`'
`i
`P|___information_y.'
`Analyse user
`i
`I
`I
`{
`I
`preferences
`!
`!
`1
`1
`!
`tot
`'
`|
`|
`!
`' Send scaling informatior!
`Analyse
`!
`|
`'
`'
`network
`,
`‘
`|
`\
`'
`i
`Calculate frame |\
`conditions
`Send frametate scaling factor
`\
`rate scaling facta
`'
`|
`+—— Capture video mages
`'
`t— at scaled fram rate
`|
`I
`J i
`«
`Encode video frames
`|
`!
`{
`t—— Packetize encoded video
`\
`Transmit RTP packets
`wd frames to RTP packets
`‘A
`I
`(
`|
`|
`i
`Transmit RTP pack
`Send recetved|RTP packets
`
`
`
`i
`{
`l
`\
`|
`Extract encoded video
`frames from RYP packets
`IS
`Decodevideoffames
`|
`‘
`Display decode video frames
`|
`I
`“
`Generate RTCe packets
`}
`,
`Send RTCP packets
`Tegnsmit RTCPpackets!
`
`Sendreceived RTCPpackets *
`Sbndreceived RTCPpackets
`.
`i
`
`
`oeT
`
`
`{
`
`'
`
`I
`I
`
`(
`
`‘
`
`!iT
`
`
`$e3Sa18eea3
`ase
`
`
`
`
`pee
`
`| Resetframer tie :
`
`conferencingsession. :
`'"Send SDP message |
`t with new,.frame ral f
`i ——,
`
`Figure 3 Sequence Diagram of Adaptive Video Frame Rate Application
`
`6
`
`ERICSSON EXHIBIT 1011, Page 6
`
`ERICSSON EXHIBIT 1011, Page 6
`
`
`
`EP 1 777 969 A1
`EP 1 777 969 A1
`
`0) EuropeanPatent
`
`Office
`
`EUROPEANSEARCH REPORT
`
`ApplicationNumber
`
`EP 05 25 6302
`
`
`
`Category
`
`DOCUMENTS CONSIDEREDTO BE RELEVANT
`Citation ofdocumentnaseayes where appropriate,
`KIM JONGWON ET AL:
`"TCP-Friendly Internet}1-5
`Video Streaming Employing Variable
`Frame-Rate Encoding and Interpolation"
`IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS
`FOR VIDEO TECHNOLOGY,
`IEEE SERVICE CENTER,
`PISCATAWAY, NJ, US,
`vol. 10, no. 7,
`1 October 2000 (2000-10-01), pages
`1164-1177, XP002369021
`ISSN: 1051-8215
`* page 1168,
`left-hand column, paragraph B
`*
`
`APPLICATION(IPC) THE
`HO4N7 /46
`
`Nh
`
`"CONSTRAINED BIT-RATE
`REED E C ET AL:
`CONTROL FOR VERY LOW BIT-RATE
`STREAMING-VIDEO APPLICATIONS"
`IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS
`FOR VIDEO TECHNOLOGY,
`IEEE SERVICE CENTER,
`PISCATAWAY, NJ, US,
`vol. 11, no. 7, July 2001 (2001-07), pages
`882-889, XP001083363
`ISSN: 1051-8215
`* page 885, right-hand column - page 886,
`Jeft-hand column *
`
`"A
`N. SEELAM, P. SETHI, W.FENG:
`hysteresis based approach for quality,
`frame rate, and buffer management for
`video streaming using TCP"
`SPRINGER VERLAG,
`INTERNATIONAL CONFERENCE
`ON MANAGEMENT OF MULTIMEDIA NETWORKS AND
`SERVICES,
`vol. 2216, 29 October 2001 (2001-10-29),
`pages 1-15, XP002374403
`* paragraph [3.1.3] *
`
`TECHNICALFIELDS
`SEARCHED
`(re)
`HO4N
`
`The present search report has been drawnup for all claims
`Place of search
`Date of completion of the search
`
`Examiner
`
`Berlin
`CATEGORYOF CITED DOCUMENTS
`
`X : particularly relevantif taken alone
`Y : particularly relevantif combined with another
`documentof the same category
`A:technologicalbackground
`O :non-written disclosure
`P : intermediate document
`
`Raeymaekers,
`28 March 2006
`T : theory or principle underlying the invention
`E : earlier patent document, but published on, or
`after thefiling date
`D: documentcited in the application
`L : documentcited for other reasons
`ett tee teeaeetaetce ee cetaneees aes ceseeeseeeaecieeenetaeeieeceesaaeeaesesceaseetneteeiiees
`& : memberof the samepatent family, corresponding
`decument
`
`P
`
`5o
`3ao
`a
`3
`3
`8
`=
`x
`9
`oO
`i
`
`7
`7
`
`ERICSSON EXHIBIT 1011, Page 7
`
`ERICSSON EXHIBIT 1011, Page 7
`
`
`
`
`
`
`
`EP 1 777 969 A1
`EP 1 777 969 A1
`
`0) EuropeanPatent
`
`Office
`
`EUROPEANSEARCH REPORT
`
`ApplicationNumber
`
`EP 05 25 6302
`
`DOCUMENTS CONSIDEREDTO BE RELEVANT
`
`Citation of documentwith indication, where appropriate,
`of relevant passages
`
`Relevant
`to claim
`
`CLASSIFICATION OF THE
`APPLICATION (IPC)
`
`"The performance of
`NEE P ET AL:
`two-dimensional media scaling for Internet
`videoconferencing"
`NETWORK AND OPERATING SYSTEM SUPPORT FOR
`DIGITAL AUDIO AND VIDEO, 1997.,
`PROCEEDINGS OF THE IEEE 7TH INTERNATIONAL
`WORKSHOP ON ST. LOUIS, MO, USA 19-21 MAY
`1997, NEW YORK, NY, USA,IEEE, US,
`19 May 1997 (1997-05-19), pages 223-234,
`XP010251701
`ISBN: Q-7803-3799-9
`* page 226, right-hand column *
`
`TECHNICAL FIELDS
`SEARCHED
`(IPC)
`
`The present search report has been drawnupforall claims
`Place of search
`Date of completion of the search
`
`Examiner
`
`Berlin
`CATEGORYOF CITED DOCUMENTS
`
`Raeymaekers,
`28 March 2006
`T : theory or principle underlying the invention
`E: earlier patent document, but published on, or
`afterthefiling date
`X : particularly relevantif taken alone
`D : documentcited in the application
`Y : particularly relevantif combined with another
`L: documentcited for other reasons
`documentof the same category
`ie cctettettee ete tattees eee cecseeeaetae cee eaeaeaseee ea eecageeaeee cies eenesaeeeieceeaseaes
`A:technologicalbackground
`O: non-written disclosure
`& : memberof the same patent family, corresponding
`P : intermediate document
`document
`
`
`P
`
`8
`8
`
`ERICSSON EXHIBIT 1011, Page 8
`
`Po
`
`
`
`
`
`EPOFORM150303.82(P04C01)
`
`ERICSSON EXHIBIT 1011, Page 8
`
`
`
`REFERENCES CITED IN THE DESCRIPTION
`
`EP 1 777 969 A1
`
`This list of references cited by the applicant is for the reader’s convenience only. It does not form part of the European
`patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be
`excluded and the EPO disclaims all liability in this regard.
`
`Patent documents cited in the description
`
`•
`
`US 6091777 A, W. Guetz [0007]
`
`Non-patent literature cited in the description
`
`•
`
`T. TAKEBAYASHI et al. Approaches to User-Centric
`Computing System for Ubiquitous Solutions. Fujitsu
`Sci. Tech. J., 02 December 2003, vol. 39, 261-269
`[0007]
`• M. NAGHSHINEH et al. End-to-End QoS Provision-
`ing in Multimedia Wireless/Mobile Networks Using an
`Adaptive Framework. IEEE Communication Maga-
`zine, November 1997 [0007]
`
`•
`
`•
`
`J. KIM et al. TCP-Friendly Internet Video Streaming
`Employing Variable Frame-Rate Encoding and Inter-
`polation. IEEE Transaction on Circuits and Systems
`for Video Technology, October 2000, vol. 10 (7
`[0007]
`IBM. Functions of mobile multimedia QoS control,
`ht-
`tp://www.trl.ibm.com/projects/mmqos/system_e.ht
`m [0007]
`
`9
`
`ERICSSON EXHIBIT 1011, Page 9
`
`