Patent Application
20080063000
The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with the drawings in which:
Some portions of the following description relate to wireless ultra wide band networks that utilize a distributed media access control scheme. In these networks there is no central media access controller, but rather various devices of the network participate in determining how to share a common wireless medium. It is noted that according to various embodiments of the invention the disclosed methods and devices can be applied in networks that utilize a distributed media access control scheme but differ from ultra wide band wireless networks. It is further noted that according to some embodiments of the invention networks other than ultra wide band network can apply some of the suggested methods.
Various operations such as transmissions utilize the distributed media access control scheme in the sense that the access to a shared medium is governed by a distributed media access control scheme.
Some embodiments of the invention provide an ultra wide band wireless medium access control method and a device capable of performing ultra wide band wireless medium access control schemes.
Network 9 includes ultra wideband (UWB) wireless devices 10, 12, 14, 16, 24 and 26, bridges 100 and 106, remote bridges 102 and 104 and wired devices 18, 20 and 22. A remote bridge is connected to another remote bridge via wireless connection. Typically, a remote bridge can also have “regular” bridge capabilities that enable it to be connected to other devices (as well as bridges) via wired connections. WUB wireless devices 10-16 can wirelessly communicate with each other and can also communicate with bridge 100. WUB wireless devices 24 and 26 can wirelessly communicate with each other and can also communicate with bridge 106. Remote bridges 104 and 106 can wirelessly communicate with each other. Remote bridge 102 and bridge 100 can communicate, via wired link or network, with each other and with devices 18 and 20. A single device can have both remote bridge and bridge capabilities. For simplicity of explanation only the remote bridge is illustrated. Such a device can communicate over wired links with other devices or bridges and also wirelessly communicate with other remote bridges and devices
Conveniently, each one of bridge 100, bridge 106 can reserve one or more DRP timeslots for downstream transmission of information to a UWB device also referred to as WiNet device), wherein the UWB device triggers this reservation.
Conveniently, a UWB wireless device such as device 10 can determine transmission parameters of a downstream transmission from bridge 100 towards device 10 and then send to bridge 100 a request to allocate one or more timeslots for that transmission. Bridge 100 and devices 10-16 can participate in a distributed MAC scheme for determining the utilization of the wireless medium over which the devices and bridge communicate. Various distributed MAC schemes as well as other UWB techniques that can be implemented by devices 10-16 are illustrated in the following U.S. patent applications all being incorporated herein by reference: U.S. patent application Ser. No. 11/043,279 titled “Method and devices for multicasting information over a network that applies a distributed media access control scheme”; U.S. patent application Ser. No. 11/043,476 titled “Methods and devices for expanding the range of a network”; U.S. patent application Ser. No. 11/043,457 titled “A device and method for mapping information streams to MAC”; U.S. patent application Ser. No. 11/043,646 titled “Ultra wideband wireless medium access control method and a device for applying an ultra wideband wireless medium access control scheme”; U.S. patent application Ser. No. 11/043,456 titled “Method and device for transmission and reception over a distributed media access control network” and PCT patent application serial number PCT/IL2005/000021 titled “Distributed and centralized media access control device and method”.
Device 10 includes controller 11, receiver 13 and transmitter 15. Conveniently, many components of transmitter 15 and receiver 13 are shared, but this is not necessarily so. Controller 11 is connected to receiver 13 and transmitter 15 and can control their operation, but this is not necessarily so.
Controller 11 is adapted to determine expected downstream transmission parameters. These parameters can relate to expected quality of service level associated with the transmission. These expected downstream transmission parameters can include, for example, transmission parameters that comprise filtering parameters for filtering downstream information to be provided to the device. These filtering parameters can include (i) multiple filter parameters defining multiple filters, (ii) filter length, (iii) location of filtered field in a frame, (iv) expected value of filtered field and (v) filter mask value.
Conveniently, controller 11 is adapted to convert high communication layer quality of service characteristics to the expected media access control downstream transmission parameters. These high communication layers can include layer three, layer four and even higher communication layers.
Conveniently, using bridge media access control downstream transmission parameters to bridge 100 greatly simplifies bridge 100 that is not required to manage transmission parameters of higher communication protocols, especially in an environment where different device can use different higher layer communication protocols.
Device 10 is adapted to request a bridge to allocate multiple downstream timeslots in response to the expected downstream transmission parameters. The request can be prepared by controller 11 and transmitted by transmitter 15. It is noted that a bridge can be requested to reserve bandwidth by providing quality of service characteristics or by indicating which DRP slot reservations are required.
Receiver 13 is adapted to receive downstream timeslot reservation information indicating of downstream timeslots the bridge assigned for a transmission of downstream information to the device as a response to the request made by the device, and to receive downstream information during the assigned downstream timeslots.
Receive downstream timeslot reservation information can be provided to controller 11. The received downstream information during the assigned downstream timeslots can be processed by controller 11, but this is not necessarily so.
Conveniently, a request to receive bandwidth allocation can be sent if the bridge can service the request. Thus, device 10 can generate the request if it receives, from the bridge, bridge capability indication indicating that the bridge is capable of allocating downstream timeslot in response to a request from the device.
Bridge 100 includes controller 111, receiver 113 and transmitter 115. Conveniently, many components of transmitter 115 and receiver 113 are shared, but this is not necessarily so. Controller 111 is connected to receiver 113 and transmitter 115 and can control their operation, but this is not necessarily so.
Receiver 113 is adapted to receive a request to allocate multiple downstream timeslots for downstream transmission from the bridge to the device that is characterized by expected downstream transmission parameters. The downstream transmission parameters can relate to various layers including but not limited to media access control layer as well as higher communication layers.
Controller 111 is adapted to schedule downstream timeslots in response to the request. Conveniently, controller 111 is adapted to participate in a distributed media access control scheme in order to schedule the downstream timeslots. Conveniently, controller 111 is adapted to filter information that is downstream transmitted to the device in response to filtering parameters received by receiver 113.
Transmitter 115 is adapted to transmit to the device a DRP reservation request including time slots assigned for a transmission of downstream information to the device and, after DRP reservation is established, to transmit to the device downstream information during the assigned downstream timeslots. Conveniently, transmitter 115 is adapted to transmit to the device bridge capability indication indicating that bridge 100 is capable of allocating downstream timeslot in response to a request from the device.
Device 10 supports PHY layer 220, a data link layer that includes MAC layer 230, and a logical link control sub-layer (denoted WiNet) 240, as well as upper layer protocols collectively denoted upper layers 250. The upper layers can include a network layer, a transport layer, a session layer and a presentation layer but this is not necessarily so. Upper layers 250 can represent some of the functionalities of controller 11.
Bridge 100 supports PHY layer 120, a data link layer that includes MAC layer 130, and a logical link control sub-layer (denoted WiNet) 140, as well as upper layer protocols collectively denoted upper layers 150. The upper layers can include a network layer, a transport layer, a session layer and a presentation layer but this is not necessarily so. Upper layers 150 can represent some of the functionalities of controller 11.
The request to allocate multiple downstream timeslots is logically sent from WiNet sub-layer 240 to WiNet sub-layer 140. Yet for another example, the bridge capability indication can be a bit within an application specific information element that is logically sent from WiNet sub-layer 140 to WiNet sub-layer 240.
The DRP timeslots are allocated at the MAC layer level.
Examples of devices and bridges that have a PHY layer are illustrated in the following U.S. patent applications, all being incorporated herein by reference: U.S. patent application Ser. No. 10/389,789 filed on Mar. 10, 2003 and U.S. patent application Ser. No. 10/603,372 filed on Jun. 25, 2003.
The receiver can include various components that are arranged in multiple layers. A first configuration includes a frame convergence sub-layer, a MAC layer, a PHY layer as well as MAC SAP, PHY SAP, frame convergence sub-layer SAP and a device management entity can also be utilized. Another configuration is described at
Wisair Inc. of Tel Aviv Israel manufactures a chip set that includes a Radio Frequency PHY layer chip and a Base-Band PHY layer chip. These chips can be connected in one end to a RF antenna and on the other hand be connected or may include a MAC layer circuitry.
Device 60 includes antenna 61 that is connected to a RF chip 62. RF chip 62 is connected to a MAC/PHY layers chip 63 that includes a PHY layer block 63 and a MAC layer block 64. The MAC/PHY layers chip 63 is connected to an application entity 66 that provides it with information to be eventually transmitted (TX) and also provides the application 66 with information received (RX) by antenna 61 and processed by PHY and MAC layers blocks 68 and 69 of
PHY/MAC layers chip 63 as well as RF chip 62 and antenna 61 can belong to transmitter 15, transmitter 115, receiver 13 and receiver 113. PHY layer block 65, RF chip 62 and antenna service PHY layers such as PHY layer 120 and PHY layer 220. MAC layer block 64 can service MAC layer 130 and MAC layer 230.
Typically, the MAC layer block 64 controls the PHY layer block using a PHY status and control interface. The MAC and PHY layers exchange information (denoted TX and RX) using PHY-MAC interface 90. The RF chip 62 provides to the PHY layer block 63 received information that is conveniently down-converted to base band frequency. The RF chip 62 receives from the PHY layer block 63 information to be transmitted as well as RF control signals. The application 66 is connected to the MAC/PHY layers chip 63 by a high-speed I/O interface.
The Upper Layer IF block 64 of the MAC/PHY layers chip 63 includes hardware components (collectively denoted 69) and software components (collectively denoted 68). These components include interfaces to the PHY layer (MAC-PHY interface 90) and to the application (or higher layer components).
The hardware components 69 include configuration and status registers 81, Direct Memory Access controller 82, First In First Out (FIFO) stacks 83 and frame validation and filtering components 84, DRP and PCA slots schedulers 85, ACK processors 86, and MAC-PHY internal interface 87.
The software components 68 include a management module 72, transmit module 73, receive module 74 hardware adaptation layer 75, DMA drivers 76, MAC layer management entity (MLME) service access point (SAP) 71, MACS API 70 and the like.
These software and hardware components are capable of performing various operations and provide various services such as: providing an interface to various layers, filtering and routing of specific application packets sent to MAC data queues or provided by these queues, performing information and/or frame processing, and the like.
The routing can be responsive to various parameters such as the destinations of the packets, the Quality of Service characteristics associated with the packets, and the like.
The processing of information along a transmission path may include: forming the MAC packet itself, including MAC header formation, aggregation of packets into a bigger PHY PDU for better efficiency, fragmentation of packets for better error rate performance, PHY rate adaptation, implementation of Acknowledgements policies, and the like. The processing of information along a reception path may include de-aggregation and/or de-fragmentation of incoming packets, implementation of acknowledgment and the like.
The hardware components are capable of transferring data between MAC software queues and MAC hardware (both TX and RX), scheduling of beacons slots, scheduling of DRP and PCA access slots, validation and filtering (according to destination address) of incoming frames, encryption/decryption operations, low-level acknowledgement processing (both in the TX path and in the RX path),
Device 60 can be a simple device or even a complex device such as but not limited to a multimedia server that is adapted to transmit information frames of different types to multiple devices. It can, for example transmit streaming data, like voice, Video, Game applications, and the like. Data files during DRP slots, and while PCA slots transmit video over IP frames, download MP3 files, download MPEG-2 files, and stream or download MPEG-4 streams.
Usually, voice frames are associated with higher quality of service requirements and accordingly are given higher transmission priorities. The voice frames QoS requirements are followed by video frames that in turn are followed by lower quality of service requirements (lower priority transmission) frames such as best effort frames and background frames.
The following tables illustrate exemplary control fields. These control fields can be sent from device (such as device 10) to bridge 100 or from bridge 100 to device, 10, according to their content. It is noted that other control fields can be used without departing from the scope of the invention.
TABLE 1 illustrates a request to allocate multiple downstream timeslots. The request includes a MUX header, a control subtype field that includes a value that indicates that the control frame is a request (this value is denoted “DRP establishment request”), expected transmission parameters (also referred to as expected traffic quality of service requirements or transmission parameters) and traffic filtering parameters (also referred to as filtering parameters). It is noted that the filtering parameters can be regarded as belonging to the transmission parameters
It is noted that the control subtype field can have other values. For example it can indicate that a control frame is a response to the bridge to the request, can indicate that the control frame includes bridge capability indication, and the like.
TABLE 2 illustrates exemplary traffic parameters. It is noted that other traffic parameters can be used, for example DRP MAS parameters.
The traffic parameters include a Mean Data Rate field, a Peak Data Rate field, a Maximum Burst Size field, a Maximum Media Access Control Service Data Unit (MSDU) size field, a Minimum Policed Unit field, a Maximum Service Interval field and a Service Type Field.
The Mean Data Rate field indicates the average data rate in units of octets per second for the expected downstream traffic to the device. The Peak Data Rate field indicates the maximum expected data rate in units of octets per second, for the expected downstream traffic to the device. Conveniently, the Mean Data Rate and the Peak Data Rate values do not include the MAC and PHY overheads incurred in transferring the MSDUs.
The Maximum Burst Size field indicates the maximum burst, in units of octets, of the MSDUs belonging to the expected downstream traffic to the device that arrives to the bridge at the Peak Data Rate. The Maximum MSDU Size field indicates an unsigned integer that specifies the maximum size, in octets, of MSDUs belonging to the expected downstream traffic to the device. The Minimum Policed Unit field indicates the minimal size, in units of octets, of MSDUs belonging to the traffic expected. The Max Service Interval field indicates the required Max Service interval for the expected downstream traffic to the device, traffic expected.
The Service Type field can indicate various aspects of the downstream traffic such as acknowledgement policy (for example, no acknowledgment, immediate acknowledgement, block based acknowledgement), type of traffic (best effort, guaranteed delivery, non-guaranteed high reliability of delivery) and the like. The type of traffic is also referred to loss of sensitivity.
The filtering parameters can start by a field indicating the number of filter parameters and then the parameters of each filter are provided. Conveniently, if a frame is not blocked by either filter is can be downstream transmitted to the device.
The filtering can be applied on various control fields included within the downstream traffic that reaches the bridge. Usually, the filtering parameters include filter parameters that comprise filter length, location of filtered field in a frame, expected value of filtered field and filter mask value. Conveniently, the mask is defined on a bit-to-bit basis.
TABLE 3 illustrates an initial response to a request to allocate multiple downstream timeslots. This initial request may include error fields. It does not indicate which are the allocated downstream timeslots. The initial response includes a MUX header field, a control subtype field that includes a value that indicates that the control frame is an initial response (this value is denoted “Initial response”), and a response bitmap.
The response bitmap includes an unsupported capability bit, an invalid acknowledgement policy bit, an invalid type of traffic bit, an invalid filtering parameters bit an unsupported filtering parameter bit and additional bits such as security violation bit, resource limitation bit and the like.
The unsupported capability bit is the bridge capability indication and indicates if the bridge can allocate downstream timeslot in response to a request from the device. The invalid acknowledgement policy bit indicates if the request included a request to apply an invalid acknowledgement policy. The invalid type of traffic bit indicates if the request included a request to apply an invalid type of traffic. The invalid filtering parameters bit and the unsupported filtering parameter bit indicate if the request included a request to support invalid or unsupported type of traffic. Examples of erroneous requests can include a request to support multicast and immediate or block based acknowledgement; filtering parameters that include a communication protocol that is not covered by the request, too many filtering parameter sets, and the like.
Method 400 starts by stage 410 of receiving, from the bridge, bridge capability indication indicating that the bridge is capable of allocating downstream timeslot in response to a request from the device. If the bridge does not have such a capability method 400 ends.
Stage 410 is followed by stage 430 of determining, by the ultra wideband device, expected downstream transmission parameters. These parameters can relate to expected quality of service level associated with the downstream transmission.
Conveniently, stage 430 includes converting high communication layer quality of service characteristics to expected media access control downstream transmission parameters.
Stage 430 is followed by stage 440 of requesting the bridge to allocate multiple downstream timeslots in response to the expected downstream transmission parameters. It is noted that stage 440 can be followed by another stage of receiving an initial response from the bridge and correcting the request (if necessary) in response to the initial response. For example the acknowledgement policy can be altered and the like.
Stage 440 is followed by stage 450 of receiving downstream timeslot reservation request on the MAC layer, indicating of downstream timeslots assigned for a transmission of downstream information to the device.
In case the reservation is established successfully, Stage 450 is followed by stage 460 of receiving downstream information during the assigned downstream timeslots.
Conveniently, stage 430 includes determining filtering parameters for filtering downstream information to be provided to the device. The filtering parameters can include multiple filter parameters defining multiple filters. Conveniently, the filtering parameters include filter length, location of filtered field in a frame, expected value of filtered field and filter mask value.
Method 500 starts by stage 510 of transmitting to a device bridge capability indication indicating that the bridge is capable of allocating downstream timeslot in response to a request from the device.
Stage 510 is followed by stage 520 of receiving, by the bridge, a request to allocate multiple downstream timeslots for downstream transmission from the bridge to the device that is characterized by expected downstream transmission parameters. These downstream transmission parameters can indicate the quality of service associated with the device.
Stage 520 can be followed by examining the request and sending an initial response that may indicate that the requests include errors.
Stage 520 is followed by stage 540 of transmitting to the device downstream timeslot acknowledgement information indicating of downstream timeslots assigned for a transmission of downstream information to the device. Stage 540 may include issuing a DRP reservation request of downstream timeslots in response to the device DRP establishment request and then receiving an acknowledgement indicating which timeslots should be allocated to the device.
Stage 540 is followed by stage 550 of transmitting to the device downstream information during the assigned downstream timeslots.
Conveniently, stage 550 includes filtering downstream information in response to filtering parameters provided by the device.
It will be apparent to those skilled in the art that the disclosed subject matter may be modified in numerous ways and may assume many embodiments other then the preferred form specifically set out and described above. It is noted that each of the mentioned above circuitries can be applied by hardware, software, middleware or a combination of the above. The mentioned above methods can be stored in a computer readable medium, such as but not limited to tapes, disks, diskettes, compact discs, and other optical and/or magnetic medium.
Accordingly, the above disclosed subject matter is to be considered illustrative and not restrictive, and to the maximum extent allowed by law, it is intended by the appended claims to cover all such modifications and other embodiments, which fall within the true spirit and scope of the present invention.
The scope of the invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents rather then the foregoing detailed description.
