Methods of Unparking a Slave Device in Park Mode

Original Post: Park Mode query (eGroups Msg. 141 ) Date: 1999-12-20

When a slave device is in park mode, it can request access to the channel through the access window. After having sent an access request, the parked slaves will listen for an unpark message from the master.

Now unpark messages can only be send in the beacon slots. But according to the beacon access window structure the next beacon slot would only arrive after M_access access windows have passed by. This would mean that the slave would perform repeated attempts in all the subsequent access windows, but still won't get a response(unpark message) from the master.

Question

However the beacon access window also shows a master to slave slot. The question is, would the master use this slot to unpark the slave, and if so, does this not conflict with the explanation that the "master would unpark the slaves ONLY in the beacon slots" ?

Answer

The answer is on page 120, sections 10.8.4.5 and 10.8.4.6 .

The master will use the beacon slot to unpark a slave ONLY if it is a master initiated unpark.
In the case of slave initiated unpark, the master can unpark the particular slave using broadcast packets in the master to slave slots in the access window.

This is logical because in the case of master initiated unpark, the master cannot be sure whether the intended slave is listening to it during the access window. On the other hand, it can be absolutely sure that the intended slave is listening to it at the beacon instants because all parked slaves are supposed to listen to the master at least at the beacon instants.

For a slave initiated unpark, the master can be sure that the slave which had sent a request to unpark, would be listening to it during the access window. So in this case, the master can send an unpark message to the slave during the access window itself, (the first paragraph on page 121 makes this clear).