Starting and maintaining PANs

Contents :
1 Scanning through channels
– ED channel scan
– Active channel scan
– Passive channel scan
– Orphan scan
2. Associaiton
3. Disassociation
4. Synchronization

1. Scanning through channels :
All devices shall be capable of performing passive and orphan scans across a specified list of channels.
An FFD shall be able to perform ED(Energy Detection) and active scans.
For the duration of the scan, the device shall suspend beacon transmissions, if applicable, and upon the conclusion of the scan, the device shall recommence beacon transmission.

A device is instructed to begin a channel scan through the MLME-SCAN.request primitive.
The results of the scan shall be returned via the MLME-SCAN.confirm primitive.

a. Energy Detection (ED) channel scan
An ED scan allows an FFD to obtain a measure of the peak energy in each requested channel.
This could be used by a prospective PAN coordinator to select a channel in which to operate prior to starting a new PAN.

During an ED scan, the MAC sublayer shall discard all frames received over the PHY data service.
An ED scan over a specified set of logical channels is requested using the MLME-SCAN. request primitive with the ScanType parameter set to indicate an ED scan.

For each logical channel, the MLME shall first switch to the channel, be setting phyCurrentChannel accordingly, and then repeatedly perform an ED measurement for [aBaseSuperframeDuration * (2^n + 1)] symbols, where n is the value of the ScanDuration parameter in the MLME-SCAN.request primitive.

The maximum ED measurement obtained during this period shall be noted before moving on to the next channel in the channel list.
The ED scan shall terminate when either the number of channel ED measurements stored equals the implementation-specified maximum or energy has been measured on each of the specified logical channels.

b. Active Channel Scan.
An active scan allows an FFD to locate any coordinator transmitting beacon frames within its POS (Personal Operating Space).
This could be used by a prospective PAN coordinator to select a PAN identifier prior to starting a new PAN, or it could be used by a device prior to association.
During an active scan, the MAC sublayer shall discard all frames received over the PHY data service that are not beacon frames.

An active scan over a specified set of logical channels is requested using the MLME-SCAN.request primitive with the ScanType parameter set to indicate an active scan.
For each logical channel, the device shall first switch to the channel, by setting phyCurrentChannel accordingly, and send a beacon request command. The device shall then enable its receiver for at most [aBaseSuperframeDuration * (2^n + 1) symbols], where n is a value between 0 and 14.
During this time, the device shall reject all nonbeacon frames and record the information contained in all unique beacons in a PAN descriptor structure.

A beacon frame shall be assumed to be unique if it contains both a PAN identifier and a source address that has not been seen before during the scan of the current channel.
If a coordinator of a beacon-enabled PAN receives the beacon request command, it shall ignore the command and continue transmitting its beacons as usual. If a coordinator of a nonbeacon-enabled PAN receives this command, it shall transmit a single beacon frame using unslotted CSMA-CA.

The entire scan shall terminate when the number of PAN descriptors stored equals the implementation-specified maximum or every channel in the set of available channels has been scanned.
If a coordinator of a beacon-enabled PAN receives the beacon request command, it shall ignore the command and continue transmitting its beacons as usual. If a coordinator of a beacon-enabled PAN receives this command, it shall transmit a single beacon frame using unslotted CSMA-CA.

The entire scan shall terminate when the number of PAN descriptors stored equals the implementation-specified maximum or every channel in the set of available channels has been scanned.

c. Passive Channel Scan
A passive scan, like an active scan, allows a device to locate any coordinator transmitting beacon frames within its POS.
The beacon request command, however, is not transmitted. This type of scan could be used by a device prior to association.

D. Orphan scan
An orphan scan allows a device to attempt to relocate its coordinator following a loss of synchronization.
During an orphan scan, the MAC sublayer shall discard all frames received over the PHY layer data service that are not coordinator realignment MAC command frames.

If a coordinator receives the orphan notification command, it shall search its device list for the device sending command.If the coordinator finds a record of the device, it shall send a coordinator realignment command to the orphaned device.

The process of searching for the device and sending the coordinator realignment command shall occur within aResponseWaitTime symbols.
The coordinator realignment command shall contain its current PAN identifier, macPANid, its current logical channel and the short address of the orphaned device. If a coordinator finds no record of the device, it shall ignore the command and not send a coordinator realignment command.

The orphan scan shall terminate when the device receives a coordinator realignment command or the specified set of logical channels has been scanned.

2. Association
A device shall only attempt to associate after having first performed a MAC sublayer reset, by issuing the MLME-RESET.request primitive, and then having completed either an active channel scan or passive channel scan. The results of the channel scan would have then been used to choose a suitable PAN.

Following the selection of a PAN with which to associate, the next higher layers shall request through the MLME-ASSOCIATE.request primitive that the MLME configures the following PHY and MAC PIB attributes to the values necessary for association :
– phyCurrentChannel shall be set equal to the LogicalChannel parameter of the MLME-ASSOCIATE.request primitive.
– phyCurrentPage shall be set equal to the ChannelPage parameter of the MLME-ASSOCIATE.request primitive.
– macPANId shall be set equal to the CoordPANId parameter of the MLME-ASSOCIATE.request primitive
– macCoordExtendedAddress or macCoordShortAddress, depending on which is known from the beacon frame from the coordinator through which it wishes to associate.

A coordinator shall aloow association only if macAssociationPermit is set to TRUE. If a coordinator with macAssociationPermit set to FALSE receives an association request command from a device, the command shall be ignored.

A device that is instructed to associate with a PAN, through the MLME-ASSICOATE.request primitive, shall try only to associate with an existing PAN and shall not attempt to start its own PAN.
An unassociated device shall initiate the association procedure by sending an associate request command to the coordinator of an existing PAN.
If the association request command is received correctly, the coordinator shall send an acknowledgment frame, thus confirming receipt.

The acknowledgment to an association request command does not mean that the device has associated.
The coordinator needs time to determine whether the current resources available on the PAN are sufficient to allow another device to associate.
The coordinator shall make this decision within aResponseWaitTime symbols. If the coordinator finds that the device was previously associated on its PAN, all previously obtained device specific information shall be removed.

If sufficient resources are available, the coordinator shall allocate a short address to the device and generate an association response command containing the new address and a status indicating a successful association.
If sufficient resources are not available, the coordinator shall generate an association response command containing a status indicating a failure.

If the association status field of the command indicates that the association was successful, the device shall store the addresses of the coordinator with which it has associated. The short address of the coordinator, contained in the original beacon selected for association following a scan, shall be stored in macCoordShortAddress and the extended address of the coordinator, contained in the MAC header of the association response command frame, shall be stored in macCoordExtendedAddress.

The device shall also store the address contained in the short address field in macShortAddress. Communication on the PAN using this short address shall depend on its range.
Table:
t87.jpg

3. Disassociation
When a coordinator wants one of its associated devices to leave the PAN, it shall send the disassociation notification command to the device using indirect transmission.
If the device requests and corrently receives the disassociation notification command, it shall confirm its receipt by sending an acknowledgment frame. Even if the acknowledgment is not received, the coordinator shall consider the device disassociated.

If an associated device wants to leave the PAN, it shall send a disassociation notificaiton command to its coordinator. If the disassociation notification command is received correctly by the coordinator, it shall confirm its receipt by sending an acknowledgment frame. Even if the acknowledgment is not received, the device shall consider itself disassociated.

4. Synchronization.
Synchronization with Beacon :
All devices operating on a beacon enabled PAN (macBeaconOrder < 15) shall be able to acqire beacon synchronization in order to detect any pending messages or to track the beacon.
A device is instructed to attempt to acquire the beacon through the MLME-SYNC.request primitive.

If tracking is specified in the MLME-SYNC.request primitive, the device shall attempt to acquire the beacon and keep track of it by regular and timely activation of its receiver.
If tracking is not specified, the device shall attempt to acquire the beacon only once.

To acquire beacon synchronization, a device shall enables its receiver and search for at most [aBaseSuperframeDuration * (2^n + 1)] symbols, where n is the value of macBeaconOrder. If a beacon frame containing the current PAN identifier of the device is not received, the MLME shall repeat this search. Once the number of missed beacons reaches aMaxLostBeacons, the MLME shall notify the next higher layer by issuing the MLME-SYNC-LOSS.indication primitive eith a loss reason of BEACON_LOSS.

If beacon frame is recived, the device shall verify that the beacon frame came from the coordinator with which it associated. If the source address and the source PAN identifier fields of the beacon frame header do not match the coordinator source address (macCoordSourceAddress or macCoordExtendedAddress, depending on the addressing mode) and the PAN identifier of the device (macPANId), the MLME shall discard the beacon frame.

Synchronization without beacons :
All devices operating on a non-beacon enabled PAN (macBeaconOrder = 15) shall be able to poll the coordinator for data at the dicretion of the next higher layer.
A device is instructed to poll the coordinator when the MLME receives the MLME-POLL.request primitive.On receipt of this primitive, the MLME shall follow the procedure for extracting pending data from the coordinator.
Reference :
IEEE Standard for Information technology, Specifications for WPANs 802.15.4

Note : This resume is created for self-learning only. Author and Publisher hold copyrights

always relay on You,

February 01 2008,
Taipei City
High Speed Network Lab

Udin Harun

Comments are closed.

%d bloggers like this: