throbber
(19)
`
`(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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket