The WiMedia Alliance’s ultra-wideband (UWB) wireless architecture handles multiple protocols with a common radio platform that uses the same PHY/MAC layer. Whether the device is using Certified Wireless USB, Bluetooth technology, or Wireless IP, the UWB architecture provides reliable operation with multiple devices running in close proximity.

Fundamental to this interoperability at the MAC layer is the beaconing protocol that performs discovery of nearby WiMedia-based devices. Beaconing plays an essential role in ensuring interoperability and 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.
• Discovering neighboring piconets to avoid interference.
• Prioritizing access (QoS) for specific applications.

One of the primary roles of the protocol is to identify in which slot or time interval a given device will transmit its frame. While there are numerous rules and policies governing the behavior of devices participating in the beacon period (BP), a major issue is analyzing contraction and expansion.

Due to the nature of Wireless private area networks (PANs), the WiMedia protocol allows devices to join or leave the network without disrupting the operation of devices already synchronized to a group. For that reason, the BP is designed to dynamically expand and contract as necessary.

During the BP, devices take turns sending frames at precise intervals. It expands when new devices join. When devices leave, the remaining ones are required to contract to occupy any vacant slots. 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 (Figure 1).

Figure 1. Logical WiMedia Superframe

The WiMedia Alliance dictates that all WiMedia-based devices satisfy the platform test specification by passing structured compliance tests. It also requires vendors to demonstrate beacon protocol interoperability. This involves testing operation with multiple golden devices in close proximity and within a single group.

Test equipment vendors now offer protocol analyzers designed to nonintrusively capture and display UWB traffic. But the emphasis on verifying beaconing protocol behavior has put a spotlight on specific capabilities including showing logical groups, removing nonessential packets from the display, automating compliance verification, and ensuring timing accuracy of the analysis platform.

Contained in the payload of every beacon frame, the BPOIE reports the BP length and status of individual slots as seen by the device transmitting the frame. The slot info bitmap field communicates or advertises to other devices which slots the transmitting device detected as occupied.

The receiving 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 DevAddr field(s) reports the device address that was seen in each occupied slot.

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 BP. It does not include its own beacon in the bitmap but instead communicates the location of its own slot in the header. Each 2-b value in the slot bitmap is decoded to show the slot status (Table 2).

The analyzer capture in Figure 2 shows the decoded BPOIE. Common analysis tasks include verifying what slots are reported occupied in the BPOIE and whether neighboring devices properly extend the length of the BP when a new device joins it. The capability to customize the display to show just the relevant portions of the frame can simplify the analysis.

Fundamental to testing beaconing protocol is the capability to capture and display frames from multiple participating devices over extended periods. Analysis tools that support pre-capture filtering make it possible to filter-in beacon frames only.

By discarding all other packets, users can capture frames for up to several hours. Filtering capabilities also allow users to avoid creating large trace files that are slow to search and save.

If the device does detect an existing BP with sufficient remaining capacity, it must try to join the group by inserting its beacon somewhere after the highest unavailable slot. After a device joins a BP, it constantly checks the announced BP length in the received beacons to determine how long to listen during the next BP. Properly extending the BP length is essential for good interoperability because it ensures a device hears neighbors trying to join the group.

The device also may be required to transmit its beacon in a signaling slot. If so, it 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 four consecutive superframes.

If the neighboring devices do not extend their BP lengths within four superframes, the device must cease occupying a signaling slot for at least four 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.

For a device to gain certification, the BP expansion and contraction rules must be observed for every superframe. The latest generation of test tools includes post-processing scripts that automatically check beacon frames and flag potential violations. Specific errors are listed with pointers to the actual frames in question.

These test scripts automatically verify protocol compliance and frame formatting for every beacon in a trace. The verification scripts are used extensively by members of the WiMedia Certification and Interoperability working group to automate analysis in the workshops. These automation frameworks typically are based on a published scripting language that allows users to create or modify scripts for their own use.

A device that sees an earlier available slot must mark its beacon as movable. If the device’s beacon is marked as movable for four 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. An illustration of beacon slot contraction can be seen in Figure 3.

Given the mobile nature of many WiMedia devices, it would be common for devices to join and leave adjacent networks, creating a greater risk of asymmetric links between devices. With asymmetric links, there is a higher potential for slot collisions because a given device might not be aware that some slots are occupied. Protocol analyzers can show common symptoms that indicate when slot collisions occur:
• Two devices advertise the same beacon slot during the current superframe.
• Devices report header check sequence (HCS) errors in their BPOIEs.
• The protocol analyzer reports HCS errors during the BP.
• The BPOIEs of devices in the BP do not report a consistent set of devices.

To avoid collisions with neighbors, each device should periodically skip beacon transmission at least once every 128 superframes and listen for a potential neighbor occupying its slot. Furthermore, devices are required to listen to BPOIEs sent by other devices and detect conditions that 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.

The WiMedia MAC protocol operates in a distributed manner, and there is no central entity that manages device synchronization. Instead, each device keeps track of its own BPST. To synchronize to an existing BP, each device must continually adjust its BPST to match that of the slowest device in the BP. When all devices do this correctly, the aggregate behavior is that the devices in the BP 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. Protocol analysis tools that evaluate timing compliance must have better clock accuracy than the devices they are testing.

The specification requires BP intervals to be between 65536 - 1.4 and 65536 + 1.4 µs. If the measurement device has nominal drift of 20 ppm, it may fail to identify cases where the beacon interval does not meet the requirement.

To ensure analysis tools can accurately identify devices that fail to meet beacon interval-timing specs, they should have an extremely high quality crystal oscillator to achieve a worst case drift of less than 4 ppm. Figure 4 illustrates how this type of accuracy allows developers to identify errors within ±24 ppm of normative timing.

Figure 4. Shows the progression of logical beacon states during contraction when another movable device occupies a higher slot.

on WiMedia verification tools
www.rsleads.com/709ee-184