EP1580914A1 - Method and system for controlling operation of a network - Google Patents

Abstract

A system for controlling operation of a networksuch as a WLAN (200, 300) where at least oneinformation stream is delivered to at least one user(250, 260; 350, 360) via at least one link exposed tovariable operating conditions. The system includes:

• a controller module (410) configured formonitoring the operating conditions (400, 410) of saidlink, and
• at least one transcoder (210, 310) configuredfor selectively transcoding (210, 310) the informationstream by selectively varying one or more transcodingparameters as a function of the operating conditionsmonitored.

Description

Field of the invention
• The present invention relates to communicationsystems, and was developed by paying specific attentionto the possible application to Wireless LAN (Local AreaNetwork) systems, such as e.g. Wireless LAN (WLAN)transmission systems adapted to provide audio/video(A/V) streaming services.
Description of the related art
• While WLAN systems are becoming increasinglypopular not only for data, but also for real-timestreaming applications, the possible variations of thewireless link conditions in a home environment (due toe.g. propagation effects, interference and trafficgenerated by other devices) make the bandwidthavailable for Audio/Video streaming a highly variablefactor.
• Consumer Electronics (CE) manufacturers are thusinterested in using a domestic WLANs to distributeaudiovisual content among entertainment devices andPCs.
• However, the lack of Quality of Service (QoS)support in the standard as well as the variableconditions of the shared wireless channel make real-timeAudio/Video WLAN distribution in the home achallenging task.
• In fact streaming media over a Wireless LAN isrelatively simple in the ideal case of a channel with alimited error rate and without interference. Inpractice, however, the attenuation of the signal causedby walls and multipath effects of a closed environmentlike the home, sometimes result in a high (andvariable) bit error rate. Furthermore, as wirelessequipment in the 2.4 GHz ISM band is becomingcommonplace, multiple users may be sharing the sameradio spectrum in an uncoordinated way, therebyproducing mutual interference.
• The effect of a plurality of devices sharing theradio spectrum and the variable bit error ratesassociated with the wireless links result in thebandwidth available for streaming audiovisual contentbeing not constant.
• The consequence of transmission errors andinterference is twofold. Firstly, there is a bandwidthwaste caused by frame retransmissions. Secondly, suchretransmissions increase the jitter of frames of areal-time flow that arrive at the receiver: a biggerbuffer is therefore needed to compensate for delayvariations.
• A typical home networking scenario is depicted inFigure 1, where a Set-Top Box (STB) 110, that alsoplays the role of the access point of a WLAN, isreceiving an input stream (e.g. TV signals from anaerial) and distributes it to one or more TV-sets 120in a home, by way of aconnection 125 included in aWireless LAN network 140. At the same time, alaptop130 is accessing the Internet 150 through theWLANaccess point 110 using aconnection 135 also includedin theWLAN 140.
• In this scenario, the TCP/IP connection 155 coulduse a significant portion of the radio bandwidth,especially if the Internet connection is broadband.
• This situation results in a decrease in thebandwidth available for the real-time stream. In thecommon case where the video source cannot adapt thesource-coding rate to the variable channel capacity, aloss of packets is experienced at the receiver, with anunacceptable video quality. This phenomenon may be"bursty" and not predictable.
• Those of skill in the art will appreciate thatother home WLAN topologies than the one presented inFigure 1 are possible, wherein the same remarks made inthe foregoing identically apply.
• Several solutions have been proposed to solve theproblem of robust real-time streaming over packetnetworks (including Wireless LANs).
• By way of example, inhttp://www.vixs.com/prod xcode.html, an arrangement isdescribed where a transcoder (Xcode chip) uses channelsampling and real-time transcoding and transrating ofMPEG-1, MPEG-2 or MPEG-4 video streams to give agraceful degradation in overall picture quality inresponse to instantaneous and generally reducedavailable channel bit-rates. Once installed, the Xcoderperforms channel monitoring to detect instances ofreduced channel bit-rate and notifies the controller (aMIPS32 Kmc) of any deviations. The controller theninstructs a dedicated transcoding/transrating processorto alter the encoding scheme and level of encoding inreal-time to guarantee the 30 frames/s.
• The arrangement in question aims at guaranteeing30 frames per second in all situations. In fact, whenscenes with low motion are being transmitted, framescan be skipped without noticeable quality degradation and with a significant bandwidth saving. Of course,this approach implies that the receiver is able to dealwith skipped frames properly.
• In US-A-20020054578 a "cross-layer" approach foradapting multimedia streaming resource allocation tovarying channel conditions in a 3G W-CDMA (WidebandCode Division Multiple Access) system is described.That approach can either minimize distortion or powerand specifically targets hybrid delay-constrained ARQ(Automatic Retransmission Request) and FEC (ForwardError Correction) mechanisms that are applied to baselayers and enhancements layers of a scalable videostream. In particular, the adaptation of the systemconsists of a dynamic allocation of bits to sourcecoding and channel coding depending on measured channelconditions. Source coding bit-rate is varied using"Fine Grained Scalability" and not transcoding as inthe invention solution. Furthermore this system istightly coupled with the 3G cellular communicationstandard.
• In US-A-20030018794 a system comprising astreaming server, a network gateway and a wireless hostis described, where the wireless host and the gatewaycooperate to inform the server about congestion in thenetwork and adverse conditions in the wireless channel.As a response to these events, the streaming server canadd more or less partial checksums to the video payloaddepending on the reported bit error rate and canretransmit packets when these are dropped in thewireless link. Therefore the streaming server isadapted to perform retransmissions of video packetsthat have been lost either because of networkcongestion or because of high bit error rates in thewireless link. This system inevitably requires clientfeedback to estimate the network conditions.
• In US-A-20030067872 a system for adapting thecharacteristics of streaming sources based on networkcongestion feedback is presented. There, networkcongestion is estimated by the client that is receivingthe media stream and it is reported back to the server.
• In US-B-6 049 549 a media control approach isdescribed where streaming of content with high QoSdemands is adapted to changing transmission mediumcharacteristics. That approach involves a resourcemanager that admits flows according to availableresources and a polling manager that polls stationsaccording to their traffic profile. Since Wireless LANsuse a CSMA/CA-type (Carrier Sense Multiple AccessCollision Avoidance) MAC, the concept of polling is notapplicable in this context without changes in theIEEE802.11 MAC. The system presented in US-B-6 049 549is adaptive only in the sense the polling sequence ischanged according to the monitored data transmissionsof the stations, i.e. the video stream beingtransmitted is not affected by such changes.
Object and summary of the invention
• The object of the present invention is thus toprovide an improved wireless transmission system foroptimized Audio/Video stream, able e.g. to dynamicallyvary the bit-rate of MPEG (Moving Picture ExpertsGroup) encoded streams depending on the wireless linkconditions.
• According to the present invention, the aboveobject is achieved by means of a method having thefeatures set forth in the claims that follow. Theinvention also relates to a corresponding system, arelated network as well as a related computer programproduct, loadable in the memory of at least one computer and including software code portions forperforming the steps of the method of the inventionwhen the product is run on a computer. As used herein,reference to such a computer program product isintended to be equivalent to reference to a computer-readablemedium containing instructions for controllinga computer system to coordinate the performance of themethod of the invention. Reference to "at least onecomputer" is evidently intended to highlight thepossibility for the present invention to be implementedin a distributed/ modular fashion.
• A preferred embodiment of the invention involvesthe use of a so-called Cross-Layer Controller (CLC)that operates on information coming from differentlayers of a protocol stack and which is able to setcritical parameters in various processing blocks in adynamic way. The CLC operates in strict coordinationwith the transcoder, the channel estimator and thedevice used.to split in packets the stream. All theblocks above can be implemented in a System on Chipthat resides in the WLAN access point or in a ConsumersElectronic CE device (e.g. a Set-Top Box) that isintended to distribute Audio/Video content in the home.
• Specifically, the arrangement described herein isbased on an architecture of the transmission systemwhere the Cross-Layer Controller (CLC) block estimatesthe Wireless LAN conditions, calculates the bandwidthavailable for Audio/Video streaming and consequentlydrives a A/V transcoder. The transcoder can vary thebit-rate at which the A/V stream is encoded and/orpossibly reduce the spatial and/or temporal resolutionthereof.
• The combination of CLC and video transcoder can beintegrated in a chipset to be used in such devices asset-top boxes and WLAN (Wireless LAN) access point that offer optimized A/V streaming support, therebyproviding product differentiation with respect tostandard WLAN equipment.
• In the arrangement described herein the channelconditions are estimated by the streaming serverwithout the cooperation of the client. The mainadvantage of that solution lies in that no dedicatedprotocol is needed between the server and the client toreport network congestion feedback.
• A preferred embodiment of the arrangementdescribed herein uses a transcoder in order to obtain acompressed video stream with a bit-rate following thevariations in the wireless bandwidth. Such a strategytypically involves: i) a channel estimator to computethe bandwidth available for Audio/Video streaming in aWireless LAN, ii) a transcoder to dynamically changethe bit-rate of the compressed stream and iii) astreaming server that splits the A/V content in packetsand transmits such packets according to the estimatedavailable bandwidth. The operations above are properlycoordinated to guarantee an acceptable quality of thereceived images.
Brief description of the annexed-drawings
• The invention will now be described, by way ofexample only, by referring to the enclosed figures ofdrawing, wherein:
• Figure 1 showing a typical WLAN home networkingscenario, has been described in the foregoing,
• Figure 2 shows the transcoding function in theoverall system architecture of the arrangementdescribed herein,
• Figure 3 is a block diagram that explains theCross-Layer Controller as used in the arrangementdescribed herein, and
• Figure 4 is a simplified block diagram of anAccess Point included in the arrangement describedherein.
Detailed description of preferred embodiments ofthe invention
• The arrangement described herein includes atransmission system architecture wherein a Cross-LayerController (CLC) block estimates the operatingconditions of Wireless LAN.
• Specifically, an adaptive video transcoder isadded to the WLAN access point or station. This is ableto dynamically vary the bit-rate of MPEG encodedstreams depending on the wireless link conditions asmeasured by a dedicated channel monitor softwarecomponent.
• Figure 2 shows two possible home networktopologies, 200 and 300, wherein transcoder blocks 210and 310 and achannel estimation block 400 areassociated to a digital set top box (STB) 220 and apersonal computer (PC) 320, respectively.
• On the left side of Figure 2, avideo streamer 230is located in the STB that transmits a video streamreceived to aTV set 250 using aWLAN connection 240.TheSTB 220 also communicates with aPC 260.
• On the right side of Figure 2, avideo streamer330 is located in thePC 320 that transmits the videostream to aTV set 350 using aWLAN connection 340. ThePC 320 also communicates with alaptop 360. Theblock370 indicates a WLAN access point and block 380indicates the Internet network.
• The transcoder blocks 210 and 310, and multimediastreaming blocks 230 and 330 in both networkarrangements are driven by a so-called Cross-LayerController (CLC) 410 associated with thechannelestimation block 400. The controller 410 processes thewireless channels and autonomously decides what portionof the available bandwidths must be dedicated to thestreams.
• The transcoder, 210 or 310, is instructed tochange accordingly the bit-rate of the video stream orto apply other stream manipulation functions on a GOP-by-GOP(Group of Pictures) basis, so the maximum rateof variations is e.g. approximately 500 ms. Thealgorithms used by the transcoder to reduce the videobit-rate of a stream are described in detail in thefollowing.
• Figure 3 shows two protocol stacks 500a and 500bof the devices that respectively transmit and receiveAudio/Video content through each of the WLANs shown.
• Specifically the two (transmitter/receiver) stacksin question may relate to operation of either of thetranscoders 210 or 310.
• In the transmitter protocol stack 500a thetransmitter, (designatedxcoder 510a in the following),takes an MPEG-2 video elementary stream indicated I(either coming from a DVD or from a DVB transportstream) as its input and applies thereto a algorithm toreduce the output bit-rate and/or to add robustness tothe video stream itself. Optionally, the xcoder 510amay have multiple output streams, for example whentechniques like "Fine Grained Scalability" or "MultipleDescriptions" are applied. The xcoder 510a may alsooutput the video streams using a different video-encodingstandard, like, for example, H.264.
• Each xcoder output stream is an elementary streamthat is split in packets before transmission. This isthe purpose of the Network Adaptation Layer/Real-timeTransport Protocol (NAL/RTP) block, 520a in Figure 3.
• This function may be accomplished according todifferent criteria, based on detected networkconditions. For example, when the WLAN is congested oris very noisy, shorter packets may be more appropriatethan larger ones. On the contrary, in good channelconditions, shorter packets coming from thevideoxcoder 510a may be aggregated into larger ones toreduce the packet header overhead.
• Once the video payload has been assembled an RTPheader is added and the packet is transmitted using aUDP (Unreliable Datagram Protocol)socket 530a towardsthe receiving device. In this embodiment, an IP-basedwireless network is assumed, where routing is performedbased on the Internet Protocol (IP).
• TheWLAN MAC layer 540a takes care of transmittingthe IP packet using the services of thephysical layer550a. Some parameters in theMAC layer 540a can bechanged dynamically: for example, when the WLAN iscongested, the maximum number of retransmission retriescan be reduced leading to better bandwidth utilization.
• Also, theMAC layer 540a collects a set ofmeasurements that can be read by theCLC 560 toestimate the conditions of the wireless channel.
• The UDP/IP layer 530a communicates with theCLC560 by means of the RTCP (Real-time Transport ControlProtocol) 570.
• The corresponding protocol stack 500b at thereceiver comprises the elements that are dual to thosein the transmitter protocol stack 500a. This protocolstack 500b comprises adecoder 510b, a NetworkAdaptation Layer/Real-time Transport Protocol (NAL/RTP)block 520b, a UDP/IP layer 530b, aMAC layer 540b and aphysical layer 550b.
• It will thus be appreciated that variousparameters are available at different layers to bedynamically changed in order to adapt the transmissioncharacteristics of an A/V stream to varying wirelessnetwork conditions. This is the responsibility of theCross-Layer Controller 410, whose operations will bedescribed in following.
• The Cross Layer Controller (CLC) block 410 is thecore module of the system, and it collects informationcoming from various elements included in the WLANsmonitored. That information may include information asto the 802.11 device driver, the RTP/RTCP softwaremodule,the streaming module.
• Based thereon the controller 410 and it estimatesthe parameters necessary for an application to optimizeits QoS.
• Estimating these parameters is not an easy task.The result of estimation depends on two factors:
• the number and accuracy of available statistics.For example an estimate based only on streamerstatistics cannot account for packet losses duringtransmission, while an estimate based on WLAN API(Application Programmers Interface) is usually relatedonly to the first transmission hop (if Access Pointcentric transmission is used it considers only thestation-Access Point link). Moreover in this last caseit is not always possible to obtain accurate estimateof the WLAN statistics;
• the algorithms used to obtain the estimates. Ingeneral, one of the key parameters to be estimated bythe CLC 410 is the bandwidth available for streamingA/V content in a WLAN. This depends i.a. on the numberof stations connected to an access point AP, their traffic patterns and their physical positions.Furthermore, the presence of other devices operating inthe same radio band can produce interference, wherebypacket retransmissions and overall bandwidth reductionmay ensue.
• An arrangement adapted to efficiently estimate atany time the bandwidth to be used by real-timestreaming application is extremely important in thiscontext.
• In that respect, it will be appreciated thatspecific bandwidth estimation method described hereinis in no way a mandatory requirement. The adaptivevideo streaming arrangement described herein can alsobe used in connection with other mechanisms fordetermining the available bandwidth.
• An exemplary embodiment of a "CLC" - "WLAN" APIinterface will now be described with reference tonetwork arrangement including at least one elementperforming the role of a Base Station System (BSS).
• Basically, two kinds of statistics can beidentified via such an interface: applicationstatistics and BSS load statistics.
• The application (per flow) statistics computed atthe MAC station level (Layer 2) on a single hop (fromthe station to the Access Point (AP) or from the AccessPoint to the station.
• If the application flow connects e.g. a firststation (STA1) to a second station (STA2) through theAccess P, only the STA1-AP info would be available:
• i) Data loss rate (% of unsent bits) includingRTP/UDP/IP headers. The current application data lossrate.
• a. Input parameters: application identifier
• b. Output parameters: data loss rate
• ii) Current throughput. Total number of bitssuccessfully transmitted in a second. This is a Layer 2throughput, includes RTP/UDP/IP headers.
• c. Input parameters: application identifier
• d. Output parameters: throughput
• iii) Maximum physical data rate. It is thephysical data rate used by the card over a link; mostlyall commercial cards change at runtime this valueaccording to channel conditions.
• e. Input parameters: application identifier
• f. Output parameters: physical data rate
• iv) Transmitted packet rate. Number of packetstransmitted in a second.
• g. Input parameters: application identifier
• h. Output parameters: transmitted packet rate
• BSS load statistics; these parameters have beenincluded in recent versions of 802.11e standard (>4.3)to provide an indication of BSS load condition.
• v) Channel utilization. The percentage of time theAccess Point (AP) sensed the medium busy, as indicatedby either the physical or virtual carrier sensemechanism. It can provide information about thecongestion level of the cell.
• vi) Available admission capacity. It specifies theremaining amount of bandwidth capacity available in aBSS.
• vii) Station count. The station count indicatesthe total number of STAs currently associated with thisBSS.
• In the following, the "CLC" - "RTP/RTCP" interfaceCLC-WLAN API interface is described.
• The RTCP RR are the RTCP Receiver Reports (see RFC3550 athttp://www.ietf.org) provided by the "RTP/RTCP"block. The UCL library function to be called by the"CLC" in order to get the RR messages is rtp_get_rr().
• The RR (Receiver Reports) packets can givefeedback about end-to-end transmission between thesender(s) and the receiver(s) by means of the followinginformation:
• The fraction of packets lost within the RTPstream. Each receiver calculates the number of RTPpackets lost divided by the number of RTP packets sentas part of the stream.
• The last sequence number received in the streamof RTP packets.
• The inter-arrival jitter, which is calculated asthe average inter-arrival time between successivepackets in the RTP stream.
• The RTCP APP are the RTCP Application specificpackets (see RFC 1889 athttp://www.ietf.org) providedby the "RTP/RTCP" block. APP packets could includeparameters read from the MAC and PHY layer of thegenerating 802.11 entity (Station or Access Point). APPpackets may be generated both by the sender(s) and thereceiver(s). Each end point can thus get informationabout its local MAC parameters, and about theparameters of its peer. RTCP APP use is optional sincethey would use proprietary protocol format.
• Now a description of the "CLC" - "Transcoder"interface is given by means of some parameterdefinitions:
• Suggested bit-rate: the maximum bit-rate that anapplication could use. The estimation should be used bythe application to adapt its output bit-rate.
• Data loss rate: this indicates the data lossrate, i.e. the percentage of data that the receiverapplication did not get. The transcoder may use thisparameter to adapt encoding robustness.
• Optimal packet size: this is the packet sizethat the streamer should use. Finally, the description of the "CLC"- "Streamer"interface is reported here in terms of parameterdescriptions.
• Streaming bit-rate: this is' the bit-ratemeasured by the streaming module, calculated as theamount of bits sent to the UDP buffer in a second. TheUDP buffer works in write blocking modality when full.It does not include RTP/UDP/IP headers.
• Transmitted packet rate: this refers to thenumber of packets sent to UDP buffer in a second.
• Streaming buffer filling: this indicates' thelevel of filling of the streaming buffer.
• Recommended Streaming bit-rate: the CLC may tellthe streamer to change the streaming bit-rate: in somecases this value may be different from the transcodingbit-rate.
• Data loss rate.
• Streaming packet size: the CLC may request thestreamer to adapt the packet size.
• Operation of the arrangement described herein isorganized in four basic steps or phases.
STEP OR PHASE 1 - Collection of statistics
• The CLC 401 periodically collects all theavailable statistics about the specific flow in whichthe transcoder is involved. The different kinds ofstatistics come from the WLAN driver, the RTP/RTCPblock and the Streamer block. As a rule, no guaranteeexsists that all of them are available at the same timein operating environment. In particular, if thereceiving station does not support RTCP, then the CLCcannot rely on RTCP statistics.
• The time period of updating these statistics ischosen as follows.
• According to RFC1889 the RTCP statistics areavailable only each 5 seconds, so this is the minimumtime interval to update them; however in RFC3550 thislimit no longer exists for high bit-rates, so RTCPstatistics are available each 360/br seconds, where bris the flow bit-rate expressed in kilobits per second.
• WLAN statistics: the time period is set to 1second, therefore the WLAN API will return the Layer 2throughput, packet loss rate, etc, averaged over 1second.
• Streamer statistics: the time period is set equalto 1 second.
STEP OR PHASE 2 - Statistics processing
• The statistics collected are then processed inorder to compute an average of them over a certainnumber of consecutive samples (each of them collectedduring the previous step or phase). The number ofsamples and the kind of average are chosen as follows.
• RTCP statistics: no processing is performed;content of RTCP reports is used as it is.
• WLAN statistics:
• the number of samples is set to 10. Withthe sampling period set to 1 second, it means thatthe average is computed over a time interval of 10seconds.
• the average is an arithmetic average.
• Streamer statistics. No processing is done: thevalues returned by the Streamer are supposed alreadyaveraged.
• The statistics are used to derive an average ofthe application throughput, data loss rate (DLR), delayand available bandwidth. These data can be comparedwith expected values in order to understand if adjustments to runtime application parameters arerequired.
• Operation of the arrangement described herein istotally independent of specific method used to computeapplication throughput, DLR, delay and availablebandwidth. An example of a possible way to estimatethese values is thus described just by way ofreference. As already indicated, other methods can beused, without compromising the validity of the overalladaptive streaming solution.
• The simplified exemplary algorithm describedherein is driven by the observed transmission bufferlevels and by MAC-level statistics provided by the WLANdevice driver.
• Other strategies may also take into account:
• explicit indications of bit-rate requested bythe application by means of suitable protocols (RSVP,UPnP) ;
• QoS Service Level Agreement violations: whenevera negotiated bit-rate (or delay or delay variation)cannot be met by the lower layers because of acongested wireless network, explicit signals are risenand can be handled at the application level by thebandwidth estimator;
• TCP-friendly RTP rate control algorithms thattake round trip time (RTT) into account;
• Explicit packet loss notifications sent by thereceiver;
• Explicit RTP packet retransmission requests sentby the application at the receiver.
STEP OR PHASE 3 - Computation of suggested bit-rateand optimal packet size
• This phase can be divided in two sub-steps.
• A first sub-step performs the computation of thesuggested bit-rate for each streaming application(transcoder and streamer couple).
• Assumption (i): a priority index is assigned toeach streaming application (or flow), the CLC 401 willconsider this field when allocates resources to flows.
• Assumption (ii): only a discrete number of bit-ratevalues in the range between the full video qualitybit-rate and the minimum video quality bit-rate can besuggested to the transcoder as working bit-rate,instead of the overall range of values between the samelimits. The minimum video quality bit-rate is theminimum value of bit-rate for a flow. The transcoderdoes not try to further decrease the transcoding bit-rateunder this value. If this value cannot beguaranteed (e.g. due to lack of bandwidth over thenetwork), then the flow should be paused or turned off.
• Assumption (iii): it is assumed that a schedulerexist able to allocate time slots to the differentflows according to their bit-rate requirements.
• The goal of the following approach is to guaranteeat least the minimum bit-rate for each flow, and toallocate the remaining bandwidth to the flows withhighest priority. This is achieved also by monitoringthe streaming buffer filling: when growing it meansthat the available bandwidth is less than the requiredvalue (and vice versa). Under the previous assumptions,the bit-rate for the transcoders and the streamers arecomputed, as shown in the following pseudo-code, by wayof procedures using well known instructions for BASIClanguage:
• LET F1 a threshold defined for each flow on thebasis of its characteristics

  

  

  
• The subsequent sub-step or sub-phase performs thecomputation of optimal packet size. If statistics aboutdifferent packet sizes and related PER over a specifiedlink are available, then the maximum packet size thatguarantees the expected PER is considered the optimalpacket size. If such statistics do not exist or nopacket size guarantees the expected PER, than theapplication packet size is divided by two until theexpected PER is obtained or the minimum packet size isreached.
STEP OR PHASE 4 - Communication of computedparameters to the transcoder
• This step can be performed by any Inter-ProcessCommunication method. The CLC 401 sends to thetranscoder a message formatted as follows:

  

  A special value (-1) is set in the field when it is notavailable
• Upon receiving the message, the transcoder isexpected:
• to change the transcoding process,
• to communicate the new target bit-rate to theStreamer; of course the new target bit-rate cannot begreater than the original target bit-rate (i.e., thebit-rate of the original video stream).
• Preferably, any transcoder included in thearrangement described herein should be able to optimizequantization, frame rate and size for optimal viewgiven the image content and the net rate available onthe channel. The transcoder will indicate the maximumbit-rate (the bit-rate that the transcoder shouldproduce, in terms of raw video data, i.e. the payloadof the network packets only, before any headerinsertion) and optimal packet size. The transcoder willdecide, based on the Q parameter, on the sequencecontent and on target rate, if to perform frame sizereduction and/or frame rate reduction, according to thefollowing pseudo code instructions:
  if (bit-rate< TH1)
     then reduce_frame_rate_and_frame_size();
  else if (bit-rate< TH2)
     then reduce_frame_size();
  else if (bit-rate< TH3)
     then reduce_frame_rate();
  else
     keep_original_frame_rate_and_size();
  TH1, TH2, TH3 are three empirical Thresholds, withTH1<TH2<TH3.
• After establishing what one out of the fourconditions is verified, the transcoder will adapt thequantization step to achieve the desired output bit-rate.
• The transcoder will also adapt the slicingstructure to the network requirements. For example, incase of small packets, the transcoder will typicallysplit larger slices into smaller ones. In case ofnegligible data_loss_rate, the transcoder could, incase of small slices, fuse them together (as much asallowed by MPEG-2 standard).
• The arrangement described herein can beadvantageously applied to WLAN access points that areoptimized to support video streaming services (in thehome or in other environments).
• In Figure 4, a simplified block diagram of thehardware 600 andsoftware 700 structures of a relatedaccess point is given.
• The main hardware blocks of the access point areanEthernet card 610, one or more Wireless LAN card(s)620, aCPU 630, aFlash memory 640 and adynamic memory650. TheWLAN 620 andEthernet 610 cards may beconnected through a PCI bridge (not shown in thepicture for simplicity). Their typical behaviour istransmitting and receiving Ethernet frames from/to the memory using DMA (Direct Memory Access) access and CPUinterrupts.
• In the CPU 630 (which usually boots an operatingsystem from flash memory upon startup) device driverstake care of handling Ethernet frames both intransmission and reception by preparing/checking theirheaders and copying their payload into OS 750(Operating System) specific data structures.
• Usually, bridgingsoftware 760 in the access pointtakes care of forwarding frames from one networkinterface to another.
• Furthermore, the Access Point AP usually includesan SNMP (Simple Network Management Protocol)agent 710that enables remote control of the device,authentication software 720 to give access only toallowed clients, an IP stack 730 (to enable remotemonitoring through SNMP) and aWeb browser 740 forconfiguration purposes.
• The present invention is applicable not only totraditional WLAN access points, but also to suchdevices as Set-Top Boxes, TV sets, Personal Computersor other equipment that are adapted to act as a WLANaccess point.
• This invention provides adaptive video streamingin a Wireless LAN so that a video stream bit-rate canbe varied, video format resized or frames skippeddepending on the channel conditions measured.
• Consequently, without prejudice to the underlyingprinciples of the invention, the details and theembodiments may vary, also appreciably, with referenceto what has been described by way of example only,without departing from the scope of the invention asdefined by the claims that follow.

Claims (30)

1. A method of controlling operation of a network(200, 300) wherein at least one information stream isdelivered to at least one user (250, 260; 350, 360) viaat least one link exposed to variable operatingconditions, the method including the steps of:

   monitoring the operating conditions (400, 410)of said at least one link, and

   selectively transcoding (210, 310) said at leastone information stream by selectively varying at leastone transcoding parameter as a function of saidoperating conditions monitored.
2. The method of claim 1,characterized in thatsaid at least one link is a wireless link.
3. The method of either of claims 1 or 2,characterized in that said at least one link isincluded in a local area network (LAN-200, 300).
4. The method of claim 3,characterized in thatsaid at least one link is included in a wireless LAN(WLAN-200, 300) .
5. The method of claim 1,characterized in thatsaid information stream is a media stream.
6. The method of claim 5,characterized in thatsaid stream is selected out of an audio stream, a videostream and an audio/video stream.
7. The method of claim 6,characterized in thatsaid stream is an MPEG or H.264 encoded stream.
8. The method of claim 1,characterized in thatsaid at least one parameter is selected out of thegroup consisting of: the bit-rate of said stream, thespatial resolution of said stream, the temporalresolution of said stream.
9. The method of any of the previous claims,characterized in that it includes the steps of:

   estimating (410) the bandwidth available fortransmitting said at least one stream over said atleast one link, and at least one of:

   varying the bit-rate of said information stream,and

   splitting the content of said streamtransmission packets according to said estimatedavailable bandwidth.
10. The method of claim 1,characterized in thatsaid at least one stream is a video stream and saidtranscoding (210; 310) involves GOP-by-GOP processingof said at least one information stream.
11. The method of claim 1,characterized in thatsaid step of monitoring the operating conditions ofsaid at least one link involves detecting at least oneof said link being congested and said link being noisy,andin that said step of transcoding includestransmitting said information stream in the form ofpackets by making the lengths of said packets shorteras said at least one link becomes more congested and/ornoisy.
12. The method of any of the previous claims,characterized in that said transcoding involves thesteps of generating corresponding transmitter (500a)and receiver (500b) protocol stacks for IP packettransmission, said stacks being arranged in a cross-layer-controlledarrangement including:

    a transcoder layer (510a, 510b),

    a network adaptation/real-time transportprotocol layer (520a, 520b),

    a UDP/IP layer (530a, 530b),

    a MAC layer (540a, 540b), and

    a physical layer (550a, 550b).
13. The method of claim 1,characterized in thatsaid step of monitoring the operating conditions of said at least one link includes monitoring at least oneof the entities selected from the group consisting of:

    data loss rate over said link,

    current throughput over said link, and

    maximum physical data rate over said link.
14. The method of claim 1,characterized in thatsaid at least one link involves a base station (BSS),and said step of monitoring the operating conditions ofsaid at least one link involves monitoring at least oneentity selected out of the group consisting of:

    channel utilization over said link,

    available admission capacity over said at leastone link, and

    total number of STAs associated with said basestation (BSS).
15. A system for controlling operation of anetwork (200, 300) wherein at least one informationstream is delivered to at least one user (250, 260;350, 360) via at least one link exposed to variableoperating conditions, the system including:

    a controller module (410) configured formonitoring the operating conditions (400, 410) of saidat least one link, and

    at least one transcoder (210, 310) configuredfor selectively transcoding (210, 310) said at leastone information stream by selectively varying at leastone transcoding parameter as a function of saidoperating conditions monitored.
16. The system of claim 15,characterized in thatsaid at least one link is a wireless link.
17. The system of either of claims 15 or 16,characterized in that said at least one link isincluded in a local area network (LAN-200, 300).
18. The system of claim 17,characterized in thatsaid at least one link is included in a wireless LAN(WLAN-200, 300).
19. The system of claim 15,characterized in thatsaid information stream is a media stream.
20. The system of claim 19,characterized in thatsaid stream is selected out of an audio stream, a videostream and an audio/video stream.
21. The system of claim 20,characterized in thatsaid stream is an MPEG or H.264 encoded stream.
22. The system of claim 15,characterized in thatsaid at least one transcoder (210, 310) is configuredfor selecting said at least one parameter out of thegroup consisting of: the bit-rate of said stream, thespatial resolution of said stream, the temporalresolution of said stream.
23. The system of any of the previous claims 15 to22,characterized in that the system is configured for:

    estimating (410) the bandwidth available fortransmitting said at least one stream over said atleast one link, and at least one of:

    varying the bit-rate of said information stream,and

    splitting the content of said streamtransmission packets according to said estimatedavailable bandwidth.
24. The system of claim 14,characterized in thatsaid at least one stream is a video stream and said atleast one transcoder (210; 310) is configured for GOP-by-GOPprocessing of said at least one informationstream.
25. The system of claim 15,characterized in thatsaid controller module (410) is configured formonitoring the operating conditions of said link bydetecting at least one of said link being congested and said link being noisy, andin that said at least onetranscoder (210, 310) is configured for transmittingsaid information stream in the form of packets bymaking the lengths of said packets shorter as said atleast one link becomes more congested and/or noisy.
26. The system of any of the previous claims 15 to25,characterized in that said at least one transcoder(210, 310) is configured for generating correspondingtransmitter (500a) and receiver (500b) protocol stacksfor IP packet transmission, said stacks being arrangedin a cross-layer-controlled arrangement including:

    a transcoder layer (510a, 510b),

    a network adaptation/real-time transportprotocol layer (520a, 520b),

    a UDP/IP layer (530a, 530b),

    a MAC layer (540a, 540b), and

    a physical layer (550a, 550b).
27. The system of claim 15,characterized in thatsaid controller module (410) is configured formonitoring at least one of the entities selected fromthe group consisting of:

    data loss rate over said link,

    current throughput over said link, and

    maximum physical data rate over said link.
28. The system of claim 15,characterized in thatsaid at least one link involves a base station (BSS) ,and said controller module (410) is configured formonitoring at least one entity selected out of thegroup consisting of:

    channel utilization over said link,

    available admission capacity over said at leastone link, and

    total number of STAs associated with said basestation (BSS).
29. A communication network including a systemaccording to any of claims 15 to 28.
30. A computer program product loadable in thememory of at least one computer and including softwarecode portions for performing the method of any ofclaims 1 to 14.

Images