WiMedia Interoperability and Beaconing Protocol

Transcription

1 and Beaconing Protocol Mike Micheletti UWB & Wireless USB Product Manager LeCroy Protocol Solutions Group T he WiMedia Alliance s ultra wideband wireless architecture is designed to handle multiple protocols with a common radio platform using the same PHY/MAC layers. These underlying layers have undergone unprecedented testing over the last year as multiple vendors begin sampling product development platforms built on this common foundation. Fundamental to the design of the WiMedia MAC layer is the beaconing protocol that performs discovery of nearby WiMedia-based piconets. Beaconing plays an essential role ensuring coexistence between devices from different vendors by providing a distributed mechanism for: Identifying which beacon slots neighboring devices occupy Advertising which beacon slot a given device will occupy Discovery of neighboring piconets to avoid interference Prioritized access (QOS) for specific applications One of the primary roles of the beacon protocol is to identify in which beacon slot (time interval) a given device will transmit its beacon frame. While there are numerous rules and policies governing the behavior of devices participating in the beacon period, this article will focus on the issue of beacon contraction and the potential collision scenarios. Figure 1: Illustrates logical WiMedia superframe and Beaconing Protocol Page 1 of 9

2 Beaconing: A Primer Due to the nature of Wireless PANs, the WiMedia protocol allows devices to join or leave the network without disrupting the operation of devices already synchronized to a beacon group. The Beacon Period (BP) is designed to dynamically expand and contract as devices join and leave the network. By reducing the number of beacon slots, WiMedia devices allow a larger portion of each Superframe to be dedicated to data transfers rather than beacons. Expanding the beacon period is required to allow new devices to join. The Beacon Period Occupancy Information Element (BPOIE) The Beacon Period Occupancy Information Element (BPOIE) is contained in the payload of every beacon frame and reports the BP length and status of individual beacon slots as seen by the device transmitting the frame. Devices are required to listen to BPOIEs to detect which slots are reported as occupied and then place their beacon in an available slot. The Beacon Slot Info Bitmap field communicates or advertises to other devices which slots the transmitting device detected as occupied. The DevAddr field(s) reports the actual address that was seen in each occupied slot. Octects: K 1 1 Element ID Length (= 1+K+2xN) BP Length Beacon Slot Info Bitmap DevAddr1 DevAddr N Figure 2. The format for the BPOIE It s important to understand that the Beacon Slot Info Bitmap only reports what a device heard from neighboring beacons. It s the device s view of the status of each slot in the beacon period. It does not include its own Beacon in the bitmap, but instead communicates the location of its own slot in the beacon header. Each 2-bit value in the Beacon Slot Bitmap is decoded to show the slot status: 0 - Unoccupied In the last superframe, no device reported a beacon frame with this slot occupied 1 - Occupied & non-movable In the last superframe, a device reported a valid beacon frame was received and reported this slot as occupied with the movable bit set to Occupied & movable In the last superframe, a device reported this slot was occupied but the frame had an invalid HCS or FCS (error) 3 - Occupied & movable In the last superframe, a device reported a valid beacon frame was received and reported this slot as occupied with the movable bit set to 1 Figure 3: Decoded values for the (2-bit) Beacon Slot Bitmap Protocol analyzers that record and display beacon frame information are used to verify numerous protocol rules and behaviors. Common analysis tasks include verifying what slots are reported occupied in the BPOIE and that neighboring devices properly extend the length of the beacon period when a new device joins the BP. Figure 4: The analyzer capture shows the decoded BPOIE; the Beacon Slot Info Bitmap represents the transmitting device s view of the status of each slot in the last superframe. In the first beacon, the device (Src ID 0x1468) reports seeing device 0x45DE in slot 5. In the second beacon, the device (Src ID 0x45DE) reports seeing device 0x1468 in slot 4 (Both devices see each other). and Beaconing Protocol Page 2 of 9

3 Beacon Period Expansion All WiMedia devices are required to transmit a beacon frame at the beginning of the superframe (or BP). After a device powers on, it must scan for beacons from neighboring devices for at least one superframe. If it discovers an existing beacon period, it must join it by inserting its beacon in an available slot. After a device joins a beacon period, it constantly checks the announced BP length in the received beacons to determine how long to listen during the beacon period. Accurately detecting devices that may join later is essential for good interoperability. Precise transmit and receive accuracy during the beacon period is imperative to ensure devices can reliably take turns sending and receiving beacons. If a device doesn t detect an existing beacon period, it will start one by sending a beacon frame with its beacon slot set to 2. If it does detect an existing beacon period with sufficient remaining capacity, it must try to join the group by inserting its beacon somewhere after the highest unavailable beacon slot. It may also be required to transmit its beacon in a signaling slot, which is used to identify that the device would like to join the beacon period and is requesting that other devices extend their BP Lengths to include it. If so, the device must continue to occupy the signaling slot until it knows that the neighboring devices have extended their BP Lengths to include its higher slot; however, the device must not occupy the signaling slot for more than 4 consecutive superframes. If the neighboring devices do not extend their BP Lengths within 4 superframes, the device must cease occupying a signaling slot for at least 4 consecutive superframes. After that, the device may resume occupying the signaling slot. This is sometimes referred to as the 4 on, 4 off signaling behavior. Figure 5: Illustrates Beacon period layout after DEV 7 joins an existing beacon group by occupying both the signaling slot and slot 9. Figure 6: Illustrates the corresponding Beacon slot bitmap as captured and decoded by a protocol analyzer and Beaconing Protocol Page 3 of 9

4 Beacon Period Contraction While participating in a beacon group, devices must systematically shift down or contract to the earliest available slots in the beacon period. By contracting the beacon period, devices maximize the amount of time available for data transfers. Shorter beacon periods also help optimize power consumption by reducing the amount of time the radio is on. A device that sees an earlier available slot must mark its beacon as movable. If the device s beacon is marked as movable for 4 consecutive superframes, and no other beacon in a higher slot was marked as movable during that time, the device must relocate its beacon in the next superframe to fill the lowest available slot after the signaling slots. Figure 7: Illustration of beacon slot contraction A stable beacon group occurs when all beacons (marked movable) have contracted to fill any earlier available slots. Unoccupied vs. Unavailable There is a common point of confusion about the terms available/unavailable and occupied/unoccupied. These terms are not interchangeable. The terms occupied/ unoccupied refer to the slot info states reported in the BPOIE. However, the terms available/unavailable refer to the history of the slot info states over the past 4 superframes. For example, if a slot is occupied in any of the 4 previous superframes, then a device must consider that slot unavailable in the current superframe. On the other hand, if a slot is unoccupied in each of the 4 previous superframes, then a device must consider that slot available in the current superframe. A device must use info in the BPOIEs of received beacons in conjunction with its own logical state to fully determine a slot s occupied/unoccupied status. and Beaconing Protocol Page 4 of 9

5 The following figure illustrates 2 examples of contraction. The first example shows the simplest case when there is no higher movable slot. The second example shows a slightly more complicated case when there is a higher movable slot. Figure 8: Illustrates progression of logical beacon states as device contracts. 1) lower slot is Unoccuppied 2) it s available 3) beacon must be marked movable at least four superframes 4) device sees no beacons with other devices in higher slots that are movable 5) device moves to lower slot Figure 9: Illustrates progression of logical beacon states during contraction when another device occupies a higher slot. 1) lower slot is Unoccuppied 2) it s available 3) beacon must be marked movable four sequential superframes 4) then device sees beacon with other device in higher slot also set to movable 5) The higher device moves in superframe 10 and only after waiting 4 more superframes - with no device in higher slot - can device move to lower slot in superframe 14. and Beaconing Protocol Page 5 of 9

6 Beacon Slot Collisions Given the mobile nature of many WiMedia devices, it would be common for devices to join and leave adjacent networks, thereby creating a greater risk of asymmetric links between devices, (i.e., A can hear B, but B cannot hear A). With asymmetric links, there is a higher potential for beacon slot collisions because a given device might not be aware that some slots are occupied. How can we determine when beacon slot collisions occur? There are several common symptoms: Two devices advertise the same beacon slot during the current superframe. Devices report HCS errors in their BPOIEs. Protocol analyzer reports HCS errors during the beacon period. The BPOIEs of devices in the beacon period do not report a consistent set of devices. To detect beacon collisions with neighbors, each device should periodically skip beacon transmission (at least once every 128 superframes) and listen for a potential neighbor occupying its beacon slot. Furthermore, devices are required to listen to BPOIEs sent by other devices and detect conditions which would mandate a move of their beacon. For example, if a device receives a BPOIE that reports a different DevAddr is occupying its slot, the device must move to a higher available slot. Considerations in Testing Beacon Protocol In addition to passing structured compliance tests, developers will be required to demonstrate beacon protocol interoperability between devices in order to satisfy the WiMedia Platform Test specification. This emphasis on interoperability has several implications for protocol layer testing: Beacon group analysis As cross vendor interoperability testing accelerates, the need to test beaconing with multiple devices within a single beacon group has become mandatory. The ability to easily see which beacon slot the device currently occupies will simplify the analysis. The time stamp display of the LeCroy UWBTracer can optionally show the logical beacon groups. Superframe number / Beacon slot (in the superframe) / Offset (into the slot). Figure 10: Change format of Timestamp to show Beacon Group information and Beaconing Protocol Page 6 of 9

7 This timing information helps users identify at a glance when devices fall outside expected values. In the example below, a beacon slot collision occurs when two devices transmit beacon frames in slot 3. Figure 11: Beacon Collision caused by frame and both occupying slot 3 (also reported as HCS error) Filtering Fundamental to BP analysis is the ability to capture and display beacon frames from multiple participating devices over extended periods. Analysis tools that support pre-capture filtering allow users to Filter-in beacon frames only. By discarding all other packets users can capture beacon frames for extended periods (several hours). Users avoid creating large trace files that are slow to search and save. Figure 12: LeCroy s UWBTracer supports FILTER-IN of Beacon frames to simplify analysis by creating trace files that are faster to search, manipulate and analyze Clock Accuracy The WiMedia MAC layer relies on rigorous timing accuracy for several key aspects of the protocol behavior, including Beacon Period Start Time (BPST) and MAS reservations. Beacon slot collisions can also occur if a device s clock accuracy is not within spec. Because the WiMedia MAC protocol operates in a distributed manner, there is no central entity that manages device synchronization. Instead, each device keeps track of its own BPST. In order to synchronize to an existing beacon period, each device must continually adjust its BPST to match that of the slowest device in the beacon period. When all devices do this correctly, the aggregate behavior is that the devices in the beacon period remain synchronized with each other. While WiMedia defines a guard time to accommodate minor drift between neighboring devices, beacon collisions caused by devices that fail to maintain timing margins can be difficult to identify. Test tools that are used to evaluate timing compliance must have better clock accuracy than the devices they are testing. and Beaconing Protocol Page 7 of 9

8 The specification requires beacon period intervals to be between and microseconds. If the measurement device has nominal drift of 20 PPM, it may fail to identify cases where beacon interval does not meet the requirement. To ensure measurement equipment can accurately identify devices that fail to meet beacon interval-timing specs, it should have an extremely high quality crystal oscillator. The LeCroy UWBTracer is rated at better than 4 PPM nominal drift. The figure below illustrates how this type of accuracy allows developers to identify errors within ± 24 PPM of nominal timing (worst case). Figure 13: Illustration beacon period timing interval. Analysis tools should be capable of accurately identifying timing errors within 10 PPM and ideally lower than 4 PPM Automated Testing of Beacon Protocol LeCroy s UWBTracer Analyzer platform includes a post processing API called the Verification Script Engine (VSE) that can be used to automate routine verification tasks. The LeCroy system was used extensively by the compliance working group to automate portions of Platform Test specification. Several scripts were developed that automatically verify over 30 compliance points for every beacon frame in a trace. These script files are available for developers to use or modify to create their own custom test suite. and Beaconing Protocol Page 8 of 9

9 Figure 14: LeCroy analysis software includes post-processing analysis scripts that automatically verify beacon period protocol compliance Summary By building the ultra wideband wireless architecture on a common radio platform using the same PHY/MAC layer, vendors have created the foundation for seamless interoperability between devices. Beaconing plays an essential role in ensuring co-existence between these devices, whether they are based on Wireless USB, WiMedia or Bluetooth. Today s investment in testing of Beacon protocol will help create robust WiMedia MAC layer devices and provide a better end-user experience for WiMedia technology in the future. and Beaconing Protocol Page 9 of 9