Polling

entry in the polling list (cf. Figure 4-16 (a)). The length toPoll of the poll timeout is set such that the timeout expires only after the latest possible reception time of the client’s re-sponse. Thus,

toPoll := (δframe + δsched + δframe)(1 + ρ) ,

where the first factor accounts for the transmission and processing delays in real-time and the second factor accounts for the clock drift. Since the delays and the clock drift are as-sumed to be small, we will neglect the factor (1 + ρ) in what follows for sake of simplicity.

Figure 4-16. Length of a polling (a) and a request slot (b)

Figure 4-16 (a) shows that the length ∆Poll of a slot corresponding to a polling entry is

∆Poll := 2δm (δm := δframe + δsched, cf. Sub-Section 4.2.3). By time t + δframe + δsched + δframe

the AP receives a frame from si or the poll timeout expires. So, by time t', δsched time units later, the AP processes the next polling list entry and sends a frame to the corresponding station.

According to the communication structure the IEEE Standard prescribes for infrastructure networks, clients send their data frames to the AP, which relays these frames to their desti-nation station(s). For instance, when a client wants to send a multicast frame, it sends this frame to the AP as a point-to-point frame and the AP multicasts the frame to the stations in the BSS. The AP relays frames from a client when it processes a polling list entry of type relay owned by that client. Figure 4-16 (b) shows that the length of a slot corresponding to a relay entry is ∆Relay := δm. At time t, the AP sends the relayed frame. By time t + δframe, the frame transmission ceases and the communication service sends a status indication (cf.

4.2.2.3). δsched time units later, by time t' = t + δm, the AP processes the next entry in the polling list and sends the corresponding frame.

In a network topology as considered in this thesis, routing messages through the AP tack-les the reachability problem. As we do not make any assumptions about the link quality between any pair of clients of the same AP, it may be impossible for one client to transfer a data frame to another client directly. On the other hand, each valid client is by definition able to communicate with the AP with a bounded number of omission failures. Thus, it is possible for a client to transfer its data frame to the AP and for the AP to transfer this data frame to the destination station. Note that while this approach tackles the reachability prob-lem it does not solve the probprob-lem of unreliable communication links; that is of message losses.

To increase the efficiency of the polling procedure, the IEEE 802.11 Standard specifies combined data and polling frames (Data+CF-Poll), which enable the AP to piggyback SDUs on the polling frames it sends. The polling protocol provides a service, called poll extension (POLL_EXT), which allows the user of the protocol at the AP to request the transmission of SDUs in the polling frames. Whenever the polling entity at the AP proc-esses a poll entry, it solicits its user to request the transmission of a SDU. The polling en-tity transmits this SDU in the polling frame it sends to the owner of the entry.

4.3.2.2 Dynamic Group Extensions

When dynamic groups are considered the polling list is not longer static but may change when stations join or leave the group. Basically, it is the tasks of the dynamic network scheduling protocol to maintain the polling list in such cases. The polling protocol, how-ever, supports it in doing so in the following three ways:

• The polling protocol provides interfaces for reading and setting the polling list so that the dynamic network scheduling protocol is able to modify the polling list when the membership changes.

• It provides medium access to stations that are not yet part of the polling list so that such stations are able to request to be added to the polling list.

• It detects clients that became invalid and sends a corresponding notification to the higher layers.

A distinguishing aspect in handling dynamic groups is whether the application requires valid stations to be able to join the group in bounded time. If this is the case, contention-free medium access must be provided to the joining stations. The shared spatial resources scenario is such an application. There, it is necessary to enable mobile systems arriving at a hot spot to communicate with the other approaching systems in bounded time.

Providing contention-free access to a joining station is a hard task (Schemmer and Nett 2003b). In order to request to be added to the polling list, a joining station must transmit frames to the AP; but, since the station has not yet an entry in the polling list, it has no con-tention-free bandwidth to transmit these frames. The AP cannot poll stations the addresses of which are unknown to it, and it cannot poll all stations that are potentially intending to be added to the polling list as well, as this would mean polling all addresses possibly in use. To solve the problem, we exploit specific properties of the shared spatial resources application. In that application, the protocol has to deal with a restricted and known num-ber of tracks incident to a shared spatial resource. As a newly arriving mobile system is required to get its own bandwidth allocated in bounded, short time, we can assume that at each point in time, there is at most one system per track requesting to be added to the poll-ing list. Each track has an identifier known to the mobile systems drivpoll-ing on it. A mobile system that wants to join the group provides the identifier of its track to the polling entity.

Now, the basic idea is that the AP not only sends polling frames to stations in the polling list but also broadcasts for each track a special polling frame, a so-called join poll, contain-ing the identifier of that track. Whenever a joincontain-ing system receives a join poll containcontain-ing the identifier its track it is allowed to transmit a frame to the AP. Thus, the protocol pro-vides contention-free access to joining stations (so-called JOIN service). Station use the

JOIN service only as long as they are not part of the polling list; once they receive normal, directed polling frames, they stop reacting to join polls.

There are other mobile applications that have less stringent requirements regarding the dynamic allocation of communication resources. For such applications, the problem is amenable to a more general solution: Stations can request to be added to the polling list during the CP using the contention-based DCF. Actually, this is the approach adopted by the IEEE 802.11 Standard where stations associate with the AP during the contention peri-ods and request to take part in the contention-free period while associating. The priority-based medium access procedure of the upcoming supplement 802.11e will open up new possibilities to realize medium access during the resource request phase. For example, it will be possible transmit resource requests at a higher priority under the EDCA.

When a client becomes invalid, the AP should free the resources allocated for that client to make them available for other clients. The polling protocol detects a client’s becoming invalid and indicates this event to the dynamic network scheduling layer, which changes the polling list accordingly. To implement this service (called FAIL), the protocol exploits the communication structure. It considers the clients’ replies to the polling frames as “i am alive” signs and counts the number of consecutive polling frames that were not followed by a reply from the client. If the counter assumes a value of OD + 1 the protocol sends an indication to its user. Thus, the protocol sends an indication whenever a client is invalid during an interval of length ∆Fail := OD × ∆Round + 2δm, where ∆Round is the maximum length of one polling round. More formally, this service fulfils the following two proper-ties:

Property 4-8 (Timeliness of Fail Notifications): There exists a known constant ∆Fail such that for all stations si and times t: if si is in the polling list at time t and is invalid during [t,t+ ∆Fail], then the service sends a failure notification for si during [t,t + ∆Fail].

Property 4-9 (Justification of Fail Notifications): For all stations si and all times t', if the service sends a failure notification for si at t', then there is a time t such that t < t' and si is in the polling list throughout [t,t'[ and not valid during [t,t'[.