WiMedia beaconing protocol test considerations

EE-Evaluation Engineering, Sept, 2007 by Mike Micheletti

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.

[FIGURE 1 OMITTED]

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).

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 non-intrusively 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.

[FIGURE 2 OMITTED]

BPOIE

WiMedia protocol analyzers are designed to capture and display beacon frame information to verify numerous protocol rules and behaviors. When verifying beaconing protocol, much of the attention is focused on the beacon period occupancy information element (BPOIE) (Table 1).

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.

BP Expansion

When testing beaconing protocol, most problems are observed when devices join and leave the group. After a device powers on, it will scan for beacons from neighboring devices for at least one superframe. If a device doesn't detect an existing BP, it will start one by sending a frame with its slot set to 2.

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.