EP1302048A2 - Qualite d'extensions de service pour applications multimedia dans un reseau d'ordinateurs sans fil - Google Patents

Qualite d'extensions de service pour applications multimedia dans un reseau d'ordinateurs sans fil

Info

Publication number
EP1302048A2
EP1302048A2 EP01937456A EP01937456A EP1302048A2 EP 1302048 A2 EP1302048 A2 EP 1302048A2 EP 01937456 A EP01937456 A EP 01937456A EP 01937456 A EP01937456 A EP 01937456A EP 1302048 A2 EP1302048 A2 EP 1302048A2
Authority
EP
European Patent Office
Prior art keywords
stream
ack
ppc
request
bandwidth
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01937456A
Other languages
German (de)
English (en)
Inventor
Rajugopal R. Gubbi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharewave Inc
Original Assignee
Sharewave Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/615,573 external-priority patent/US6934752B1/en
Application filed by Sharewave Inc filed Critical Sharewave Inc
Publication of EP1302048A2 publication Critical patent/EP1302048A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/824—Applicable to portable or mobile terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2838—Distribution of signals within a home automation network, e.g. involving splitting/multiplexing signals to/from different paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/284—Home automation networks characterised by the type of medium used
    • H04L2012/2841—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Definitions

  • the present invention relates generally to a scheme for communications within a computer network and, in particular, to a scheme for communicating multimedia data across a computer network such as a local area network (LAN).
  • LAN local area network
  • Modern 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.
  • most computer networks have relied on wired links to transport this information.
  • 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.
  • 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.
  • computers In the home and office environments, computers have traditionally been used as stand-alone devices. However, initially at the office and more recently at home, there have been some steps taken to integrate the computer with other devices. 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.
  • analog wireless links for transporting information between these units.
  • Such analog wireless links operate at frequencies commonly utilized by wireless telephones.
  • analog wireless communication links suffer from a number of disadvantages. For example, degraded signals may be expected on such links because of multipath interference.
  • interference from existing appliances, such as televisions, cellular telephones, wireless telephones and the like may be experienced.
  • analog wireless communication links offer less than optimum performance for a home or office environment.
  • a subnet 10 includes a server 12.
  • 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).
  • 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, video teleconferencing equipment, and other office or 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.
  • 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.
  • PN pseudorandom
  • 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.
  • the server 12 and/or its associated host 13
  • the clients 16 communicate with their various subclients 20 using, for example, wired communication links or wireless communication links such as infrared links.
  • 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.
  • 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.
  • ECC error correction coding
  • 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.
  • each transmission slot (forward or reverse) is made up of one or more radio data frames 40 of variable length.
  • 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.
  • ECC error correction coding
  • the ECC bits may be used to simplify the detection of the beginning and ending of data packets at the receive side.
  • 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.
  • 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.
  • 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.
  • 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 Bi, B2, etc., which are assigned by server 12 to the individual clients 16 for their respective transmissions to the server 12.
  • Losy 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 encodeddecoded 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 log-in 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.
  • each directional slot i.e., F and B
  • each directional slot i.e., F and B
  • 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 on-line 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.
  • PCF Point Coordinator Function
  • CPFs contention free periods
  • the PCF does not guarantee the availability of the beacon period itself; a DCF-only station can manage to occupy the channel and delay the beacons arbitrarily. These delays can be as large as the maximum size of the data frame that is supported in the 802.11 standard. Additionally, the PC uses a DIFS plus a random back-off delay to start a CFP when the initial beacon is delayed because of deferral due to a busy medium. This further complicates the problem of providing a periodic opportunity for the stations (STAs) to transmit their data.
  • PCF access point
  • PC point coordinator
  • Another factor detrimental to multimedia data transport is inefficient operation in channel overlap conditions. There is a risk of repeated collisions if multiple, overlapping, PCs operate in the same PHY channel. There is the added complication of a PC being required to lose control of the medium for a random number of slot times periodically. As the home market widens and the wireless stations are used by apartment dwellers, the throughput reduction due to this problem becomes unacceptable for the user. Further, two sets of devices belonging to the same user can form two basic service sets (BSSs) each with a PC. This causes unnecessary increase in beacon traffic and exacerbates other problems due to collisions.
  • BSSs basic service sets
  • the present scheme although applicable to wired networks, is offered as a supplement to the scheme proposed in the 802.11 standard for wireless networks in an effort to provide the most advanced and useful description.
  • This invention provides Quality of service extensions for multimedia applications communicating across a computer network, and as mode of example, these extensions are defined in relation with existing issues that apply to 802.11 WLANs.
  • Some of the main extensions proposed are the following: the medium access control (MAC) header is extended to include the components for multimedia support; the network topology extensions include tighter definition of the point coordinator (PC); peer-peer connections during contention free periods (CFPs); alternate PC and proxy PC.
  • the Quality of Service (QoS) related extensions include the simplifying the operation during CFPs, support of streams, stream priority, synchronization of time division multiplex (TDM) transmissions by devices during CFP, dynamic bandwidth management, channel protection using error control coding and negotiable retransmission parameters.
  • QoS Quality of Service
  • TDM time division multiplex
  • dynamic bandwidth management By dynamically negotiating for the priority, bandwidth and the retransmission parameters for each stream separately, the network capacity is optimally distributed among different multimedia streams and the latency control is achieved.
  • DCF distributed coordination function
  • This invention enhances the 802.11-MAC to provide QoS to multimedia streams. For this purpose it introduces concept of streams at MAC and bandwidth management policies for the streams. This description is centered on the already existing point coordinator function (PCF) and recommends direct station to station data transmission without having to relay it through a PC. The proposal maintains complete compatibility with the current definition of 802.11-MAC. In essence the following enhancements are proposed.
  • PCF point coordinator function
  • MM-data is for the multimedia data that needs to be transported and MM-Command is for the new MAC management frames.
  • a new MM-control field containing frame position, stream index, BSS session ID and time stamp.
  • Additional elements are defined for Beacon, probe response frames. These elements are to indicate the current load and indication on the bandwidth shared with other overlapping subnets in the same channel. Additional element to indicate whether the PC is actually Proxy PC is also defined.
  • a selective retransmission mechanism to improve the efficiency of the stream transportation is defined.
  • 8. Stream Management and dynamic bandwidth negotiation schemes are defined.
  • 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 an example of a transmission hierarchy in a multimedia enhanced network according to one embodiment of the present invention
  • Figure 4 illustrates an example of a multimedia enhanced MAC frame format according to one embodiment of the present invention
  • Figure 5 illustrates an example of a multimedia enhanced MAC frame header format according to one embodiment of the present invention
  • Figure 6 illustrates an example of a structure of a unicast command frame according to one embodiment of the present invention
  • Figure 7 illustrates an example of a structure of broadcast command frame including command blocks, commands, and sub-commands, according to one embodiment of the present invention
  • Figure 8 illustrates an example of a multimedia enhanced capability information field according to one embodiment of the present invention
  • Figure 9 illustrates an example of an element for network frame index according to one embodiment of the present invention
  • Figure 10 illustrates an example of an element for a Beacon Generator Properties according to one embodiment of the present invention
  • Figure 11 illustrates an example of an element for load indication according to one embodiment of the present invention
  • Figure 12 illustrates an example of the operation of PPC within the network frame of a PC according to one embodiment of the present invention
  • Figure 13 illustrates an example of a transmission sequence in a network frame according to one embodiment of the present invention
  • Figure 14 illustrates an example of a data stream hierarchy in a multimedia- enhanced network according to one embodiment of the present invention
  • Figure 15 illustrates an example of a stream connection process according to one embodiment of the present invention
  • Figure 16 illustrates an example of a stream disconnection process according to one embodiment of the present invention
  • Figure 17 illustrates an example of a retransmission mechanism — Ack and Nack— according to one embodiment of the present invention
  • Figure 18 illustrates an example of overlapping subnets sharing the same channel according to one embodiment of the present invention
  • Figure 19 illustrates an example of the transmissions slots of each one of several subnets in a complete overlap scenario according to one embodiment of the present invention
  • Figure 20 illustrates an example of the beacon distribution for transmissions of several subnets in a complete overlap scenario according to one embodiment of the present invention
  • Figure 21 illustrates an example of the operation of a proxy-coordinator according to one embodiment of the present invention
  • Figure 22 illustrates an example of a Null command according to one embodiment of the present invention
  • Figure 23 illustrates an example of a Stream Management command according to one embodiment of the present invention
  • Figure 24 illustrates an example of a Restart All Stream Connections Subcommand according to one embodiment of the present invention
  • Figure 25 illustrates an example of a Stream Connection request subcommand structure for transmit or receive streams according to one embodiment of the present invention
  • Figure 26 illustrates an example of a Stream Connection request subcommand for transmit and receive streams according to one embodiment of the present invention
  • Figure 27 illustrates an example of a Stream Connection accept subcommand structure for transmit and/or receive streams according to one embodiment of the present invention
  • Figure 28 illustrates an example of a Stream Connection reject subcommand according to one embodiment of the present invention structure
  • Figure 29 illustrates an example of a Stream disconnect subcommand according to one embodiment of the present invention
  • Figure 30 illustrates an example of a Stream authorization Request/Grant/Reject subcommand structure according to one embodiment of the present invention
  • Figure 31 illustrates an example of a Dynamic Bandwidth Management command according to one embodiment of the present invention
  • Figure 32 illustrates an example of a Dynamic Bandwidth Request subcommand according to one embodiment of the present invention
  • Figure 33 illustrates an example of a Stream Management Grant subcommand according to one embodiment of the present invention
  • Figure 34 illustrates an example of a Remain Quiet/Ack Command according to one embodiment of the present invention
  • Figure 35 illustrates an example of a Change Channel/Ack Command according to one embodiment of the present invention
  • Figure 36 illustrates an example of a Channel status Command according to one embodiment of the present invention
  • Figure 37 illustrates an example of a PC Redundancy command according to one embodiment of the present invention
  • Figure 38 illustrates an example of a PCR Negotiation subcommand according to one embodiment of the present invention
  • Figure 39 illustrates an example of a PPC command according to one embodiment of the present invention
  • Figure 40 illustrates an example of a Proxy service request subcommand according to one embodiment of the present mvention
  • Figure 41 illustrates an example of a PPC provider request subcommand according to one embodiment of the present invention
  • Figure 42 illustrates an example of a PPC service for subnet connection subcommand according to one embodiment of the present invention
  • Figure 43 illustrates an example of a PPC permission grant/ack subcommand according to one embodiment of the present invention
  • Figure 44 illustrates an example of a Proxy Service Reject/Break subcommand according to one embodiment of the present invention
  • Figure 45 illustrates an example of a Proxy coordinator provider request subcommand for the OSB purposes according to one embodiment of the present invention
  • Figure 46 illustrates an example of a PPC-OSB tunneling subcommand according to one embodiment of the present invention
  • Figure 47 illustrates an example of a Proxy coordinator relieve request subcommand according to one embodiment of the present invention
  • Figure 48 illustrates an example of an Overlapping Subnet Bandwidth Negotiation command according to one embodiment of the present invention
  • Figure 49 illustrates an example of an Overlapping Subnet Bandwidth Request subcommand according to one embodiment of the present invention
  • Figure 50 illustrates an example of as Overlapping Subnet Bandwidth Grant subcommand according to one embodiment of the present invention
  • Figure 51 illustrates an example of a Master Coordinator relieve request subcommand according to one embodiment of the present invention
  • Figure 52 illustrates an example of a Proxy coordinator command according to one embodiment of the present invention
  • Figure 53 illustrates an example of a Retransmission command according to one embodiment of the present invention
  • Figure 54 illustrates an example of a Retransmission Request subcommand according to one embodiment of the present invention
  • Figure 55 illustrates an example of a Retransmission Fail subcommand according to one embodiment of the present invention
  • Figure 56 illustrates an example of a Retransmission Resync subcommand according to one embodiment of the present invention
  • a wireless local area network compliant with the 802.11 standard (802.11 WLAN) provides a good support for device connection and authentication, and has concentrated mainly on the transport of asynchronous data over a wireless medium. These features of the 802.11 standard are sufficient for data network applications.
  • the scheme described in the above-cited co-pending application (hereinafter referred to as the "Whitecap" scheme) is designed from ground up for the transport of multimedia data streams with all the multimedia services required by a WLAN.
  • Recent efforts in the development of the 802.11 standard and the Whitecap architectures are leading to higher bit rates and better products in the market. Many manufacturers are able to produce consumer electronic devices that provide the flexibility of a wireless solution at home or at the office.
  • the following description proposes the best mode of implementation known to the inventor for an efficient multimedia data communication scheme.
  • the current state of the art and consumer trends indicate that wireless communication systems will be the best method of implementing communication networks, without limiting the invention to this technology, this description is focused on wireless networks, referencing as the basic underlying computer network architecture the 802.11 based WLANs.
  • the proposed extensions to the point coordinator function (PCF) can be broadly categorized into two groups; network topology support and quality of service (Qos) for multimedia data.
  • the quality of service extensions can be further divided into dynamic slot support, streaming support, priority support, network synchronization support, dynamic bandwidth management, channel robustness support, dynamic channel change support and overlapping subnet support.
  • this invention presents a set of basic of services that can support future developments in the field and hence provides for a long lasting protocol.
  • Multimedia Station a network component having all the extensions for transporting multimedia data as disclosed in this mvention.
  • Point Coordinator Point coordinator as defined in the 802.11 standard with the added functionality for multimedia data transport capability.
  • Alternate Point Coordinator An MMS that is capable of becoming a PC. Multiple devices in a subnet may have PC capabilities and a voting scheme is followed to choose one of them to become the PC for the subnet.
  • Proxy Point Coordinator An MMS that is providing proxy services.
  • the nature of proxy service can be of two types, first, within the subnet between two devices providing data repeater services. Second, it can be between multiple subnets for the purposes of negotiations to share the bandwidth in the same channel.
  • Network frame is defined as the periodically occurring frame starting from the beacon transmission of a PC and containing transmissions of the MMSs within the PC's local BSS, followed by the transmissions of MMSs in overlapping BSSs sharing the same PHY channel.
  • Streams A set of MAC frames belonging to the same application level data, typically with high bit content and timing requirements (isochronous). For example, video, high fidelity (CD quality) audio, or videoconferencing connections.
  • Stream Management Process through which a stream is initiated within a subnet. This involves authorization of the receive device for consuming the device and making sure sufficient BW is available to entertain the QoS requirements of the stream.
  • Subnet A cluster consisting of one PC and several clients attached to it. The word Subnet is used in synonym to a BSS in 802.11 network.
  • DTDMA Dynamically adjustable Time division Multiple Access
  • BSS-SID Basic Service Set Session Identification
  • Master Coordinator Is the point coordinator with the BSS-SID zero. This PC provides the beacon that marks the beginning of the network frame and also provides the management for bandwidth sharing among the overlapping BSSs that are currently sharing the same PHY channel.
  • DBM Dynamic Bandwidth management
  • ECC Error Correction Coding
  • the disclosed enhancements to the 802.11-MAC architecture support multimedia data flow, both in a server-client and a peer-peer fashion.
  • the basic architecture described in this embodiment is based on PCF (point coordinator function). All devices share the media in a dynamically adjustable TDMA fashion.
  • the present invention may support several types of devices. They may be very thin clients, thin clients, fat clients or personal computers. Very thin clients are those that have neither significant processing capability nor data storage capability. Examples of this are simple input/output devices like wireless keyboards and display units. Several set top boxes also fall into this category as they neither can process the incoming data nor can provide any significant storage spaces. Thin clients are those having considerable magnitude of processing ability but little or no storage capability. Examples of these are D? phones. Fat clients could have both processing ability and data storage capability. Usually these types of clients are specific to the applications they are designed for. The personal computers are considered as a separate type of devices in this discussion as they are unique owing to their richness in processing ability, data storage capability and type of applications they can run.
  • PC point coordinator
  • API alternate point coordinator
  • PPC proxy point coordinator
  • MMS multimedia station
  • a point coordinator is the device that is responsible for operation of devices in contention free period (CFP).
  • CCP contention free period
  • PC is also responsible for slot timings, synchronization and dynamic network management.
  • a proxy point coordinator is a client device providing a time reference for a low power or a hidden device that cannot directly communicate with the PC. Whenever a device that is trying to reach the PC fails to do so, a client device (MMS) that can receive from both the PC and the new client device can volunteer to provide a time reference and a tunnel for the communication between them. This is discussed in detail later.
  • MMS client device
  • An APC is a client with the capabilities of a PC.
  • a set of devices in the subnet can be configured as APC. Whenever there is a break down at the current PC, one of these devices can take over the responsibility of the PC thus avoiding network failure.
  • An MMS is a STA with enhancements to support multimedia applications. Its multimedia capabilities are defined in the following requirements. An MMS should,
  • an MMS can optionally measure and report collisions during non-CFP so that the PC can optimize the CFP v/s non-CFP communications.
  • beacons provide the time reference to the MMSs for their transmissions.
  • the PC is required to negotiate and/or allocate the transmission slot duration within CFP for each MMS.
  • the PC is required to monitor the bandwidth utilization by the MMSs during CFP and renegotiate the bandwidth with them, if required, so as to optimize the network utilization.
  • Dynamic channel change The PC is required to measure the channel losses, receive the feedback on channel status from the individual MMSs and assess the channel conditions. If the current channel is severe, the PC is required to momentarily pause the CFP operation and look for a better channel. Once a better channel is found, the PC is required to inform all the associated STAs in the current channel and move the network operations to the new channel. The same mechanism, but in a slightly different manner, may be used when the current channel is occupied and a new PC wishes to establish a CFP. The new PC should check other channels for a free channel before starting negotiations to share bandwidth with a currently operating PC during a CFP.
  • a PC should always monitor the contention period and make sure there is at least one data frame plus acknowledgement duration left free in the contention period.
  • APC alternate point coordinator
  • all the APCs are periodically updated with a table of currently operating MMSs and their operating parameters. If an APC is away/off and associates itself during an ongoing session, it either waits for the PC to provide such an update or it can request the information. If there are multiple APCs volunteering to take over the responsibility of a failed, then these APCs may vote for the responsibility. This is achieved by broadcasting a list of the available resources at each of these volunteering APCs. The APC with the largest number of resources wins the negotiation. This can take multiple iterations of negotiations depending on the type of APCs and number of APCs involved. If there is more than one device with equal resources at the final negotiation stage, then the device with the highest MAC address is chosen for this responsibility. The list of resources that are used in this negotiation is shown in Table 1 and they are arranged in their order of priority.
  • a multimedia command should also contain a field to indicate whether the device was designated as a PC during its installation. The comparison is performed from top to bottom and the decision is made whenever a better resource comparison is found. If there are multiple devices designated as PCs during installation, then similar negotiations may be held and the device with more resources wins the negotiation. The other devices that are not designated as a PC during installation leave the negotiation once such a device enters the fray. Three scenarios in which an MMS replaces the current PC are discussed in the following sections.
  • a proxy point coordinator is an MMS acting as a proxy PC between the actual PC and another MMS requesting a connection with the PC.
  • the ability to become a PPC is optional for MMSs.
  • a PPC comes into action when it recognizes that a request from an MMS is going unanswered by the operating PC. This may occur because of a hidden node problem.
  • an MMS When an MMS recognizes that request-calls from another MMS are going unanswered by the currently operating PC, then it may volunteer to be a PPC. If it is not already associated with the operating PC, it so associates itself and obtains permission to be the PPC for the requesting MMS. Once the operating PC grants such permission, the PPC forms a tunnel between the operating PC and the requesting MMS by repeating the frames transmitted from either network component to the other. The PPC also sends a beacon for the use by the requesting MMS. This beacon will have all the information from the beacon of the operating PC with the CF parameters appropriately adjusted to simulate a CFP within an existing CFP. Even when there is a PPC operating, all the MMS are required to register with the PC whenever possible.
  • the beacons from a PC and any PPCs can be clearly differentiated by the CF parameters contained therein.
  • the CF parameters in a beacon from a PPC indicate a CFP contained within the duration indicated by the CF parameters in a beacon from the PC.
  • an MMS can be allocated transmission bandwidth from either PC or a PPC, but not both, it can receive frames at all times. This enables an MMS to receive from a device during the CFP of the PC and transmit during the CFP of a PPC or vice- versa. All the transmissions managed by PC or a PPC should use the same BBSS-SID and operate as defined in the 802.11 standard.
  • the present protocol provides definitions for extensions to allow any two stations to request transmission time during CFP and transfer data amongst themselves. This limits the burden on the PC to granting such transmission time and providing the beacon service avoiding the bandwidth overhead of the PC having to repeat the data for the actual destination station.
  • the peer-to-peer connection extensions will be defined below.
  • Transmitted data has four layered structures in the hierarchy as shown in Figure 3.
  • Each network frame 52 has transmissions from a PC and client devices arranged in a time-shared fashion.
  • Each device's transmission contains one or more streams 54 (audio, video, and data streams) and one command (virtual) channel.
  • Each device's slot 55 is time divided for different classes of data.
  • Radio data frames 44 are of variable length and contain the PC/client data MAC frames 30, which in turn are of variable length.
  • Each network frame 52 is divided into a contention free period (CFP) 57 and a contention period (CP) 58.
  • the CFP 57 in each network frame 52 is divided into several slots 55, each slot 55 being for transmissions by a multimedia-enabled device (MMS).
  • MMS multimedia-enabled device
  • Each device and the PC dynamically negotiate the duration of these slots 55 so as to achieve the best possible bandwidth utilization.
  • the bandwidth is negotiated with the PC by the transmitting device.
  • the PC maintains a dynamic table consisting of all the bandwidth allocations. This information is used in deciding connection to a new client.
  • the connection type (isochronous or non-isochronous) and the required min/max bandwidth are negotiated during the creation of the stream 54.
  • Each device's transmission contains MAC frames 30 (shown in Figure 4) intended for different devices in a sequential order. Groups of frames for each device constitute a stream-like command, voice audio, video and data, etc. These streams 54 are also referred to as the virtual channels or virtual streams in this description.
  • the duration of a network frame 52 and the duration of each transmission slot 55 is set by the PC based on the Quality of Service (QoS) requests from the client devices so as to achieve the best possible bandwidth utilization with optimal latency in the delivery.
  • QoS Quality of Service
  • An MMS/PC does not send or expect MAC-level acknowledgements to any frame received during the CFP as this can disrupt the TDM operation of the network during the CFP.
  • An MMS is not allowed to send any non-MM frames during a CFP. Instead, such communications are limited to the contention periods within each network frame.
  • MMS/PC can send MM frames to another MMS/PC during contention periods expecting the MAC-level acknowledgements starting within SIFS similar to the acknowledgements currently defined for control, data and management frames.
  • beacons for CFP 57 in the present scheme is similar to that defined in the 802.11 standard, with the following enhancements.
  • the PC should indicate the next channel it intends to use in the channel field. This can be used by any overlapping BSSs to occupy the current channel after the current BSS moves over to a new channel.
  • All the MMSs and PPCs make use of the beacon information after verifying the BBSS-SID contained in the beacon.
  • the beacon period indicated by the CF parameters in the beacon from the PC are used, so that if a beacon is lost because of channel corruption, network components still operate using the periodicity indicated by the previously received beacon.
  • a PPC within one network is clearly distinguished from a PC of another network operating within the CFP of the same PC by the differences in their BSS-SID and BBSS-SIDs.
  • NAV settings upon reception of a beacon by all non-MMSs are same as those defined in the 802.11 specification.
  • All MMSs strictly adhere to the negotiations and agreed upon transmission times within a CFP. They transmit only during the allocated transmission slots 55 within the CFP and have the freedom to contest for the time during a contention period 58. Additionally, all MMSs must make use of the guaranteed repetition of the beacon, whose period is provided by the PC during the association.
  • the PC should send the beacon with an appropriate beacon interval.
  • the TBTT is set such that the actual beacon is trasmitted after a delay of (2*DIFS+RTS+CTS+3*SIFS+MaxData+Ack) from the start of the CFP. This allows a non-MMS to have started its transmission just before the start of the CFP and still not affect the time of the beacon transmission. However, MMSs know the actual start time of the beacon transmission and hence can make use of this period before the beacon, if available, for connection establishment purposes.
  • the PC monitors the channel and recognizes the frames from STAs with the Duration field set to exceed the NAV beyond the actual transmission of the beacon by the PC. If such a frame is detected during the CFP before the beacon, then the PC sends out a short dummy frame during the period of acknowledgement to that frame. This corrupts the acknowledgement frame, forcing the STA to back off the channel.
  • This mechanism along with the above-proposed delay, guarantees the availability of channel time for a CFP at the period that the PC indicates in the beacon as the beacon interval.
  • the first and last multimedia frames transmitted by an MMS during its CFP transmission slot 55 must contain such first or last frame indication in its MAC header 31 for other devices to be able to recognize them. If a device receives the last frame from the device preceding it in the CFP transmission list, then said device can prematurely start transmitting in the leftover time. This feature provides the opportunity to maximize the use of bandwidth during CFP operation whenever a device runs out of data before the end of its assigned TX-slot.
  • the "last frame" time window of observation must be limited. This time window should start only after the last frame from the device transmitting one TX-slot prior to each device's preceding TX-slot.
  • the currently reserved frame type '11' (binary) is used for multimedia (MM) frames.
  • the MM frame type has two subtypes, MM-data and MM-Command.
  • the MM-data subtype is used to transport the data in streams.
  • MM-Command subtype is used to communicate the management commands defined in a later section of this description.
  • MM frames 30 have three main parts; the header 31, the payload or body 32 and the ECC 33. There are two proposed frame formats depending on the way ECC bytes are transmitted.
  • the MAC frame header 31 is defined having a new field called MM-control field 36 which is four bytes long.
  • MM-control field 36 which is four bytes long.
  • the various fields in the header 31 and the sub-fields of the MM-control field 36 are shown in Figure 5. These fields and their usage are discussed in the following sections.
  • the sequence control field 37 in the enhanced header 31 is used as "stream sequence control". That means that every stream transported with this header format must have an independent sequence number (independent of other traffic in the BSS).
  • the frame position field (FP) 38 is two bits long and indicates the position of the frame, within the TX-slot.
  • the least significant (LS) bit is used to indicate whether the current frame is the first frame and the most significant bit (MS) is used to indicate the last frame. Setting both of these bits to logic low (00) is used otherwise.
  • This embodiment defines a Pad bytes count sub-field 39 that indicates how many bytes are padded in a frame to make the entire frame DWORD (4 bytes) aligned.
  • This sub-field helps easing the hardware implementation of the MACs by working with DWORD aligned frames instead of byte aligned frames.
  • the MAC hardware is expected to pad bytes at the end of the frame after the FCS field and report the count in this sub-field.
  • this information is used to determine the correct length of the frame throw away the padded bytes.
  • the BSS-SID sub-field 41 comes to use when overlapping subnets needs to operate in the same channel. In the present embodiment, this field allows up to 16 overlapping subnets to share the same channel as described below. 4.3.4 Stream Index
  • the 8 bit stream index sub-field 43 is used in conjunction with the MAC addresses of the originating device to uniquely identify a data stream.
  • a device can generate or consume up to 255 streams from each of the other devices in the network. All the values of stream index are dynamically assigned and used.
  • the 16 bit stream Time Stamp sub-field 45 is used to provide support for synchronization of any two streams originating from a device.
  • the contents of this sub-field are multiplied with 1024 microseconds (TU) to obtain the actual time. Details on the use of this sub-field are described later in this description.
  • the MAC frame body 32 contains the information (data) bytes.
  • the body contains a chain of commands and subcommands.
  • a command frame body 60 can have either the unicast or the broadcast format depending on the destination address in the MAC frame header 31. If a device is going to send a command frame to another specific device, it can use the unicast format. This same format can also be used to send one command frame with several command blocks 62 within that frame. Any number of commands 64 can be chained together within a unicast command frame or a command block in a broadcast command frame. However, this concatenation of commands is limited by the allowed maximum size of a MAC frame. The commands used for the network operation are defined in a later section.
  • each command block consists of a header 70 with three fields and several micro-blocks 62.
  • the command block header 70 contains a destination address 72, the block is length 74 and a sequence number 76 for the micro-block that was received last from the specified destination address 72.
  • Each micro-block 62 has a chain of commands 64.
  • Each command 64 consists of a command description 65, a command payload length 66 and the command is payload 67 itself.
  • the unicast frames do not have command blocks 62 but have the header 70 containing the sequence number 76 of the micro-block that was received last from the specified destination address.
  • the command micro blocks 62 that are same as described above.
  • the command micro-block 62 is given an increasing sequence number that is specific to a destination address.
  • the command frame body 60 contains a series of commands 64 with a command description 65 that is followed by the associated command payload 67 destined for one device.
  • the structure of the unicast command frame body is shown in Figure 6. As the entire command frame is meant for one destination device, the number of command frames that needs to be sent out from each device is equal to the number of destination devices it is communicating to. If a command does not have any subcommand specified, the payload must contain the bytes corresponding to the command without any subcommand structure inside.
  • the command frame body 60 contains series of command blocks 62 as shown in Figure 7. Each device can compile all the commands 64 intended for a destination device into a command block. All the command blocks can be combined into one frame which can be transmitted as a broadcast frame.
  • the device that receives a command acknowledges the reception in a command packet of its own
  • the device that sends a command is required to know the command or the boundary that is indicated in the received acknowledgement 76.
  • the commands transmitted for the first time in a command frame are grouped into a micro-block and assigned a sequence number (uBlock Seq).
  • Each subsequent command frame must contain all the micro-blocks that have not been acked or have not timed out.
  • the mirco-blocks should be arranged in the same order as of their first transmission. This sequence is dependent on the acknowledgements from the destination device and hence, each device may have more than one sequence of micro- blocks.
  • the device that receives a command frame must send the sequence number of the last micro-block that it received from the sender as the acknowledgement 76 to the device.
  • the uBlock-Seq-Ack 76 received in a command frame is used to remove those commands from the list of micro-blocks pending for transmission.
  • Each MM frame 30 is protected using selectable an ECC depending on the requested type of channel protection for the corresponding stream.
  • CRC is computed using the JEEE-32 bit CRC polynomial and appended to the MAC frame 30 as similarly to how it is currently defined in the 802.11 standard.
  • the ECC is based on GF(2 8 ) RS coding.
  • the size of the CRC is 32 bits and the size of the ECC is based on the frame size, the ECC block size (n), the ECC message size (k) and the number of correctable errors (t m .
  • one embodiment shows capability information contained in a management frame 80 that includes the following one bit information fields:
  • PPC proxy services
  • an APC capability bit 86 to indicate whether the device can be an alternate PC (APC)
  • a channel sharing bit 88 to indicate whether the BSS is sharing the channel with other overlapping BSSs.
  • the interpretation of the current channel field in the DS parameter set is modified to mean the next channel number. This change is necessary to enable the dynamic channel change feature.
  • the beacon frames must also have the following information elements.
  • the beacon must have a network frame index 90, depicted in Figure 9, with a running network-frame-index-number 93 for the beacons transmitted. This is required for a client device to synchronize with commands like the channel change command.
  • the beacon must have a generator device property field indicating whether the device is a PPC in a PPC sub-field 102 or an MC in an MC sub-field 104 as shown in Figure 10. For a PC, the PPC bit 102 will be zero.
  • the beacon must have a current-load field 110 indicating the number of associated devices 112, the percentage of bandwidth used in the BSS 114, the number of subnets sharing the same channel 116, and the percentage of bandwidth used in said channel 118.
  • the new disassociation reason codes are:
  • PC is turning off with no APC in the network
  • PPC cannot serve this client anymore. This reason can be used if and only if a PPC currently serves this client.
  • the operation of the PC is enhanced to include the responsibilities of Stream Management, dynamic bandwidth allocation, and network synchronization.
  • the PC decides the network parameters depending on the requests from the clients. In associated with its BSS one embodiment these parameters may be, network frame size, number of stream connections, transmission duration of each device, etc.
  • the PC optimizes these parameters for efficient network performance and communicates them to all the devices in the BSS.
  • 6.2 Proxy Point Coordinator (PPC) PPC
  • a PPC is a client proxying as a point coordinator for devices that have poor reception from the actual PC.
  • the PC selects a device to be the PPC depending on the inputs from the device.
  • the proxy service involves providing time reference through proxy-beacon and command and data relaying between two devices. An example of this operation taking place is when a client's link with the actual PC is poor and the client requests a proxy service from a device with a better link to both, the PC and the requesting client. Another example of this type of proxy operation would be a device requesting command and data relay services for another device in the BSS with whom its link is poor. If the client being served does not see a PPC for a predefined duration, it can request a new PPC connection to some other device. Similarly, if a PPC does not receive from a client for a predefined amount of time, it must inform the PC and withdraw itself from the PPC service to that client.
  • the duration allocated for the PPC transmission is simply treated as a TX-slot by the PC, and the duration allocated for a PPC's CFP_Max_duration is determined based on the transmission requests from the individual devices operating within that duration.
  • the PPC is responsible to communicate the bandwidth allocation decisions from the PC to those devices it is servicing.
  • PPC Data relay services between devices.
  • the PPC is allowed to modify the From-DS and To-DS bits in the MAC header and insert its own address in the from-DS address field.
  • a device can have one PPC per link that it is connected to, though ideally one PPC for all devices is desired;
  • the PPC function is depicted in Figure 12.
  • the PPC's operation 122 is included in the overall PC's CFP operation 124.
  • An MMS operating as a PPC is allocated more than one CFP TX-slot. First it may transmit its own data as an MMS in a first TX-slot and second it may relay the data from one or more other MMSs in subsequent TX-slots operating as a PPC.
  • APC Alternate Point Coordinator
  • Time synchronization between the PC and the clients is important in any isochronous-date capable network.
  • This scheme achieves synchronization through the exchange of synchronization commands and PC beacons 53.
  • the parameters used to achieve network synchronization are:
  • the network frame 52 size is the time between two beacon 53 transmissions from the PC. This parameter is decided based on the number of online clients, then- bandwidth, and their latency requirements.
  • the wait time 132 is the time for which a device has to wait after receiving the beacon 53 from the PC and before it can start transmitting.
  • the transmission slot 55 is the allocated transmission duration for each device in the PC's local subnet (BSS).
  • a PCF beacon 53 is periodically sent from the PC to its client devices as a time reference.
  • the devices depending on proxy coordinators use the proxy beacons for time reference.
  • the PC provides each client with the network synchronization parameters discussed in the earlier section.
  • the clients honor this agreement by waiting and starting transmission at the allocated. While waiting, if a device detects the end of transmission indication from the preceding device, then it immediately starts its own transmission. The end of transmission is detected when the preceding client sends a MAC frame marked as the last MAC frame.
  • the extra bandwidth, if any, detected by the current client device can be used of to send its queued up data. For example, if a client is supposed to wait for 20msec and it detects the last MAC frame from the preceding client within 15msec, then it can use the extra 5msec. Due to high MAC frame losses in wireless channels accurate wait times are necessary in starting the transmission from a device. If necessary, PC can indicate the broadcast address in the previous client Identification field restricting the client from using such left over bandwidth. Additionally the clients themselves may not use extra bandwidth if there are strict timing restrictions on their transmissions. 7.3 Time Synchronization of Action to PC's Decisions
  • the PC has the responsibility of taking decisions on the above listed synchronization parameters and the change of channel operation. However, a more important responsibility that comes with the of decision-making is conveying the decision information to all the devices in the subnet and synchronizing their action to such decisions.
  • One example is the time synchronization to use new network synchronization parameters.
  • the PC achieves this operation by informing of the decision to all clients, typically in a broadcast message, and sending along the number of network frames to wait before making the new decision effective. Additionally, the PC might repeat the decision in many successive network frames. Whenever such repetitions are made, the time to wait is appropriately reduced. With this scheme, even if a device did not receive first few transmissions and receive the same later, it will wait until exactly the same time event as the other devices before adopting the new parameters.
  • the PC dynamically decides the network frame 52 size and communicates that information to all the client devices in the subnet before the change takes place.
  • the network frame size is decided based on the number of client network components that are currently online and the latency requirements of their streams. When there are many client network components, the network frame should be longer. Conversely, if there are fewer network components low latency requirements on their streams, then the network frame can be shorter.
  • an MMS requesting lower latency on an ongoing isochronous stream is allowed to transmit in more than one non-consecutive slot.
  • the association agreements would specify the number of slots, and the parameters for each slot. This mechanism may be essential in some situations, for example when one device is transporting a Voice Over IP (VOIP) stream to one MMS while transporting a DVD- video stream to another MMS in the same network frame.
  • VOIP Voice Over IP
  • the PC depending upon the latency requested, ultimately decides the number of non-consecutive slots per frame it can grant to any given device. 7.6 Synchronization When Multiple Overlapping BSSs Share The Same Channel
  • the synchronization parameters required, and their usage are very similar to the description above.
  • the parameters are, the network frame size 52, the wait time for each PC/BSS 132, the transmission slot duration for each BSS 55, the address of the PC of preceding BSS, and the corresponding BSS-SID.
  • the wait time at PC-level meant for beacon transmission is strictly enforced to avoid any confusion in the network hence no bandwidth optimization is allowed between BSSs.
  • These wait times are always measured from the initial synchronization beacon transmitted by the master-coordinator (MS). This forms two-stage wait times, where each PC waits for certain length of time from the beacon of master coordinator and the MMSs within each BSS wait for their pre-negotiated TX-slot a certain amount of time from the beacon of their associated PC.
  • This scheme provides the necessary mechanisms at the MAC layer for all the services necessary to transfer multimedia data.
  • Applications such as, VOIP and live video streaming generate isochronous data that needs a low latency network protocol with end-to-end QoS to function.
  • the use of the virtual stream concept simplifies the task of providing QoS for such data.
  • this scheme supports the ability of a PC to specify and control the bandwidth of each stream and the rate of each stream that is necessary to deliver the guaranteed bandwidth requirements.
  • Each network component can be transmitting a set of data streams and can be consuming another set of data streams. For every data stream generation and consumption, . the component must obtain permission from the PC and negotiate the network bandwidth for the same. The PC grants such requests depending on the available resources.
  • the client network components can dynamically connect and disconnect any stream and can re-negotiate the bandwidth for an existing stream on an on-going basis.
  • the hierarchy corresponding to the data streams is as shown in Figure 14. Any two data streams on the network can be distinctly identified based on the TX device address 142, the RX device address 144 and the stream index 146 that are sent with each MAC frame. Each of these streams can be negotiated with different QoS parameters.
  • the PC maintains the QoS and user list for each data stream and shares that information with all the users of that data stream.
  • Each stream needs to be connected when it is needed and disconnected when it is not needed any more. The only exception to this is the basic command channel from each QoS enabled device.
  • a set of Listen End-Point identifiers (16 bit) are defined so that a network component requesting a stream connection can do so with the correct End-Point at the destination network component.
  • the REP-ID is dynamically assigned to be unique for each stream connection and is exchanged with the other network component using the stream management commands that are defined later in this description.
  • the stream connection request 152 must contain the requester's End-Point ID for the stream and the Listen End-Point ID at the destination.
  • Some of the defined Listen End-Point ID are: v
  • connection, distribution and disconnection processes are described in the following sections.
  • Each network component is responsible for setting up and tearing down all the streams that it sources.
  • the PC keeps track of bandwidth allocation. Hence, for a stream connection between any two network components, the PC needs to be informed of the stream connection status and characteristics. Two possible approaches are: 1) Forward every connection setup request to the PC and have the PC node establish the stream connections between the clients; or
  • the drawback of the first approach is that the stream connection establishment time would be prolonged and that unnecessary additional load is imposed on the PC.
  • the second approach has the advantage of decentralization of the stream connection responsibility to the device that needs the stream connection.
  • the PC is only involved at the stage of authorization and bandwidth allocation for the connection.
  • a stream is unidirectional and the two ends of the stream are referred to as the source (Tx) and destination (Rx) devices in this section.
  • a stream index gets allocated for that stream, which is used for handling the MAC frames.
  • the source device 154 sends a stream connection request 152 to a destination device 156.
  • Such destination device acknowledges the request by transmitting back a stream connection accept 158 which is also acknowledged by the source device 154 who finalizes the negotiations with a stream connection complete 159 message and initiates the stream transmission 151.
  • the connection setup process also allows for the creation of a bi-directional connection, which essentially results in the creation of two such streams, one in each direction.
  • the multicast clients get permission to consume the multicast stream from the PC.
  • the source device needs to collect retransmission requests from all the destination devices for that stream and decide the MAC frames that need to be retransmitted.
  • either the source device 154 or the destination device 156 can initiate such a request.
  • An example of a stream disconnection process is shown in Figure 16 where the source device 154 is assumed to be initiating the disconnection by transmitting a stream disconnection request 162. In this case, the destination device 156 responds with a stream disconnection accept 164 message and the stream is disconnected. In multicast streaming, if a destination device 156 initiates such a request, the PC simply withdraws the devices permission to consume that particular data stream. 8.3 Support for Stream Synchronization
  • Stream synchronization is defined as the process of restoring temporal relationships between various streams or elements that compose the multimedia information.
  • the MAC layer assists in stream synchronization by providing stream sequence number and the stream time stamp in the header.
  • the MAC supplies this information to the upper layers.
  • This scheme describes four types of streams to be supported along with the current best effort priority: isochronous (2 priorities) and non-isochronous (2 priorities).
  • isochronous (2 priorities) and non-isochronous (2 priorities).
  • the priority of a stream is taken into consideration when a PC allocates bandwidth and when the frames are transmitted by TX-devices.
  • Every network component in the subnet can dynamically negotiate the required bandwidth with the PC. This is necessary when accommodating streams whose characteristics can change during transmission or when channel conditions change due to external factors such as interference.
  • the PC keeps track of all the bandwidth allocations. If a network component requests bandwidth that is more than the available, then the PC indicates how much the bandwidth is available to the network component. If it is sufficient for the network component to initiate its transmission, it accepts it and the bandwidth is allocated.
  • the actual algorithm employed in the dynamically allocation of bandwidth can vary across implementations.
  • Each client network component must collect the required bandwidth for each of its streams and provide that information to the PC.
  • the bandwidth requirement is divided according to the priorities of the streams.
  • the bandwidth changes are decided by the PC and indicated to the network components. These changes can happen due to several reasons. For example, whenever a new stream is being admitted, if an existing stream is being terminated, if another BSS starts sharing the channel or due to changes in stream characteristics that might be carried out periodically.
  • the bandwidth allocation is readjusted according to the priority of the stream. Within each of the stream priority level, the bandwidth is allocated as per the following order of priority.
  • the PC maintains a table listing the available bandwidth, the allocated bandwidth for each stream priority at every client network component, the requested bandwidth for each stream priority at every network component, and the time of request as shown in Table 3.
  • the requirements of the PC are treated in the same way as requests from other devices.
  • the PC and PPC devices can make use of more bandwidth for management purposes.
  • the PC is required to monitor the transmissions during the CFP by all MMSs and take action if they do not conform to the agreed upon transmission duration. If an MMS is consistently under utilizing the allocated bandwidth, especially the isochronous bandwidth, the PC can renegotiate that extra bandwidth and allocate it to other MMSs.
  • any network there are always some data packets that need not be related to any of the stream. Examples of this are an ARP packet from IP IPX based network and onetime management packets. A stream index of zero is reserved for such asynchronous data frames that do not need any consistent QoS parameters. Hence there is no connection, disconnection or QoS negotiations for streams with an all zero stream index. Any network component can use this all zero ID and send non-stream based data. This stream is given the lowest priority in the network and retransmission parameters are set so as to provide very high number retransmissions.
  • Maintaining low latencies is a challenge when transporting multimedia data types.
  • This scheme aims at guaranteeing the requested limit on the maximum latency through the following measures.
  • First, the retransmission attempts for a MAC frame in any stream are strictly bounded by the latency requirements.
  • the invention allows a stream to be transmitted more than once within a network frame.
  • a network component can request low latency for a stream in a long network frame and it is permitted to transmit its MAC frames frequently in the time slots appropriately arranged within a network frame.
  • This scheme supports Forward Error Correction (ECC) coding along with the Cyclic Redundancy Check (CRC) mechanism.
  • ECC Forward Error Correction
  • CRC Cyclic Redundancy Check
  • Each receiving device can request a specified ECC and a CRC for each stream.
  • 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. The ECC is applied to all streams of all priorities depending on the negotiations made during the stream connection establishment. 8.7.1 Error Correction Scheme
  • n, k Reed-Solomon coder over GF(2&)
  • error correction schemes may be used.
  • the 'n' and 'k' vary depending on the RF channel condition and negotiated QoS parameters for a particular class of data.
  • Each MAC frame (including the header) is split into blocks of 'k' symbols (each symbol is a byte) and the ECC is carried out to form 'n' byte blocks. If the number of bytes in a data MAC frame is not integer multiple of 239, then the last block is sent with a truncated ECC using the virtual zeros technique.
  • the ECC bytes are computed as if the data was 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. It is possible to add new types of ECC in the future through negotiations during stream connection establishments. Note that the size of the first block in every MAC frame is always fixed to RS(255, 239). The negotiation of the ECC type applies only from the second block onwards in each MAC frame. Hence RS(n, k) means the second block onwards, the block size is 'n' bytes with information being 'k' bytes unless there is less than 'k' information bytes remaining in the MAC frame.
  • the first block of 239 bytes is encoded using RS(255, 239), the next '1' blocks of data are encoded using RS(n, k) and the last block is encoded using RS(m+k, m).
  • the header of the MAC frame in a stream contains an incrementing sequence number and the receiving device responds with an acknowledgement for each sequence number received or missed.
  • the acknowledgements are grouped at the destination client to synchronize them to its own transmit-slot.
  • the acknowledgement is sent as a command in the command frame from the destination client back to the source device.
  • the source device always retransmits the negatively acknowledged frames first before transmitting any new MAC frames. If the ack-command is not received from the destination device, the source device continues to transmit new MAC frames assuming successful reception.
  • the MAC frames that were transmitted in earlier network frames are cleared upon the reception of ack for them or upon the expiration of the retransmission window time. Different commands used for this mechanism are discussed in a later section of this description.
  • FIG. 17 An example scenario illustrating this retransmission mechanism is shown in Figure 17.
  • device-A 170 is sending MAC frames 173 to device-B 172 where all the MAC frames are assumed to belong to the same stream.
  • the MAC frame with sequence number 3 is lost in the network Frame #n 52 and hence is negatively acknowledged 174 (Nacked) by device-B.
  • device-A retransmits MAC frame with sequence number 3 and then transmits some more new MAC frames.
  • the SR-ARQ commands are transmitted continuously in each network frame until the lost MAC frames are recovered or the window of retransmission expires.
  • the acknowledgement window is a moving window spanning from the first negatively acknowledge (Nacked) MAC frame to the last received MAC frame.
  • the ack- window is represented as a bitmap with each bit representing the acknowledgement status (Ack/Nack) for each MAC frame.
  • the initial offset of stream sequence number is supplied with the ack-window in each ack-command. Using this representation, all the acks for the MAC frames in an RX-stream are, grouped and sent back in one command when the destination device gets its opportunity for transmission.
  • the retransmission window is defined as the sequence of MAC frames in their increasing order of sequence number that can be stored at the source device available for retransmission. Hence, this window size depends on the tolerable delay or latency, expected channel conditions, and throughput requirements for a stream.
  • the retransmission window size is computed during the stream connection setup taking into account the above factors. During the transmission, the window size is optimized for the tolerable delay after which a MAC frame may be discarded if it has not been acknowledged by the destination device. 8.7.2.3 Maximum Number of Retransmissions
  • the maximum number of retransmissions of a MAC frame in a stream is negotiated during the stream connection negotiation. This number can also be negotiated to be zero for no retransmissions if necessary.
  • the source device can discard MAC frames if they are too old. This type of discarding is performed based on the maximum delay tolerable for that stream. Whenever a MAC frame is discarded at the source device, the destination device is kept informed of the occurance. The destination device must appropriately update its ack-window and receive window when such an indication is received from the source device.
  • the destination device can also discard MAC frames in a time-constrained stream. In such situations the destination device informs the source device to discard the MAC frames up to a certain sequence number. The source device must appropriately update its ack-window and retransmission window when such an indication is received.
  • a source device may not receive the ack command from the destination device if the acknowledgement MAC frame that was sent by the destination device is lost or corrupted in the channel. In such situations, the source device need not do any retransmissions in its next transmit slot. Instead, it can assume that all the MAC frames sent in the previous transmission slot have been received by the remote. However the source device must be ready to retransmit those MAC frames if the destination device sends any NAck later.
  • Each device measures the channel in terms of packet loss rate (PLR).
  • PLR packet loss rate
  • This information is periodically sent to the PC as feedback on the channel along with other channel related information like number of frames transmitted, number of frames received from the current BSS, number of packets received from other BSSs, etc.
  • the PC uses this information along with its own measurements to assess the channel conditions. This channel assessment is used for channel changing, decisions and also to detect or assess the overlap situations.
  • the last option in combating a severe channel is to change over to a better channel.
  • the PC decides whether to change from the current channel to a better channel.
  • the PC carries this operation out by first searching for a good channel and then instructing all the client devices to move over to the new channel.
  • the channel changing can happen in two situations: first, during the association of an MMS to a PC when they are in different channels; and second, during the operation of a BSS when the current channel of operation has low throughput to offer, either due to too many BSSs sharing the channel, or due to high interference. The following paragraphs describe these two situations and explain the process of changing the channel of operation.
  • the PC of a BSS always tries to be in a channel, with sufficient available bandwidth unless all the devices are in the DCF-only mode of operation. This is true even when the BSS does not have any MMS.
  • an MMS wakes up and needs an association, it searches all the possible channels for a PC by sending its request and timing out in each channel before changing over to the next channel. This assures that an MMS will always find a PC, even if they are in different channels.
  • the PC recognizes the association request from an MMS, it authenticates the MMS and at the same time it starts negotiations with any BSS-group that may be operating in that channel. Once the PC obtains the duration for its own CFP, it sends the beacon in the channel at its TBTT.
  • the MMS requests the bandwidth, obtains connection with another MMS and starts using the channel. If the MMS that needs to be connected is in another channel, it is the responsibility of the PC to request the first MMS to remain quiet and search the other channels for the second MMS.
  • the PC achieves this by sending request signals addressed to the second MMS in each channel.
  • the PC requests the second MMS to move to the original channel of the PC's operation and establishes the connection in that channel.
  • the second situation requiring channel selection is when the PC or one of the MMSs experiences serious channel impairments despite higher degree of ECC.
  • Each MMS and the PC in the BSS measure the channel status in terms of packet error rates and packet loss rates that they are experiencing.
  • the MMSs send the measured channel status to the PC periodically. Using the channel status from all the MMS and the one measured locally, the PC decides to change the current channel and move the network operations to a better channel.
  • the PC decides to leave the current channel, it searches for another free channel. This is achieved by informing all the MMSs to remain quiet through a broadcast message and snooping other channels for operation of BSSs or for the stray energy measured in terms of CCA mechanisms. As all the MMSs are required to remain quiet due to the absence of the beacon from the associated PC, there will be a momentary pause in the network operation. If a free channel is found, the PC switches back to the original channel, broadcasts a change channel command to all the MMSs and expects acknowledgements back from each individual MMS. Each MMS changes channel only after it sends repeated acknowledgement messages to the change channel command from the PC.
  • the PC If an MMS does not respond, the PC, after attempting to reach it a predetermined number of times, decides that the MMS is unreachable and times out. Similarly, the MMS, after waiting for a predefined length of time, decides that the PC is unreachable and starts searching for the PC in other channels.
  • the PC changes channel after all the MMSs respond or after the time out condition is reached. Once in the new channel, the MMSs wait for the beacon from the PC to start the communications. To announce its presence in the new channel, the PC broadcasts a change channel message with the indication of the destination channel as the current channel and expects acknowledgement from each MMS. If an MMS does not respond within a predefined number of attempts, the PC decides that the MMS is disconnected. After identifying all the MMSs the PC starts the regular network operations. If a BSS is currently sharing bandwidth with other BSSs, the PC of the BSS that is changing the channel should inform the MC before moving the network operations over to a new channel.
  • the PC After deciding to change the channel, if a free channel is not found, the PC simply returns to the original channel and broadcasts change channel message with the current channel as the destination channel. After this it starts normal operation by sending out beacons and expecting the MMSs to communicate as before.
  • This scheme aims to achieve a "Share and Survive" policy by providing for the CFP operation of overlapping subnets in the same channel as shown in Figure 18.
  • the operation of overlapping subnets 180 in the same channel 182 is achieved by sharing the bandwidth among those subnets through appropriate negotiations.
  • the BSS-SID serves as the subnet index in this mode of operation.
  • the BSS-SID is used to achieve the slot synchronization among the transmissions of PCs of all the overlapping subnets.
  • the transmissions of each subnet with respect to the Master Coordinator are shown in Figure 19.
  • the coordinator of the first subnet occupying the channel also takes the responsibility of the Master Coordinator (MC) and assumes an all-zero BSS-SID.
  • Each subnet negotiates its contention free duration and an overall contention free period is formed starting from the beacon of the MC 201.
  • the other subnets are provided with network synchronization parameters such as BSS-wait-time and BSS-tx-time.
  • the wait times are always measured from the beacon from the Master Coordinator. This forms a two stage wait time, where each PC waits for a pre-negotiated duration of time from the MC's beacon and the client devices within a subnet wait for a pre-negotiated Tx-slot some length of time from the start of the individual CFPs 208.
  • the subnets need to negotiate (or expose) only the bandwidth required for the devices in the overlapping region. This includes both the TX and RX streams of those devices.
  • the rest of the individual CFPs for non-overlapping devices 210 need not be negotiated with other subnets. In essence, one can imagine a set of CFPs negotiated for all the devices in the overlap region 212 in all the subnets. Each subnet must have its own CFP 208 encompassing all the its allocated pieces. The negotiated piece of CFP for other subnets are strictly kept unallocated in the current subnet. This results in non-overlapped CFPs 212 for the devices in the overlapped region.
  • This section describes the operation of overlapping subnets when the PCs cannot receive from each other while at least one of the online clients can receive from both PCs.
  • the device that can receive from both the PCs assumes the responsibility of a proxy-point-coordinator and tunnels the negotiations between the two PCs. Any device that can hear two PCs (with all zero BSS-SID) can volunteer for this responsibility with its PC. If there is more than one device that is in the overlap region, the PC can choose one of those devices for this responsibility.
  • a proxy point coordinator (PPC) 214 essentially provides a tunnel for the communication between the Master Coordinator 216 and a PC 218 that is not able to receive from the MC.
  • the subnet sharing the channel with the assistance of the proxy coordinator 214 uses the beacon from the proxy-coordinator 204 as time reference. This result in marginally increased overhead on the channel bandwidth, but keeps a close time synchronization of transmissions among the channel sharing subnets.
  • a proxy coordinator wants to leave the subnet it does so only after informing both the Master-Coordinator and the subnet that it is currently servicing.
  • the Master Coordinator tries to shift the link to another device that can receive from both sides. If this is not possible, there is no overlapping region between the subnets and the subnets can form their own independent BSS using in the same channel without interference.
  • the management command channel is nothing but one or more management command frames sent by a device in its allocated transmission slot. If there are no commands to be sent in a slot, the device is free to use that bandwidth for any buffered data transmission. If there is a command received it is mandatory for the device to process that command and send out the response without delaying the command's transmission. There is no explicit ack for the command frames. Instead the reliability of the command transportation is build into the structure of command frames as explained later.
  • the command frames are always error protected using RS(255, 239) coding.
  • the broadcast MAC frames are not encrypted and the unicast command frames can be encrypted.
  • Command frames between the overlapping subnets must always be sent unencrypted and error protected using RS(255-239) coding.
  • the BSS-SID in the MAC header is used to distinguish the source of the command originator. These frames must have only the inter-subnet bandwidth-negotiation commands. They must not have any commands related to clients within a subnet.
  • the Null command shown in Figure 22, has no payload and has no payload length field.
  • the receiving device is expected to throw away all the NULL commands that are received in a command frame.
  • This command shown in Figure 23, is used to setup and tear down a stream connection between two devices in the network. There are several subcommands under this command and they are described in the following sections.
  • This subcommand is sent to all the devices that are currently connected in the network to synchronize their stream connections with the other devices. This is critical when a device gets disconnected and connects back within the timeout periods of other devices. The device might have lost all its stream connections while some devices in the network, not realizing of the disconnection still have them alive. This synchronization command brings them all to the same state of no streams with the current device. Hence, they all need to restart their stream connections with the current device.
  • the subcommand structure is shown in Figure 24.
  • the timeout period 240 indicates the time by when the response is expected. This provides some time for the device to clean up its stream list and send the response. 10.2.2 Restart All Stream Connections Ack
  • the devices that receive a Restart- All-Stream-Connections subcommand must send this subcommand as the acknowledgement.
  • the subcommand structure is the same shown in Figure 24 wherein the timeout period is ignored.
  • This subcommand indicates whether the request is for a transmit stream or receive stream or both. This subcommand also indicates the desired stream characteristics, which includes the stream QoS parameters.
  • the subcommand structure is shown in Figure 25.
  • the stream connection type 250 is one octet field containing two sub-fields.
  • the stream direction 251 (least significant 2 bits) indicates whether the stream connection is for a transmit-stream (1) or a receive-stream (2) or both (3).
  • the value '0' for this field is invalid.
  • the bi-directional stream request comes handy in one server and multiple client applications, where one server application can request bi-directional stream connection without an active client application at the destination device.
  • the multicast streaming request field 252 is a one bit field (bit b2) indicating a request to connect to an already established stream if there is a stream that is already present at the indicated LEP-ED 253. If there is no stream with the required LEP-ID, a new stream is created. By setting this bit high, it is possible to request to send one stream from a device to a group of devices in the same subnet. This group is the multicast group for that particular stream. If there is a stream that exists with the indicated LEP-ID, the source device gets a multicast stream permission from the PC and then only provides the stream parameters and stream index to the device that is trying to join the multicast stream group. Note that the stream direction must not be set to 'bidirectional' if the multicast stream request bit is set. The source device can also use the multicast request bit to invite a multicast stream connection to another device.
  • the Listen End-Point ED (LEP-ID) 253 indicates the destination end point to which the stream connection is intended.
  • the Requester End-Point ID (REP-ID) 254 indicates the end point identification at the requesting device.
  • the Requester End Point Information (REPI) 255 is a 4-octet field that is supplied by the agent requesting the stream connection. This field is passed unaltered to the agent at the destination device.
  • the Source-Sink parameters 256 include the stream index 146, security type 257 and the receive window size 358.
  • the source device 154 always issues the stream index 146.
  • the defined security types 257 are 0 for no security and the rest are reserved.
  • the receive window from the source device 154 is a request to the destination device 156. However the destination device makes the final decision on the receive window.
  • the stream QoS parameters 259 contain fields regarding bit-rates required 230- 232, acceptable latency 235/236, priority of the stream 237, error correction 238 and the retransmission requirements 239 of the stream. If the connection request is for a stream to be received, the initiating device can suggest these parameters. The source device makes the final decision on these parameters considering the request from the receiving device.
  • the instantaneous rate variation of the stream is characterized by the minimum 230, maximum 231 and average 232 rates in bytes/sec provided by the source device. Additionally the source device provides information such as maximum burst size 233 and average MAC frame size 234 to better characterize the streams behavior. This information can be used by the bandwidth request/allocation mechanism to better cope with the changes in the instantaneous rate of the stream.
  • the latency requirements of the stream are indicated through the duration between transmissions 235 and the maximum transmission delay variation 236.
  • the duration between transmissions 235 indicates the frequency at which the stream needs to be transmitted.
  • the maximum transmission delay variation 236 indicates the jitter allowed around the duration between transmissions without violating the latency requirements of the stream.
  • the priority 237 is a 3 bit field allowing up to 8 priorities bot only four priorities are defined.
  • the ECC type 238 is an 8 bit field that allows up to 256 types of error protection/correction schemes. The following values of ECC types are defined in the present scheme:
  • the size of the first block in every MAC frame is always fixed to RS(255, 239).
  • the maximum retransmission duration 239 indicates the time over which the retransmission of the MAC frame is meaningless.
  • the value '0' in this field means no retransmission is required and all-one value means retransmission forever to provide completely reliable transmission of the stream.
  • the subcommand structure to establish a TX-stream and an RX-srream at the same time is shown in Figure26.
  • the stream direction 251 for this structure should be set to 3. Though this will eventually result in establishing two unidirectional streams, this is useful when both the streams have to be established at the same time with bandwidth allocated to them at the same time.
  • the stream connection accept message is the acceptance acknowledgement from the destination device 156.
  • the subcommand structure shown in Figure 27 is similar to that for a Stream Connection request, except for the addition of an acceptor end point ID (AEP-ID) 270.
  • AEP-ID acceptor end point ID
  • This ID similar to REP-ID, is allocated dynamically by the accepting device and uniquely identifies the stream connected at its end.
  • the REP-ID remains as the end point ID for the stream at the device that initiated the request for stream connection. Additionally the accepting device sends its own information embedded in AEPI field 272.
  • This subcommand is sent only if the LEP-ID is valid at the accepting device and a stream connection at that end point is acceptable.
  • the stream parameters should be same as those dictated by the source device 154.
  • the stream index 146 in this subcommand should be a valid, unique index for the stream that is being established.
  • the stream connection negotiate message is used by the destination device to suggest its own stream parameters.
  • the subcommand structure is also shown in Figure 27 since it is similar to that for the Stream Connection request message except for the addition of an acceptor end point ID (AEP-ID) 270 making it identical to the stream connection accept command.
  • AEP-ID acceptor end point ID
  • This ID similar to REP-ID, is allocated dynamically by the accepting device and uniquely identifies the stream connected at its end.
  • the REP- ID remains as the end point ID for the stream at the device that initiated the request for stream connection. Additionally, the accepting device sends its own information embedded in AEPI field.
  • This subcommand is transmitted if the LEP-ED is valid at the accepting device and a stream connection at that end point is acceptable. If certain parameters in the stream connection request are not acceptable to the current device, in contrast with the stream connection accept command, here the current device can insert its acceptable values in the corresponding fields of this subcommand. The requesting device should consider these parameters, though the decision of the source device is final. Upon such a decision, the requesting device should re-send its parameters.
  • This subcommand can also be used to negotiate a different set of stream parameters even after the stream connection is established and during the stream communication. At any time if the parameters cannot be negotiated, either of the devices can reject the connection. If they are negotiated, a stream connection accept is expected from one of the devices as the final subcommand of negotiation session.
  • the stream index in this subcommand should be a valid, unique index for the stream that is being negotiated.
  • the source device is responsible for negotiating the terms with all the devices that are currently participating in the multicast stream group.
  • the stream connection reject is transmitted during the connection establishment process if the stream parameters are not acceptable.
  • the subcommand structure is shown in Figure 28.
  • the RxEP-ID 280 is the end point ID for the stream at the device that received the request for stream connection.
  • the SEP-ED 282 is the end point ID for the same stream(s) at the device that sent the stream connection. The stream index is ignored in this subcommand.
  • both the devices move on to the final stage of connection establishment. This stage involves obtaining the channel bandwidth for the connection. If the source device does not already have the bandwidth required for the stream, it asks the PC for the new bandwidth allocation using the DBM mechanism. Once such an allocation is made, the source device sends the stream-connection-complete subcommand to the other device and starts sending out the stream MAC frames. If the bandwidth allocation is unsuccessful, a stream connection reject subcommand is sent from the source device. Note that for a bi-directional connection, each device should carry out the bandwidth negotiation for the stream they are sourcing.
  • the stream disconnect message may be sent when an already established stream needs to be disconnected.
  • the subcommand structure is shown in Figure 29.
  • the RxEP-ID 280 is the end point ID for the stream at the device that receives the request for stream disconnection.
  • the SEP-ID 282 is the end point ID for the same srream(s) at the device that sent the stream disconnection subcommand.
  • the stream connections, transmit and/or receive, associated with the RxEP-ID and SEP-ID should be disconnected.
  • the stream index in this subcommand should be a valid, unique index for the stream that is being disconnected.
  • the defined reason codes are same as those listed in the section above for stream connection reject subcommand.
  • the stream disconnect ack message may be sent in reply to a stream connection disconnect subcommand.
  • the subcommand structure is also shown in Figure 29.
  • the RxEP-ID 280 is the end point ID for the stream at the device that receives the request for stream disconnection.
  • the SEP-ID 282 is the end point ID for the same stream(s) at the device that sent the stream disconnection subcommand. Whenever this subcommand is received the stream connections, transmit and/or receive, associated with the RxEP-ID and SEP-ID should be disconnected.
  • the stream index in this subcommand should be a valid, unique index for the stream that is being disconnected.
  • the source device sends this subcommand to the PC to obtain the authorization for a device that is requesting the stream.
  • the same subcommand is applicable to allow a device to join a multicast stream group.
  • the subcommand structure is shown in Figure 30.
  • RxAddr 300 is the address of the device receiving the multicast stream connection.
  • the source address can be obtained form the header of the frame.
  • the authorization request should be performed for one stream at a time. Hence the 'bidirectional' stream indication need not be used in this subcommand.
  • the subcommand payload is same as that shown in Figure 30.
  • this command is sent by a PC, it indicates that the PC has authorized the stream consumption and has admitted the QoS for the stream.
  • a DB-Grant command with all the required parameters for network synchronization, is expected from the PC before the source device can start transmitting the stream.
  • the subcommand payload is same as that shown in Figure 30. 10.3 Dynamic Bandwidth Management (DBM)
  • the client uses this subcommand to negotiate new bandwidth and latency parameters with the PC.
  • the payload structure of this subcommand is shown in Figure 32.
  • All the bandwidth requests 321 are in bytes per second and all the latency requests 322 are in TUs (1024 microsecs).
  • a device can request bandwidths at different latencies. For example, if a device is streaming voice and audio/video, it can request a voice bandwidth with a lower latency and an audio/video bandwidth with a larger latency.
  • the requests 320 are chained as shown in the Figure 32 and the total of all such requests 324 is sent as the first 16 octets of the subcommand payload.
  • the client device should accumulate all the individual stream requirements into groups of latency requests and send the same in the format shown in Figure 32.
  • the PC may attempt to allocate all the bandwidth at the requested latency in the order of stream priority.
  • a PC uses this subcommand to acknowledge the DB-Req subcommand from the client.
  • the payload structure is same as that for the DB-Req shown in Figure 32.
  • This subcommand does NOT mean that the requested bandwidth is allocated, but only means that the PC has received the request and is processing that subcommand.
  • the PC uses this subcommand to send the finalized DB -parameters to the client.
  • a payload structure is shown in Figure 33. All the parameters used in the section for network synchronization are made available to the client by the PC in this subcommand.
  • the network frame size 330 is indicated in TU (1024 micro seconds).
  • the Effective network frame index (ENFI) offset 331 indicates the relative network frame index from which time the Stream Management parameters should be used.
  • An all-one value of ENFI indicates that the client has an option to accept the BW and send DB- Grant-Ack or send a new DB-Req for negotiation.
  • the PC makes the final decision and sends the DB-Grant with a valid ENFI to force the decision on the client.
  • the client has the option of disconnecting one or more streams if BW/latency is not acceptable.
  • the CTP 332, with the minimum value of one second, in the DB-Grant subcommand supercedes all the other CTPs.
  • the transmission wait time 333 and the slot time 334 in the Network synchronization parameter 335 is indicated in microseconds.
  • the number of tx-slots before the current tx-slot 336 includes any previous transmission slots by the current device in the same network frame.
  • the PTx-Addr field 337 indicates the address of the device that precedes the current device in a transmission list. This address can be a broadcast address indicating that the PC does not allow the current device to take over the channel when the previous device finishes early.
  • the Tx-Obs field 338 indicates the relative time duration from a beacon for which the device is not allowed to listen for the last frame transmission from a previous device. When there are multiple transmission allowed for a device within a network frame, the devices starting after this device are limited in their time window of observation using this field.
  • Dynamic Bandwidth Grant Ack has the same payload as the DB-Grant subcommand ( Figure 33).
  • the client Upon receiving the DB-Grant subcommand, the client is expected to send the parameters back to the PC in the ack subcommand to indicate its acceptance of the parameters.
  • the ENFI offset 331 in the DB-Grant-ack subcommand is ignored at the PC.
  • the Remain-Quiet command shown in Figure 34, is sent from the PC node informing all clients to remain quiet until it can check the other channel and come back.
  • the client is expected to respond by sending back a Remain Quiet Ack message.
  • the time out field 342 indicates the maximum time period through which the client must wait. If the PC did not come back and resume the operation either through change channel command or through a beacon, the client disconnects itself and searches for the PC.
  • the PC When the PC decides that another channel is better than the current channel, it can use Change Channel command, shown in Figure 35, to inform all the clients to switch channels.
  • the time out field 352 indicates the maximum time period within which the client must switch channels and wait for the PC in the new channel. If the client does not send any frame after the beacon from the PC within that time, the client is declared disconnected and is required to associate again. Similarly, if the client does not receive a beacon from the PC within the specified timeout period, it disconnects and searches for the PC.
  • a Channel Status command may be sent at a regular interval by the clients to inform the PC node regarding their channel status.
  • the channel status bytes form the payload of the MAC frame.
  • a command structure is shown in Figure 36.
  • the channel statistics are measured separately for each of the devices that the current device is receiving data from.
  • the address of the client (or BSS-ID) for which the channel statistics is measured may be provided in the command sent to the PC as shown in Figure 36.
  • the Tx-Address 362 may be a broadcast address to indicate an aggregate channel statistics.
  • the duration of connection 363 is provided to the PC in order to keep track of connection times between devices for proxy service purposes. If TX-Address is set to all-ones, then the address indicated in the TX- Address/TX-BSS-ID is actually another BSS. That is, the current block payload is for another subnet whose frames are received by the sending device.
  • the Transmit MAC frame Count in measurement window (TPCW) 364 is the total count of all the MAC frames transmitted by the client device within the measurement window.
  • the Receive MAC-frame Count in Measurement Window (RPCW) 365 is the total count of all the MAC-frames received by the client device within the measurement window.
  • the total number of MAC frames that were received in error within the measurement window is represented by the Receive MAC-frame Error Count (RPECW) 366.
  • the MAC frame loss count (PLCW) 367 represents the total number of MAC frames that were not received (requested retransmission) within the measurement window.
  • the Channel measurement window (CMW) 368 field indicates the duration of the time, in TU (1024 microseconds), during which the measurement was conducted. The client device selects this duration, which is used by the PC. The device may restart the measurements in the new time window.
  • APCs use the PC Redundancy command, shown in Figure 37, to negotiate for the responsibility of the PC in the subnet. Additionally, the PC uses this command to hand over its responsibility to an APC when it shuts off or becomes overloaded.
  • the subcommands used in this process are discussed in the sections below.
  • a PCR Negotiation subcommand is used when the PC is absent and a subnet needs to be established. Multiple APCs in a subnet can send this command and negotiate for taking over the responsibility of the PC in the subnet.
  • a command payload structure is described in Table 1 and is shown in Figure 38.
  • the Max-PHY-Tx-range 382 of the command indicates the free-air distance range (in meters) that is possible for the device.
  • the command's Max External connection field 383 represents the number of physical (wired/wireless) ports that are available on the device for connections outside the current subnet.
  • the Active Ext connection field 384 indicates the number of currently active physical (wired/wireless) ports other than the current subnet and the Max PHY rate 385 indicates the maximum possible bit rate in Mbits/sec at the PHY layer of the device.
  • An APC device uses this command to pullout of multi-device negotiation session if it has received a PCR-negotiation subcommand from another device that is better suited for the operation.
  • An example of a payload structure is shown in Figure 38.
  • a device decides that it is better suited to perform the PC function than the other devices in the subnet, then it takes over the PC responsibility.
  • This command is sent out to inform other currently negotiating devices about the assumption of the PC responsibility.
  • a sample command payload structure is also the one shown in Figure 38. If there are multiple devices sending this command, then the effect of this command is similar to the effect of a PCR negotiation command.
  • the devices constantly compare the contents of this subcommand transmitted by other devices. If another device is better suited as a PC, the current APC sends out the PCR pullout subcommand.
  • This command is used to provide the services of PPC in a subnet as discussed in section 6.2.
  • the subcommands are discussed in the following sections.
  • a client can use a PPC Service Request sub-command, shown in Figure 40, to request the service of a PPC upon recognizing that a link between itself and another device, including the PC, is too poor for proper communication.
  • This sub-command is always broadcasted.
  • the requesting client should mention all the devices to which this sub-command applies, in addition to the transmission requirements for a corresponding link. If the client requests this service for all the links, then it may mention a broadcast address and an overall QoS request, instead of mentioning all the devices in the subnet.
  • a device may volunteer to be a PPC when it recognizes a request for such a service.
  • a device may volunteer to provide a proxy service between two specific devices by specifying their addresses in Device Addr-1 411 and in Device Addr-2412 of Figure 41.
  • a device may volunteer to provide the proxy service between a specific device and the rest of the network as seen by the volunteering device. This is indicated to the PC by using a broadcast address as the second address 412.
  • the PLR-Measured field 414 indicates the channel condition between the volunteering device and the device whose address precedes this field.
  • the PLR is indicated as average number of MAC frames lost in every 10,000 MAC frames.
  • the PC makes the final selection among the volunteers.
  • a device may volunteer for PPC service by embedding the incoming proxy-scv-reg MAC-frame in the subcommand 422 of Figure 42, and sending it to the PC.
  • the PC responds back using the same subcommand with the payload being the response MAC frame for the new device.
  • the volunteering device simply transmits the embedded MAC frame as a new MAC frame by itself. After the connection is established, the PC sends PPC-permission-grant and confirms the PPC role of the volunteering device between the new device and the PC.
  • the subcommand structure is illustrated in Figure 43.
  • the ENFI 331 is the Effective Network Frame Index and is discussed in section 10.3.3.
  • the rest of the fields contain the addresses of the devices in the order of their appearance in the chain. Hence the first and the last address indicate the devices that are serviced under this proxy service chain.
  • the PC expects an ack from each of the devices listed in this subcommand.
  • This command also acts as the breaking of the previous link between device- 1 and device-2. In this case, the PC expects an ack from the PPC that was present in the immediately previous arrangement that is removed from the current arrangement.
  • the PC may choose a client to perform PPC operations. If the chosen device has not volunteered and it does not want the responsibility it can reject such a selection using this subcommand. This allows the devices with power-save mode enabled not to get involved in the proxy service.
  • the subcommand structure is shown in Figure 43.
  • the ENFI field 331 from PPC Permission Grant command is decremented and sent in the acknowledgment.
  • the current PPC must use the same subcommand if it decides to relieve itself from the responsibility of being a PPC.
  • the PC is expected to find an alternative or tear down the entire PPC-chain.
  • the PC may break the proxy service link between two devices. Such a decision of the PC is broadcasted in this subcommand.
  • a subcommand structure is shown in Figure 44.
  • the reason codes 442 are;
  • This subcommand is used to request a permission from the PC for providing proxy services between overlapping subnets for bandwidth sharing.
  • the OSB commands are discussed in section 10.9.
  • a volunteering client can use this subcommand to volunteer for the PC's responsibility.
  • a subcommand structure is shown in Figure 45. This command is sent upon the reception of OSB-Req and when PC is not responding to it. 10.8.10PPC-OSB Provider Accept
  • the PC may choose one out of several volunteers and send this subcommand to permit that client to be a PC between the two subnets.
  • the client compares the payload of the subcommand with its own and sends an acknowledgment to the PC.
  • a subcommand structure is shown in Figure 45.
  • the PC can also use the same subcommand to appoint a device to be a PPC for bandwidth sharing between subnets, even though the device has not volunteered to provide the service.
  • the PC may reject the volunteer using this subcommand shown in Figure 45. No acknowledgment is expected for this subcommand.
  • the current PC uses the same subcommand if it decides to relieve itself from PC responsibility. This subcommand may be sent from the client to the PC indicating that the current device is rejecting the responsibility of PPC-OSB.
  • both the PC and the PPC use PPC-OSB subcommand (shown in Figure 4 ) to tunnel the OSB commands between the two subnets.
  • the PC is expected to send out the payload of this subcommand as a separate MAC frame.
  • the PPC also reads and analyzes the communication between the two PCs to keep track of bandwidth negotiation conditions.
  • the PPC also provides beacon service as time reference for the PC of the other subnet.
  • the current PPC sends this subcommand to relieve itself from the responsibilities before going into sleep mode or shutting off.
  • a command payload is shown in Figure 47. 10.8.15PPC-OSB Relieve Request Ack
  • the PC sends this acknowledgment back to relieve the current PPC-OSB from its proxy responsibilities.
  • the PC finds another device for PPC responsibility or directly communicates the OSB commands.
  • a sample command payload is shown in Figure 47.
  • this sub-command sent by itself as a MAC-frame, includes four subcommands that are used for dynamic (overlapping) bandwidth negotiation among the subnets.
  • the command structure is shown in Figure 48. The subcommands are discussed in the following sections.
  • the PC in the new subnet uses this subcommand to negotiate bandwidth with the Master coordinator.
  • the subnets that are already sharing bandwidth in the same channel may also use the same command to alter their requested bandwidth.
  • a sample payload structure of this subcommand is shown in Figure 49.
  • All the bandwidth requests 492 are presented in bytes per second and all the network frame duration requests 494 are in TUs (1024 microsecs).
  • the Master Coordinator decides the allocated bandwidth and the network frame duration based on requests from all the subnets currently sharing the channel.
  • the other subnets have the option of accepting MC's decision or moving over to some other channel.
  • Zero bandwidth request means the current subnet does not wish to share the channel anymore either because it moves over to the new channel or because it shuts down.
  • the MC uses this subcommand to acknowledge the OSB-Req subcommand from other subnets.
  • a payload structure is shown in Figure 49. This subcommand does not represent bandwidth allocation, but only means that the MC has received the request and is processing the subcommand.
  • the MC uses this subcommand to send the finalized bandwidth parameters to individual coordinators.
  • a payload structure is shown in Figure 50. All the parameters used in section 7 for network synchronization are made available to the client by the PC in this subcommand.
  • the network frame size 502 is indicated in a TU (1024 microseconds) field.
  • the Effective network frame index (ENFI) 504 indicates the relative network frame index from which time the Stream Management parameters should be used.
  • An all-one value of ENFI indicates that the subnet has an option to accept the offered bandwidth and send an OSB-Ack message or send a new OSB-Req for negotiation.
  • the MC makes the final decision on bandwidth allocation and sends the OSB-grant message with a valid ENFI to force the decision on the subnet.
  • the subnet has the option of disconnecting if the bandwidth allocation is not acceptable.
  • the MC may periodically resend the OSB-grant message and expect an ack in return. If an ack does not arrive after a predetermined number of attempts, the MC should disconnect the subnet from its group. The bandwidth that was previously allocated to the outgoing subnet may then be granted to other subnets, if required.
  • the transmission wait time 506 and the slot time 508 in the network synchronization parameter 505 is indicated in microseconds.
  • the OSB-TP 503 in this subcommand transmitted from the MC overrides that specified in all the other subcommands from other PCs. There may be more than one set of parameters sent to any one subnet in this subcommand to accommodate multiple latency requirements of the subnet.
  • the OSB-ack subcommand has the same payload format as the OSB-Grant subcommand.
  • the subnet receiving the OSB-grant subcommand is expected to send the agreements back to the MAC in the ack subcommand to indicate its acceptance of the agreements.
  • the ENFI offset 504 in the OSB-ack subcommand is ignored by the MC.
  • the Master Coordinator broadcasts this subcommand to relieve itself from MC responsibilities.
  • the PC with the next lowest BSS-SID should take over the responsibility of the MC.
  • the time out period indicates the time within which a response is expected.
  • the payload for this command is shown in Figure 51. 10.9.6 Master Coordinator Relieve Request Ack
  • the PC with the next lowest BSS- SID should take over the responsibility of the MC and broadcast this subcommand as the ack. Once that occurs, all the devices in its network should change their BSS-SID to zero.
  • the time out period 512 in this subcommand indicates the time taken for the subnet to synchronize, during which time no OSB requests are entertained. However, the new MC continues to provide beacon services for both the current group of subnets and also for its own subnet separately.
  • the PC in each subnet must use this command to communicate the BSS-SID 522 that needs to be used by the clients. Note that the PC should broadcast this command whenever there is a change in BSS-SID.
  • the payload for this command is shown in Figure 52.
  • the retransmission command has three subcommands that are described in the following sections.
  • the command structure is shown in Figure 53.
  • the retransmission command may be transmitted from one specific device to another specific device in a command frame.
  • the address of the source and the destination devices are available from the command frame header or the sub-header if it is a command frame in broadcast mode.
  • This subcommand conveys the ack-window from the destination device to the source device.
  • the payload for this command is shown in Figure 54.
  • Ack-win Begin Sequence number 543 indicates the stream sequence number of the last nacked MAC frame.
  • the Ack-win End Sequence number 544 indicates the stream sequence number of the most recently received MAC frame.
  • the MAC-frame-Rx-Status 545 is a bitmap indicating the status of received MAC-frames from the Ack-Win Begin Sequence number 543 to the Ack-Win End Sequence number 544.
  • a bit value of '0' indicates a positive ACK and '1' indicates a negative ACK (NAck).
  • NAck negative ACK
  • the receive-status of the most recently received MAC frame, whose sequence number is Ack-win-End-Sequence- number 544, is indicated in the last valid bit of the MAC frame-Rx-Status field 545. Note that this need not be the most significant bit of the MAC frame-Rx-Status field 545.
  • the length of the MAC frame-Rx-Status field 545 may be computed as the difference between the Ack-Win-End-Sequence-number 544 and Ack-Win-Begin- Sequence-number 543, wrapped around if needed, and adjusted to the next byte boundary. Hence there could be some invalid bits at the most significant side of the MAC frame-Rx-Status 545 after the bit representing the status for the MAC frame whose sequence number is Ack-Win-End-Sequence-number 544.
  • This subcommand is transmitted by a source device requesting the receiver to ignore the MAC-frames up to the specified sequence number 554 in a stream identified by its stream index 552. This is required when the source device fails to receive an ack from the receiver and the maximum tolerable delay for that MAC frame has expired.
  • the subcommand structure is shown in Figure 55.
  • the destination device sends this subcommand as an acknowledgement to the reception of the Retransmission-Fail subcommand from the source device.
  • a sample subcommand structure is shown in Figure 55.
  • This subcommand may be sent by the source device to synchronize the sequence number 564 with the destination device. On receiving this subcommand, the destination device should update its state for the stream to expect this sequence number next.
  • the subcommand structure is same as that shown in Figure 56.
  • the destination device sends this subcommand as an acknowledgement to the reception of the Retransmission resync subcommand from the source device.
  • the subcommand structure is same as that shown in Figure 56. Thus a set of Qos extensions to support multimedia applications over 802.11 LANs has been described.

Abstract

Cette invention concerne un protocole de mise en réseau comprenant des définitions des améliorations apportées à la qualité du service dans le but de fournir des connexions fiables pour des trains de données multimédia dans des réseaux d'ordinateurs sans fil. Ces améliorations peuvent être mises en oeuvre sous forme d'extensions d'en-tête de paquets tel qu'un champ de commande multimédia composé de divers champs secondaires.
EP01937456A 2000-07-13 2001-05-16 Qualite d'extensions de service pour applications multimedia dans un reseau d'ordinateurs sans fil Withdrawn EP1302048A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/615,573 US6934752B1 (en) 2000-03-23 2000-07-13 Quality of service extensions for multimedia applications in wireless computer networks
US615573 2000-07-13
PCT/US2001/015851 WO2002006986A2 (fr) 2000-07-13 2001-05-16 Qualite d'extensions de service pour applications multimedia dans un reseau d'ordinateurs sans fil

Publications (1)

Publication Number Publication Date
EP1302048A2 true EP1302048A2 (fr) 2003-04-16

Family

ID=24465976

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01937456A Withdrawn EP1302048A2 (fr) 2000-07-13 2001-05-16 Qualite d'extensions de service pour applications multimedia dans un reseau d'ordinateurs sans fil

Country Status (3)

Country Link
EP (1) EP1302048A2 (fr)
AU (1) AU2001263194A1 (fr)
WO (1) WO2002006986A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6165604A (en) * 1997-07-02 2000-12-26 The Dow Chemical Company Fiber-reinforced composite and method of making same

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100450795B1 (ko) 2001-12-12 2004-10-01 삼성전자주식회사 무선 독립망에서 혼합형 자원 공유 방법과 이를 위한 단말및 데이타 포맷
USRE43383E1 (en) 2001-12-12 2012-05-15 Samsung Electronics Co., Ltd. Method for sharing hybrid resources in a wireless independent network, a station for the method, and a data format for the method and the station
ATE514297T1 (de) * 2002-03-08 2011-07-15 Koninkl Philips Electronics Nv Verfahren und system zur bereitstellung eines einzigen ruhestellungs-/messanforderungselements für vereinte kanäle in einem drahtlosen lokalen netzwerk gemäss 802.11
US7756090B2 (en) * 2002-03-12 2010-07-13 Koninklijke Philips Electronics N.V. System and method for performing fast channel switching in a wireless medium
EP1355450B1 (fr) * 2002-04-10 2006-10-25 Lucent Technologies Inc. Réduction des effects de chevauchement des canaux dans des réseaux locaux sans fils utilisant un protocol central d'accès
US8762551B2 (en) * 2002-07-30 2014-06-24 Intel Corporation Point coordinator delegation in a wireless network
US7414986B2 (en) 2002-08-02 2008-08-19 Sharp Laboratories Of America, Inc. System and method for controlling wireless LAN bandwidth allocation
GB2392582A (en) * 2002-08-30 2004-03-03 Hutchison Whampoa Three G Ip Implementation of streaming in a umts network which enables utran to enhance the experience of users and save resources
US7995583B2 (en) 2002-09-10 2011-08-09 Koninklijke Philips Electronics N.V. Apparatus and method for announcing a pending QoS service schedule to a wireless station
AU2003284317A1 (en) * 2002-10-21 2004-05-13 Intellon Corporation Contention-free access intervals on a csma network
KR100597396B1 (ko) * 2003-06-04 2006-07-06 삼성전자주식회사 멀티 프로토콜 데이터 프레임 송수신 방법 및 장치
JP3996096B2 (ja) * 2003-06-23 2007-10-24 東京電力株式会社 無線ｌａｎ通信システム
US8090857B2 (en) 2003-11-24 2012-01-03 Qualcomm Atheros, Inc. Medium access control layer that encapsulates data from a plurality of received data units into a plurality of independently transmittable blocks
CN100337436C (zh) * 2004-08-29 2007-09-12 华为技术有限公司 一种无线网络控制器配置信道带宽的方法
US8175190B2 (en) 2005-07-27 2012-05-08 Qualcomm Atheros, Inc. Managing spectra of modulated signals in a communication network
EP2159966A1 (fr) 2007-05-10 2010-03-03 Intellon Corporation Gestion d'un accès réparti à un support partagé
US8638653B2 (en) 2008-03-27 2014-01-28 Intel Corporation Adaptive transmissions for optimized application delivery in wireless networks
JP2011101162A (ja) * 2009-11-05 2011-05-19 Renesas Electronics Corp データ処理装置及び通信システム
US8660013B2 (en) 2010-04-12 2014-02-25 Qualcomm Incorporated Detecting delimiters for low-overhead communication in a network

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001071981A2 (fr) * 2000-03-23 2001-09-27 Sharewave, Inc. Extensions multimedias pour reseaux locaux sans fil
WO2002005492A1 (fr) * 2000-07-12 2002-01-17 Sharewave, Inc. Flux multimedia et qualite de services dans des reseaux familiaux sans fil

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001071981A2 (fr) * 2000-03-23 2001-09-27 Sharewave, Inc. Extensions multimedias pour reseaux locaux sans fil
WO2002005492A1 (fr) * 2000-07-12 2002-01-17 Sharewave, Inc. Flux multimedia et qualite de services dans des reseaux familiaux sans fil

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GUBBI R: "Isochronous services in home multimedia networks", COMMUNICATIONS, COMPUTERS AND SIGNAL PROCESSING, 1999 IEEE PACIFIC RIM CONFERENCE, 22 August 1999 (1999-08-22) - 24 August 1999 (1999-08-24), VICTORIA, BC, CANADA, XP010356692 *
GUBBI R: "Multimedia streams and quality of service in the next generation wireless home networks", MOBILE MULTIMEDIA COMMUNICATIONS, 1999. (MOMUC '99), 15 November 1999 (1999-11-15) - 17 November 1999 (1999-11-17), SAN DIEGO, XP010370706 *
SHAREWAVE: "whitecap? network protocols", ONLINE, 18 April 2001 (2001-04-18), XP002457212, Retrieved from the Internet <URL:http://web.archive.org/web/20010418131137/http://www.sharewave.com/Products/WhiteCap/whitecap.html> [retrieved on 20071031] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6165604A (en) * 1997-07-02 2000-12-26 The Dow Chemical Company Fiber-reinforced composite and method of making same

Also Published As

Publication number Publication date
WO2002006986A3 (fr) 2002-06-13
WO2002006986A2 (fr) 2002-01-24
AU2001263194A1 (en) 2002-01-30

Similar Documents

Publication Publication Date Title
US6934752B1 (en) Quality of service extensions for multimedia applications in wireless computer networks
US6865609B1 (en) Multimedia extensions for wireless local area network
US7093015B2 (en) Method and apparatus for accessing a wireless computer network communication channel by accessing quiet intervals in network frames
US7251231B2 (en) Method and apparatus for controlling communication within a computer network
US6754176B1 (en) Scheme for managing overlapping wireless computer networks
EP1302048A2 (fr) Qualite d&#39;extensions de service pour applications multimedia dans un reseau d&#39;ordinateurs sans fil
US20030231621A1 (en) Dynamic communication channel switching for computer networks
US20040081089A1 (en) Transmitting data on scheduled channels in a centralized network
US20040022222A1 (en) Wireless metropolitan area network system and method
JP4734227B2 (ja) Ｗｌａｎにおける帯域プロビジョニング方法及び装置
JP2008252925A (ja) 複数の局を含むネットワークの通信チャネルにアクセスする方法
WO2001071981A2 (fr) Extensions multimedias pour reseaux locaux sans fil
US8046484B2 (en) Transmitting data across a contention channel in a centralized network
US7653012B2 (en) Relay transmission of data in a centralized network
WO2002005492A1 (fr) Flux multimedia et qualite de services dans des reseaux familiaux sans fil
US8468252B2 (en) Selecting optimal transmission in a centralized network
US7324544B1 (en) Network slot synchronization scheme for a computer network communication channel
CA2379844A1 (fr) Structure de synchronisation de creneaux temporels de reseau pour canal de communication de reseau informatique
WO2002089416A2 (fr) Evitement de collision dans des reseaux de communication
Gubbi Isochronous services in home multimedia networks
EP1112643A1 (fr) Architecture hierarchisee de reseau informatique
TW200934107A (en) Bi-directional amplifier for data over coax applications
EP1254538A2 (fr) Gestion de connexion de flux dans des reseaux informatiques sans fil

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030206

AK Designated contracting states

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

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20071127

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20111201