WO2002005492A1

WO2002005492A1 - Multimedia streams and quality of service in wireless home networks

Info

Publication number: WO2002005492A1
Application number: PCT/US2001/001659
Authority: WO
Inventors: Rajugopal R. Gubbi
Original assignee: Sharewave, Inc.
Priority date: 2000-07-12
Filing date: 2001-01-17
Publication date: 2002-01-17
Also published as: AU2001232850A1; EP1302025A1

Abstract

Data (e.g., multimedia data) is transmitted between components of a computer network according to a method wherein said data is transported from a first network component to at least a second network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream. The first negotiations may include the bandwidth requirement for said data stream and/or permissions to transmit from one network component to a second network component. In some cases, these permissions may be granted by a third network component designated as a master network component. This method may be employed in wireless (e.g., infra red or radio frequency) computer networks. The data streams may be organized in a hierarchical structure, including transmission priorities such as isochronous, high, medium and low, depending on the data content of said streams. The data content may include multimedia, voice, and asynchronous data.

Description

Multimedia Streams and Quality of Service in Wireless Home

Networks

RELATED APPLICATION

The present application is related to and hereby claims the priority benefit of US Provisional Application No. 60/149,524, entitled "Multimedia Streams and Quality of Service in Wireless Home Networks" filed August 17, 1999, by Rajugopal R. Gubbi.

FIELD OF THE INVENTION

The present invention relates generally to a scheme for communications within a computer network and, in particular, to a scheme for accommodating multimedia within a wireless computer network such as a wireless local area network (LAN).

BACKGROUND

Modem computer networks allow for inter-communication between a number of nodes such as personal computers, workstations, peripheral units and the like. Network links transport information between these nodes, which may sometimes be separated by large distances. However, to date most computer networks have relied on wired links to transport this information. Where wireless links are used, they have typically been components of a very large network, such as a wide area network, which may employ satellite communication links to interconnect network nodes separated by very large distances. In such cases, the transmission protocols used across the wireless links have generally been established by the service entities carrying the data being transmitted, for example, telephone companies and other service providers.

In the home environment, computers have traditionally been used as stand-alone devices. More recently, however, there have been some steps taken to integrate the home computer with other appliances. For example, in so-called "Smart Homes", computers may be used to turn on and off various appliances and to control their operational settings. In such systems, wired communication links are used to interconnect the computer to the appliances that it will control. Such wired links are expensive to install, especially where they are added after the original construction of the home.

In an effort to reduce the difficulties and costs associated with wired communication links, some systems for interconnecting computers with appliances have utilized analog wireless links for transporting information between these units. Such analog wireless links operate at frequencies commonly utilized by wireless telephones.

Although easier to install than conventional wired communication links, analog wireless communication links suffer from a number of disadvantages. For example, degraded signals may be expected on such links because of multipath interference. Further, interference from existing appliances, such as televisions, cellular telephones, wireless telephones and the like, may be experienced. Thus, analog wireless communication links offer less than optimum performance for a home environment.

In a co-pending application, Serial No. 09/151,579, which is assigned to the assignee of the present application and is incorporated herein by reference, a computer network employing a digital wireless communication link adapted for use in the home and other environments was described. The architecture of that network (referred to in the previously cited provisional application as a "Whitecap" network) included a number of network components arranged in a hierarchical fashion and communicatively coupled to one another through communication links operative at different levels of the hierarchy. At the highest level of the hierarchy, a communication protocol that supports dynamic addition of new network components at any level of the hierarchy according to bandwidth requirements within a communication channel operative at the highest level of the network hierarchy is used.

The generalization of this network structure is shown in Figure 1. A subnet 10 includes a server 12. In this scheme, the term "subnet" is used to describe a cluster of network components that includes a server and several clients associated therewith (e.g., coupled through the wireless communication link). Depending on the context of the discussion however, a subnet may also refer to a network that includes a client and one or more subclients associated therewith. A "client" is a network node linked to the server through the wireless communication link. Examples of clients include audio/video equipment such as televisions, stereo components, personal computers, satellite television receivers, cable television distribution nodes, and other household appliances.

Server 12 may be a separate computer that controls the communication link, however, in other cases server 12 may be embodied as an add-on card or other component attached to a host computer (e.g., a personal computer) 13. Server 12 has an associated radio 14, which is used to couple server 12 wirelessly to the other nodes of subnet 10. The wireless link generally supports both high and low bandwidth data channels and a command channel. Here a channel is defined as the combination of a transmission frequency (more properly a transmission frequency band) and a pseudorandom (PN) code used in a spread spectrum communication scheme. In general, a number of available frequencies and PN codes may provide a number of available channels within subnet 10. As is described in the co-pending application cited above, servers and clients are capable of searching through the available channels to find a desirable channel over which to communicate with one another.

Also included in subnet 10 are a number of clients 16, some of which have shadow clients 18 associated therewith. A shadow client 18 is defined as a client which receives the same data input as its associated client 16 (either from server 12 or another client 16), but which exchanges commands with server 12 independently of its associated client 16. Each client 16 has an associated radio 14, which is used to communicate with server 12, and some clients 16 may have associated subclients 20. Subclients 20 may include keyboards, joysticks, remote control devices, multidimensional input devices, cursor control devices, display units and/or other input and/or output devices associated with a particular client 16. A client 16 and its associated subclients 20 may communicate with one another via communication links 21, which may be wireless (e.g., infra-red, ultrasonic, spread spectrum, etc.) communication links.

Each subnet 10 is arranged in a hierarchical fashion with various levels of the hierarchy corresponding to levels at which intra-network component communication occurs. At a highest level of the hierarchy exists the server 12 (and/or its associated host 13), which communicates with various clients 16 via the wireless radio channel. At other, lower levels of the hierarchy the clients 16 communicate with their various subclients 20 using communication links 21, for example, wired communication links or wireless communication links such as infrared links.

Where half-duplex radio communication is used on the wireless link between server 12 and clients 16, a communication protocol based on a slotted link structure with dynamic slot assignment is employed. Such a structure supports point-to-point connections within subnet 10 and slot sizes may be re-negotiated within a session. Thus a data link layer that supports the wireless communication can accommodate data packet handling, time management for packet transmission and slot synchronization, error correction coding (ECC), channel parameter measurement and channel switching. A higher level transport layer provides all necessary connection related services, policing for bandwidth utilization, low bandwidth data handling, data broadcast and, optionally, data encryption. The transport layer also allocates bandwidth to each client 16, continuously polices any under or over utilization of that bandwidth, and also accommodates any bandwidth renegotiations, as may be required whenever a new client

16 comes on-line or when one of the clients 16 (or an associated subclient 20) requires greater bandwidth.

The slotted link structure of the wireless communication protocol for the transmission of real time, multimedia data (e.g., as frames) within a subnet 10 is shown in Figure 2. At the highest level within a channel, forward (F) and backward or reverse (B) slots of fixed (but negotiable) time duration are provided within each frame transmission period. During forward time slots F, server 12 may transmit video and/or audio data and/or commands to clients 16, which are placed in a listening mode. During reverse time slots B, server 12 listens to transmissions from the clients 16. Such transmissions may include audio, video or other data and/or commands from a client 16 or an associated subclient 20. At the second level of the hierarchy, each transmission slot (forward or reverse) is made up of one or more radio data frames 40 of variable length. Finally, at the lowest level of the hierarchy, each radio data frame 40 is comprised of server/client data packets 42, which may be of variable length.

Each radio data frame 40 is made up of one server/client data packet 42 and its associated error correction coding (ECC) bits. Variable length framing is preferred over constant length framing in order to allow smaller frame lengths during severe channel conditions and vice-versa. This adds to channel robustness and bandwidth savings. Although variable length frames may be used, however, the ECC block lengths are preferably fixed. Hence, whenever the data packet length is less than the ECC block length, the ECC block may be truncated (e.g., using conventional virtual zero techniques). Similar procedures may be adopted for the last block of ECC bits when the data packet is larger.

As shown in the illustration, each radio data frame 40 includes a preamble 44, which is used to synchronize pseudo-random (PN) generators of the transmitter and the receiver. Link ID 46 is a field of fixed length (e.g., 16 bits long for one embodiment), and is unique to the link, thus identifying a particular subnet 10. Data from the server 12/client 16 is of variable length as indicated by a length field 48. Cyclic redundancy check (CRC) bits 50 may be used for error detection/correction in the conventional fashion.

For the illustrated embodiment then, each frame 52 is divided into a forward slot F, a backward slot B, a quiet slot Q and a number of radio turn around slots T. Slot F is meant for server 12-to-clients 16 communication. Slot B is time shared among a number of mini-slots B]_, B2, etc., which are assigned by server 12 to the individual clients 16 for their respective transmissions to the server 12. Each mini-slot Bi, B2, etc. includes a time for transmitting audio, video, voice, lossy data (i.e., data that may be encoded/decoded using lossy techniques or that can tolerate the loss of some packets during transmission/ reception), lossless data (i.e., data that is encoded/decoded using lossless techniques or that cannot tolerate the loss of any packets during transmission/reception), low bandwidth data and/or command (Cmd.) packets. Slot Q is left quiet so that a new client may insert a request packet when the new client seeks to login to the subnet 10. Slots T appear between any change from transmit to receive and vice-versa, and are meant to accommodate individual radios' turn around time (i.e., the time when a half-duplex radio 14 switches from transmit to receive operation or vice- versa). The time duration of each of these slots and mini-slots may be dynamically altered through renegotiations between the server 12 and the clients 16 so as to achieve the best possible bandwidth utilization for the channel. Note that where full duplex radios are employed, each directional slot (i.e., F and B) may be full-time in one direction, with no radio turn around slots required.

Forward and backward bandwidth allocation depends on the data handled by the clients 16. If a client 16 is a video consumer, for example a television, then a large forward bandwidth is allocated for that client. Similarly if a client 16 is a video generator, for example a video camcorder, then a large reverse bandwidth is allocated to that particular client. The server 12 maintains a dynamic table (e.g., in memory at server 12 or host 13), which includes forward and backward bandwidth requirements of all online clients 16. This information may be used when determining whether a new connection may be granted to a new client. For example, if a new client 16 requires more than the available bandwidth in either direction, server 12 may reject the connection request. The bandwidth requirement (or allocation) information may also be used in deciding how many radio packets a particular client 16 needs to wait before starting to transmit its packets to the server 12. Additionally, whenever the channel conditions change, it is possible to increase/reduce the number of ECC bits to cope with the new channel conditions. Hence, depending on whether the information rate at the source is altered, it may require a dynamic change to the forward and backward bandwidth allocation.

SUMMARY OF THE INVENTION In one embodiment, data (e.g., multimedia data) is transmitted between components of a computer network according to a method wherein said data is transported from a first network component to at least a second network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream. Such multimedia data may include high quality voice, audio, video, and real time data. The first negotiations may include the bandwidth requirement for said data stream and/or permissions to transmit from one network component to a second network component.

In some cases, these permissions may be granted by a third network component designated as a master network component. This method may be employed in wireless

(e.g., infra red or radio frequency) computer networks.

The data streams may be organized in a hierarchical structure, including transmission priorities such as isochronous, high, medium and low, depending on the data content of said streams. The data content may include multimedia, voice, and asynchronous data. In some cases, a stream identifier for the data stream includes one or more of the following fields: a subnet identification, a session identification, a destination component identification, a packet type, and a stream index.

The present method may also include synchronizing any two or more temporally related streams using the stream identifier. In such cases, a receiving network component provides synchronization feedback to a sending network component for timing adjustments at the sending network component. Data packets within a stream are synchronized using said stream identifier. Such synchronizing includes buffering premature packets.

The method may further include a second or more sets of stream set up negotiations to dynamically adjust stream transmission parameters. The second set of negotiations may include bandwidth reallocation.

The computer network within which the present methods are used generally includes at least one network component designated as a point coordinator and a second network component designated as a client of the said point coordinator, the point coordinator controlling access to the transmission medium for at least a period of time. Within the network, each network frame corresponds to a transmission time slot within a transmission channel for communicating between two or more network components.

A further embodiment provides a method of communicating in a computer network including at least a first network component and a second network component. The method includes transmitting multimedia data streams, including high quality voice, video, and real time data; requesting permission by the first network component to at least the second network component before commencing transmission of said multimedia data streams, communicating multimedia data stream transmission parameters between at least said two network components, establishing a connection for transmitting said multimedia data streams according to the negotiated transmission parameters, modifying said transmission parameters when changes in the transmission requirements occur, transmitting said multimedia data streams in packets of data within network frames, re-transmitting said transmitted packets of data upon a previous transmission failure and a request by at least a second network component, and restoring the temporal relationships between said packets of data after a packet is re-transmitted, such that a reliable and efficient multimedia data stream transmission method is defined.

In an alternative embodiment, a computer network wherein multimedia data streams are transmitted between network components makes use of a protocol defining a set of quality of service parameters that provide a guaranteed bandwidth, a maximum latency and a dynamic rate control mechanism for transporting said multimedia data streams. The quality of service parameters may include one or more of the following: a maximum number of data retransmission attempts including zero; a bandwidth requirement including a transmission duration and a minimum number of transmissions per unit of time; a maximum permissible latency; and a set of parameters that define the channel protection.

A further embodiment provides an interface that includes means for transporting data from a first computer network component to at least a second computer network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream. The interface (e.g., a network interface card) may include a wireless transceiver to communicate in a wireless computer network.

Another embodiment may provide a system (e.g., a server or other computer system) that includes an interface capable of transporting data from a first computer network component to at least a second computer network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream.

These and other features and advantages of the present invention will be apparent from a review of the detailed description and its accompanying drawings that follow. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:

Figure 1 illustrates a generalized network structure that is supported by a wireless communication protocol configured in accordance with an embodiment of the present invention;

Figure 2 illustrates a hierarchical arrangement for the transmission of data and control information within a subnet according to one embodiment of the present invention;

Figure 3 illustrates various Network Services Classification in accordance with an embodiment of the present invention;

Figure 4 illustrates an example of transmissions of each device in a network frame in accordance with an embodiment of the present invention;

Figure 5 illustrates a data stream hierarchy in computer networks in accordance with an embodiment of the present invention;

Figure 6 illustrates an example of Guaranteed Bandwidth in accordance with an embodiment of the present invention; and

Figure 7 illustrates Priority Services in computer networks in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

The challenge of networking at home is to connect devices anywhere in and around the home in a way that is simple, reliable, secure, and inexpensive. Wireless LANs are an attractive solution for this, as they do not demand any changes to the existing electrical wiring. To date, the high cost and impracticality of adding new wires has inhibited the wide spread adoption of home networking technologies. As robust and sleek radios are becoming affordable, wireless LANs are penetrating into home market. Nevertheless, multiple, incompatible communication standards have limited the acceptance of wireless networks in homes. Additionally, these existing standards are mainly oriented towards transporting asynchronous data. These standards do not address the problem of transporting Isochronous data like audio and video which is, in fact, the more widely used data type in a home environment. Hence, there is a need for an efficient wireless network architecture that supports exchange of Isochronous as well as asynchronous data between different consumer electronic devices, which may or may not be from the same vendor. The three spectrum bands currently considered for wireless LANs that employ spread spectrum are in the vicinities of 900Mhz, 2.4GHz and 5.8GHz. The IEEE 802.11 standard specifies the Media Access Control (MAC) and Physical (PHY) protocols using the 2.4GHz band for 1, 2, 5, and 11 Mbps rates. BlueTooth SIG and HomeRF groups have developed their own wireless LAN technologies for l-2Mbps. Other examples of WLAN technologies are WaveLAN from Lucent, Inc., RangeLAN from

Proxim, Inc. and Next by IBM. In addition ShareWave, Inc. has developed WhiteCap

LAN architecture to provide all the services needed at home including reliable

Isochronous data transfer with guaranteed latency.

Some examples of what home users wish to do with wireless devices include Share multimedia data between devices, access the Internet from anywhere in and around the home using portable devices,

Intelligently forward incoming telephone calls to multiple cordless handsets, FAX machines and voice mailboxes, and Auto-upgrade all wireless devices in the home.

Home networks demand Isochronous data transfers like high quality audio and video, network reliability and efficiency, channel sharing by devices and auto-upgrades of devices. To meet these demands of a home network, there is a need for reliable and guaranteed Quality of service (Qos). The 802.11 and HomeRF designs have so far concentrated on transferring asynchronous data with no support for Qos and hence multimedia data transfers over the home network. On the other hand, the scheme described in the above-cited co-pending application (hereinafter termed the "WhiteCap" architecture) lays enormous emphasis on transporting multimedia data over the home network while not undermining the need for transporting asynchronous data. This invention describes the Qos measures provided by the WhiteCap architecture.

The WhiteCap architecture is subnet based as discussed above. The WhiteCap architecture supports streams to provide the best Qos possible. The concept of slots and streams are introduced and the proposed Quality of services includes guaranteed bandwidth and/or latency for multimedia streams and dynamic rate control are then described. These Qos parameters are presented in the following sections and a summary of the discussion is presented thereafter.

Overview of WhiteCap Network Architecture

As indicated above, the WhiteCap architecture generally includes one master device and many client and sub-client devices arranged in three hierarchical levels. The physical media between the master and clients is a wireless RF channel. This architecture employs Direct Sequence Spread Spectrum (DS-SS) in the unlicensed band at 2.4Ghz. This provides 2 channels at 4Mbρs using Differential QPSK (DQPSK) and 3 channels at l l/22Mbps using improved modulation schemes. The media between sub- clients and clients can be a wireless (IR) or a wired channel.

The WhiteCap architecture is master-client based wherein one designated device acts as the master device and the client devices avail the services provided by the master device. Various services 30 offered by the WhiteCap architecture are shown in Figure 3. Each cluster of devices having one master device and many client devices is termed as a subnet. For the purposes of identification, each device should have unique device ID and each subnet should have unique subnet ID. To avoid causing high interference the distribution of subnets should be non-overlapping. However, in practice it is difficult to prevent subnets from overlapping. The problems caused by overlapping are minimized if each home is assumed to have one subnet thus using only one channel. Additionally one subnet per home ensures access to and synchronization of all devices at all times. Nevertheless, if there is a need many subnets located in neighboring homes can share the same channel through appropriate negotiations between the master devices. Subnets sharing a channel in this way form a subnet group.

Types of Devices

Several types of devices are supported in this network architecture. The devices can be classified as very thin clients, thin clients, fat clients and personal computers (PC) based on their capabilities. The same devices can also be classified as master devices, alternate master devices, application/data server, dependent devices and independent devices based on their network responsibilities. A master device is a device that is responsible for all the network operation. An alternate master device is a client with the capabilities of a master device and is responsible to perform as a master device in the absence of such a device. An application server is a device that can host a thin or a very thin client. An independent device is a device that can operate without a host but is not capable of hosting another device. A dependent device is a device that can operate only when hosted by an application server.

Hierarchical Structure of Transmitted Data

Transmitted data has layered structures in the hierarchy as shown in Figure 2. Each network frame 52 has separate transmission slots 56 meant for each of the devices in the network shown in more detail in Figure 4. Each slot may contain data streams 60 like command, voice audio, video and data meant for different devices in a sequential order. Each data stream may consist of one or more packets 62 in each transmission slot.

All client devices dynamically negotiate their transmission slot duration with the master device in order to optimize the network utilization. These negotiations typically take place when a new client comes online or a new application is launched on a device thus starting a new stream or changing the bandwidth and latency requirements of a stream.

Each network frame 52 has a special time slot called reQuest slot 54 (Slot Q).

The Slot Q 54 is left unused by the currently online devices so that a new device can request connection using this slot. The length of Slot Q is kept at its minimum and is at least the length of one command packet.

Network Synchronization

Time synchronization between the master device and the clients is important in any Isochronous network. In the WhiteCap architecture this is made easy through the exchange of connection agreements and other commands among the master device and client devices. The parameters used to achieve network synchronization are the network frame size, the wait time for each device, Tx slot (duration) for each device and the session ID of the preceding client.

As seen in Figure 6, the network frame 52 is the duration between two transmissions from the master device. This parameter is decided based on the number of online clients and their bandwidth and latency requirements. Wait time 58 is the duration for which a device has to wait after receiving the first packet from the master device, before it can start transmitting. Tx slot 56 is the allocated transmission duration (bandwidth) for each client.

As part of connection agreements the master device provides each client with these parameters. The clients honor this agreement by waiting in receive mode and starting transmission at the right time. During waiting if a device detect an end of transmission indication from the preceding device, then it immediately starts its transmission. The extra bandwidth if any detected by the current client device can be made use of to send its queued up data. For example, if a client is supposed to wait for 20msec and it detects the last packet of preceding client within 15msec, then it can make use of the extra 5msec. Due to high packet losses in wireless channels accurate wait times are necessary in starting the transmission from a device. Stream support in WhiteCap Networks

Each device can originate a set of data streams and can consume another set of data streams. For every data stream generation/consumption, it has to take permission from the master device and negotiate the network bandwidth for the same. The client devices can dynamically connect and disconnect any stream and can re-negotiate the bandwidth for an existing stream.

The hierarchy corresponding to the data streams is as shown in Figure 5. Any two data streams on the network can be distinctly identified based on Subnet ID, Source client ID 70, Destination Client ID 72, Packet type 74 and stream index 76 that are sent with each packet in its header. This means that two types of streams originating from the same device can have the same stream index 76. Each of these streams can be negotiated with different Qos requirements and destination. The master device maintains the Qos and user list for each data stream and distributes the same to all the users of that data stream.

Broadcast within a subnet is achieved using stream index of all ONEs. For example, for a video broadcast the packet type is Video and stream index is all ONEs.

Stream Connection, Distribution and Disconnection

In the WhiteCap network streams are connected and disconnected as the need arises. The only exception to this is the basic command channel that is granted to each device during the connection establishment process. Each device can request and connect a stream or disconnect an existing stream at any time during the session. Whenever there is a new stream that needs to be started, either the source device or the destination device can initiate such a request. The source device provides the stream index, packet type and the destination device gets permission to consume that stream from the master device. In the case of shadow clients, the shadow clients get such permission only after both the source and the destination devices approve of such usage of the data. The source device is required to collect retransmission requests from all the destination devices for that stream and decide the packets that need to be retransmitted.

Whenever a stream needs to be disconnected, either the source device or the destination device can initiate such a request. In the shadow client mode, any one of the destination devices can opt to stop using the stream without in any way affecting the other devices. The master device disconnects a stream and reuses the bandwidth either when the user list for that stream is empty or the source device opts for disconnection of that stream.

Handling Non-stream based data

In any network there are always some data packets that need not be related to any of the streams. An example of such data is an ARP packet in an IP/IPX based network. A stream index with all zeroes is reserved for such data packets in Whitecap networks. Any device can use this stream index to non-stream based data. Such data is given the lowest priority but is allowed a high number of retransmission attempts.

Stream priorities

Whitecap provides two types of priorities for streams, namely, Isochronous priority for Isochronous streams and best effort priority for asynchronous streams. Best effort priority is further classified as high, medium and low. The priority of an entire stream is decided once for each stream during connection establishment. As priorities apply to streams, each packet does not carry the priority bits in its header, thus saving network bandwidth. Stream Synchronization

Stream synchronization is defined as the process of restoring temporal relationships between various streams or elements, which compose the multimedia information. It is an optional service that devices can negotiate for. In Whitecap networks stream synchronization is achieved using a dedicated field in its packet header called the stream frame number. Stream synchronization is not provided to streams with stream index of all zeroes (a non-stream data).

The source device uses the stream frame number field to time stamp the video and the audio stream packets. The receiving device compares the stream frame numbers on the two streams it needs to synchronize. There is enough buffering provided based on the synchronization window that is requested for these streams. If a packet is lost within this window, a retransmission is requested and the data is delivered only after resynchronization at the receiving device. On the other hand, if the synchronization time window has elapsed and the packets are not yet correctly received, the retransmission request is aborted and the data is delivered with information on the missing packets. Additionally, the data-consuming agent can provide the Whitecap service layers with indications such as UNDERFLOW, NORMAL and OVERFLOW for each of the streams. This information is transported over to the device that is generating the stream and is delivered to the data-generating agent so that the data rate of that stream is appropriately altered.

Quality of Service for Home Networks

Whitecap provides all the sophisticated network services necessary for transfeιτing multimedia data. Applications, such as, VOIP and live video streaming deal with Isochronous data that needs a low latency network protocol with end-to-end Qos. The various Qos related services provided in the WhiteCap architecture are discussed in the following sections. These services and their associated parameters such as the number of data retransmission attempts, bandwidth, maximum permissible latency and channel protection are dynamically negotiable for each stream.

Packet Sequence Preservation

The WhiteCap protocol guarantees the order of packets at the receiving end by preserving the packet sequence. If a packet is lost in the channel and a retransmission is requested for that stream, the packets are held in the network receive buffer until the missing packet is retransmitted by the transmitter and is correctly received by the receiver. Once a retransmitted packet is received all the packets up to the next missing packet in the same stream are delivered to the data-handling device. On the other hand, if repeated retransmissions fail or a retransmission is not requested for that stream, the packets are delivered in an increasing order of the packet sequence with information to the device handler about the missing packets.

Data Fragmentation

The WhiteCap service layer can fragment data blocks of any size. A data source can provide a large block of data meant for any stream and the WhiteCap protocol stack takes the responsibility of fragmentation at the transmitting end and re-alignment at the receiving end before delivering the data block to the data sink.

Voice, Audio, Video and Data Compression

The audio, voice and video streams are optionally compressed and transported over the WhiteCap networks. The WhiteCap protocols support negotiations for the type and rate of compression. Currently the WhiteCap supports voice and audio compression based on ADPCM with compression ratio of 4:1. The voice compression can accept either A-law/U-law coded or raw PCM samples as input. The video compression is based on wavelet transforms and negotiable compression rates. The compression ratio negotiations provide options to the receiver when the allocated bandwidth is less than the requested bandwidth for that stream. The data compression supported is based on LZ compression. Streams compressed using other compression schemes are also transported in the WhiteCap networks with similar Qos as the streams compressed using native compression schemes.

Channel Protection

As Isochronous streams, by nature, are not retransmitted, they are highly vulnerable to the channel losses. Channel losses could result in unacceptable quality of streams, like audio and video. To avoid such situations, WhiteCap protocols support both Error Correction Coding (ECC) and Cyclic Redundancy Check (CRC) mechanisms. Each receiving device can request either ECC or CRC or both for a stream. With ECC, the Isochronous streams become much more usable even under severe wireless channel conditions. The supported ECC scheme is based on Reed Solomon coding with variable protection capability.

Interleaving is not inherently supported in WhiteCap networks due to the high latencies involved. Any data interleaving is left to specific applications above the WhiteCap services layer.

Cyclic Redundancy Check Scheme

The CRC is computed using the following standard generator polynomial of degree 32:

C G( rx \) - x •'- + , x 26 + , x 23 + , x 22 + , x 16 + , x 12 + , x 11 + , x 10 + , x 8 + , x 7 + , x 1 + , x 4 + , x 2 + , x+ , 1 , The CRC is the One's compliment of the sum (module 2) of the following:

(a) The remainder of x^k(x³¹+ x³⁰+ x²⁹+ ....+ x²+ x+1) divided (modulo 2) by G(x), where k is the number of bits in the calculation fields, and

(b) The remainder after multiplication of the contents (treated as a polynomial) of the calculation fields by ²and then division by G(x).

Error Correction Scheme

WhiteCap networks use (255, k) Reed-Solomon coder over GF(2^). Currently 'k' is the number of information symbols, 'k' varies depending on the RF channel condition and negotiated Qos for a particular class of data. Each data packet (including the header) is split into blocks of k symbols (each symbol is a byte) and ECC is carried out to form 255 byte blocks. If number of bytes in a data packet is not an integer multiple of k, then the last block is sent with truncated ECC using virtual zeroes technique. In this technique, the ECC bytes are computed as if the data is padded with zero bytes to complete a block, but the pad bytes are not transmitted. Instead at the receiver, the pad bytes are added and then the data is decoded.

Data retransmission

WhiteCap allows negotiation of the number of retransmissions for each stream at the time of connecting a stream. The mechanism used for retransmission is a variation of the selective Auto Repeat reQuest(ARQ) technique. For lossless data delivery a high number of retransmissions up to a maximum of 255 can be negotiated. For Isochronous streams, zero or a limited number of retransmissions can be negotiated.

Guaranteed Bandwidth for Isochronous Application Support

Data streams that are extremely time-sensitive can be allotted guaranteed levels of service. Guaranteed levels of service are negotiated between devices through the connection agreement protocol. Embedded in the Whitecap protocol is the synchronization, time stamping, and sequencing, necessary for Isochronous communication. The protocol specifies the bandwidth for each slot and the rate of slots necessary to guarantee the bandwidth requirements. For instance, a particular video stream may require 2500 bytes of every 4^th slot.

Guaranteed Maximum Latency

Maintaining low latencies is a challenge when transporting multimedia data types. For example, a 50msec delay in voice delivery can cause an audible click. The WhiteCap protocols owing to their efficiency guarantee the requested limit on the maximum latency. First, the retransmission attempts for a packet in any stream are strictly bound by the latency requirements. Second, the channel protection and its variation based on the channel conditions makes possible the low latency achieved for Isochronous streams. Third, the WhiteCap protocols allow a stream to be transmitted more than once within a network frame. A device can request low latency for a stream in a long network frame and it is permitted to transmit its packets in a frequent manner in the time slots that are closely arranged within a network frame. Fourth, depending on the latency requirements the network frame is adjusted to allow frequent (or slower) transmissions of an Isochronous stream. Nevertheless, the network frame size adjustments are carried out talcing into account the requirements of all the Isochronous streams in the subnet.

Priority services

This priority of a stream is an indication of latency and quality of delivery at the receiving end. As mentioned earlier, WhiteCap guarantees the required bandwidth for Isochronous streams. The remaining bandwidth is allocated to best effort priority service. After the priority service level differentiates the packets, they are buffered and queued according to priority level to insure proper sequence of the packets. The non- Isochronous packets are then transmitted in a weighted fair queuing arbitration mechanism. Data that is not transmitted in a specified network frame is delayed using a random early detection mechanism starting from the lowest priority traffic first.

Dynamic Rate Control

Dynamic rate control (DRC) is required to combat the severely varying wireless channel. In essence this means to dynamically increase the channel protection of data streams when the channel is severe for the cost of reduction in information rate. On the other hand, when channel is favorable, the channel protection is dynamically reduced and information rate is increased in turn increasing the audio/video quality at the receiving end.

In WhiteCap networks the dynamic rate control is achieved through dynamic bandwidth negotiation, priority adjustments, joint optimization of source coding and channel coding, and the channel change from a noisy channel to an available better channel. To help in DRC, the channel performance is measured from time to time at all devices and these measurements are passed on to the master device for analysis and decision.

Channel Measurement

Each device keeps track of the all the packets received and computes the packet loss using a special field in the packet header called the stream sequence number. Each device forwards the count of number of packets lost to the master node approximately once every second. Master node uses this information to assess the channel scenario.

The channel measurement is used for channel changing and to provide varying error protection in DRC mode. A channel change is carried out whenever the noise/interference in the current frequency band becomes unbearable. A varying error protection is employed to provide better bandwidth utilization and robustness according to the channel variations.

Dynamic Bandwidth Negotiation

Every device in the subnet can dynamically negotiate the required bandwidth with the master device. This is a necessity especially when a new Isochronous stream is generated from a device which is currently allocated a low bandwidth. The master device keeps track of all the bandwidth allocations. If a device requests for bandwidth that is more than what is available, then the device is allocated only the available bandwidth. It is up to the device to decide whether to use or reject the allocated bandwidth.

Each device collects the required bandwidth for each of its streams and averages them over a period of time. The bandwidth requirement is divided into four groups as per the priority of the streams (Isochronous, High, Medium and Low) as depicted in Figure 7. Comparing this requirement with the currently allocated bandwidth, the device may decide either to give up some of it or to request more bandwidth. The master device collects all such requests including its own bandwidth requirements and compares them with the available bandwidth as shown in Table 1. If there is some bandwidth available, it allocates all new requests for Isochronous bandwidth first. Then it considers the High priority streams and then medium and so on. When there are multiple streams of the same priority, it allocates the bandwidth using the following order of priority.

1. Device with (overall) lowest bandwidth

2. Device with lowest bandwidth for the current priority

3. Device that sent the request first. (First come first served policy). For this purpose the master device maintains a table containing the available bandwidth, allocated bandwidth for each stream priority at every client device, the requested bandwidth for each stream priority at every device and the time of request as shown in Table 1.

Table 1

Joint Source and Channel Code Optimization

The client devices measure the channel status in terms of packet error rates and packet loss rates that they are experiencing. Each device sends the measured channel status to its data sources periodically. Using the channel status, the data source device adjusts the source and channel coding rates jointly to help achieve a better quality delivery at the receiver. This is especially useful for audio and video, as, through the use of variable rate coders, it is possible to gracefully degrade the reception quality when the channel becomes severe. In the case of data channels, the DRC simply increases the channel protection and reduces the source data rate, as the channel becomes severe. When the channel conditions are favorable, DRC results in higher source data throughput with lower channel code rate.

Channel Change

The master node monitors the channel behavior at the system level and keeps track of the same. The client devices send the channel status in terms of packet error rates and packet loss rates that they are experiencing. Using the channel status from all the client devices and the one measured locally at the master node, the master node decides to move the network operations to a better channel, if one is available. Master carries this out by first searching for a good channel and then instructing all the client devices to move over to the new channel.

Summary

Thus, supporting service structures for multimedia streams and the Qos layer provided in the WhiteCap architecture to facilitate transporting Isochronous data, such as multimedia, over wireless home networks has been described. The WhiteCap architecture supports Isochronous and asynchronous streams, multiple stream priorities, dynamic connection and disconnection of streams, stream synchronization for restoring their temporal relationship at the receiver. The WhiteCap architecture provides a Qos layer to ensure efficient utilization of the available bandwidth and timely and reliable delivery of data under all channel conditions. The various parameters associated with the Qos layer, such as the number of data retransmission attempts, bandwidth, maximum permissible latency and channel protection are dynamically negotiable for each stream. The bandwidth allocation is dynamic and is based on the stream priority.

The Isochronous streams are given preference over streams of other priorities while allocating the bandwidth. Optionally each stream is provided with a compression scheme to improve the bandwidth utilization. Error control coding (ECC), cyclic redundancy checks (CRC), a negotiable number of data retransmission attempts and packet sequence preservation are provided to achieve reliable data delivery for all streams. Dynamic rate control is provided to enable graceful degradation of data quality with increasing channel losses. Additionally, where multiple channels are available, dynamic channel change service is provided to move the network operation to a better channel.

Claims

CLAIMSWhat is claimed is:

1. In a computer network, a method of transmitting data between network components, the method comprising transporting said data from a first network component to at least a second network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream.

2. The method of claim 1 wherein said data comprises multimedia data, asynchronous data, and voice.

3. The method of claim 2 wherein said multimedia data comprises high quality voice, audio, video, and real time data.

4. The method of claim 1 wherein said first negotiations comprise permission to transmit from one network component to a second network component.

5. The method of claim 4 wherein said permission is granted by a third network component designated as a master network component.

6. The method of claim 1 wherein said data streams are organized in a hierarchical structure.

7. The method of claim 6 wherein the hierarchical structure comprises transmission priorities including isochronous, high, medium and low depending on the data content of said streams.

8. The method of claim 7 wherein the data content includes multimedia, voice, and asynchronous data.

9. The method of claim 1 wherein said first negotiations include the bandwidth requirement for said data stream.

10. The method of claim 1 wherein said stream identifier comprises one or more of the following fields: a subnet identification, a session identification, a destination component identification, a packet type, and a stream index.

11. The method of claim 1 further comprising synchronizing any two or more temporally related streams using said stream identifier.

12. The method of claim 11 wherein a receiving network component provides synchronization feedback to a sending network component for timing adjustments at the sending network component.

13. The method of claim 1 further comprising synchronizing the data packets within a stream using said stream identifier.

14. The method of claim 13 wherein the synchronizing includes buffering premature packets.

15. The method of claim 1 further comprising a second or more sets of stream set up negotiations to dynamically adjust stream transmission parameters.

16. The method of claim 15 wherein the second set of negotiations include bandwidth reallocation.

17. The method of claim 1 wherein the transmission medium a wireless medium.

18. The method of claim 17 wherein the data is transmitted as radio frequency signals.

19. The method of claim 18 wherein the radio frequencies are transmitted using a frequency hopping spread spectrum protocol.

20. The method of claim 18 wherein the radio frequencies are transmitted using a direct sequence spread spectrum protocol.

21. The method of claim 17 wherein the data is transmitted as infra red frequency signals.

22. The method of claim 1 wherein the computer network comprises at least one network component designated as a point coordinator and a second network component is designated a client of the said point coordinator, the point coordinator controling access to the transmission medium for at least a period of time.

23. The method of claim 22 wherein each network frame corresponds to a transmission time slot within a transmission channel for communicating between two or more network components.

24. A method of communicating in a computer network including at least a first network component and a second network component, the method comprising: transmitting multimedia data streams, including high quality voice, video, and real time data; requesting permission by the first network component to at least the second network component before commencing transmission of said multimedia data streams, communicating multimedia data stream transmission parameters between at least said two network components, establishing a connection for transmitting said multimedia data streams according to the negotiated transmission parameters, modifying said transmission parameters when changes in the transmission requirements occur, transmitting said multimedia data streams in packets of data within network frames, re-transmitting said transmitted packets of data upon a previous transmission failure and a request by at least a second network component, and restoring the temporal relationships between said packets of data after a packet is re-transmitted.

25. In a computer network wherein multimedia data streams are transmitted between network components, a protocol defining a set of quality of service parameters that provide a guaranteed bandwidth, a maximum latency and a dynamic rate control mechanism for transporting said multimedia data streams.

26. The protocol of claim 25 wherein the quality of service parameters comprise one or more of the following: a maximum number of data retransmission attempts including zero; a bandwidth requirement including a transmission duration and a minimum number of transmissions per unit of time; a maximum permissible latency; and a set of parameters that define the channel protection.

27. An interface comprising means for transporting data from a first computer network component to at least a second computer network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream.

28. The interface of claim 27 further comprising a wireless transceiver to communicate in a wireless computer network.

29. A system comprising an interface capable of transporting data from a first computer network component to at least a second computer network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream.

30. A machine-readable medium that provides instructions, which when executed by a machine, cause said machine to transport data from a first computer network component to at least a second computer network component in streams that include a first set of stream set up negotiations providing a unique identifier to each one of one or more data packets associated with a data stream