MAC 802.11 Point Coordinator Function

by Govindan Nair


IEEE 802.11 protocol allows DCF (Distributed Coordination Function) and PCF (Point Coordination Function) to access the medium. This paper discusses the analysis of PCF traffic and DCF traffic over a BSS network. A Glomosim¹ simulator was used to simulate the PCF environment.

The MAC layer protocol of the WLAN-based Carrier Sense Multiple Access(CSMA) technology

The original 802.11 physical layer specification supported traffic rate up to 2Mbps with two subsequent extensions 802.11a and 802.11b that can support traffic up to 11Mbps and 50Mbps respectively. However MAC layer protocol remains unchanged. The IEEE802.11 standard specifies the coexistence of DCF and PCF in the MAC sub layer architecture[1]. DCF was developed for asynchronous data transmission, where all stations share the medium using the CSMA/CA protocol and a random back-off mechanism. PCF was developed for supporting time-bounded services, where a point coordinator (basically the Access Point of the Basic Service Set (BSS)) determines which station has the right to transmit. The PCF is intended for transmission of real-time traffic as well as that of asynchronous data traffic. This access method is based on a polling scheme controlled by an Access Point.

This paper examines the characteristics of traffic experiences when the wireless network supported by PCF access method and DCF access method of IEE802.11. This paper is divided as follows:

  • IEEE 802.11 DCF overview
  • IEEE 802.11 PCF overview
  • Methodology used for development
  • Simulation setup
  • Simulation results

¹ Glomosim is a simulator for mobile wireless networks, developed by UCLA. More information on this simulator is at*

IEEE 802.11 DCF overview

The DCF of IEEE 802.11 is based on CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance). In DCF, the wireless station senses the state of the medium before transmitting a packet. If the medium is idle for a time interval greater than a distributed inter-frame space (DIFS), then the station transmits a packet. Otherwise the transmission state becomes idle and is monitored by the station. Whenever the medium is judged to be idle, the station waits for a DIFS and then decreases the backoff counter in a step-wise manner. As soon as the back-off timer expires, the station transmits its packet. The receiver acknowledges the transmitted packet after a short inter-frame space (SIFS) if the packet is received correctly. Figure 1 shows the DCF mechanism.

To deal with hidden node problems, RTS (Request To Send) and CTS (Clear To Send) are specified by IEEE 802.11. If the size of the data packet is larger than the RTSThreshhold[1], RTS and CTS packets are exchanged before the data packet is transmitted. RTS/CTS contain a duration field that specifies the time necessary to complete the transaction. This information is used to update the network allocation vector (NAV), a timer used by the station receiving the RTS/CT S packet to delay access to medium.
Figure 1: DCF operation

IEEE 802.11 PCF overview

PCF in IEEE 802.11 is based on a polling scheme. This polling scheme should be either a simple round robin method or priority-based scheme. In PCF, a wireless channel has a superframe structure (contention Free Repetition Interval) as shown in Figure 2 that consists of a contention free period (CFP) and contention period (CP).

Figure 2: PCF operation
Click Figure 2 for a larger image

At the beginning of every CFP, the AP sends a beacon frame to all stations in the basic service area (BSA) after the AP confirms that the medium is idle for point-inter frame space (PIFS). PIFS is smaller than a DIFS period, but longer than the SIFS period. (IEEE 802.11 defined the duration for different physical layers.) Beacon frame contains the information on the maximum duration of the CFP, beacon interval, and BSS identifier. All stations in BSS set their NAV and not to send any packet in the CFP after receiving a beacon.

During the CFP, the AP polls each station in its polling list by sending a DATA+CF-poll frame or CF-poll frame. If a station receives a DATA+CF-Poll frame from the AP, it can respond to the AP after a SIFS period with a DATA+CF-ACK or a CF-ACK frame. If the AP receives a DATA+CF-ACK frame, it can send a DATA+CF-ACK+CF-Poll frame, or CF-ACK+ CF-Poll frame. If a station receives a CF-Poll from the AP, it can respond to the AP with DATA frame or a NULL frame. The AP continues to poll each station until it reaches the maximum duration of the CFP and the AP can terminate the CFP by sending a CF-End frame.


This section describes the PCF implementation details. The Glomosim simulation model supports 802_11 DCF mode, and modification made on 802_11.pc and 802_11.h files to support PCF mode. The station sends an associate request to join the polling list of AP. Once the AP forms the polling list, then it sends a beacon frame with CFP period and beacon interval to all stations in the BSA. The AP sends CF-Poll frame to the first station on the list. If there is no response from that station within PIFS timeframe, then the AP switches to the next station, and continues until it reaches the end of the list. If there is traffic after the PIFS time frame, then the AP polls to next station after the completion of data transfer. A station receives a poll from the AP, then the station transfers the data to the destination if there is one or idle. If a station receives CF-End from AP, then it sets the NAV = 0 and waits for a poll from AP. Selection of AP, beacon interval, CFP period, and frame size are configured in file. The above discussion is depicted in Figure 3 following:

Figure 3: PCF algorithm

Beacon Frame format [2] = frame type + duration + dest. Addr + Source Addr + bssid + FCS + Beacon interval + time stamp + Capability Info + CF Parameter list
Association Request Frame Format = frame type + duration + dest. Addr + source Addr + bssid + fcs + Capability Info + Listen Interval + SSID
CF-End/CF-End + CF-Ack Frame Format = frame type + duration + dest. Addr + bssid + fcs.

AP uses a polling scheme as round robin method. AP maintains an array of maximum number of nodes in the BSA. If a node associates with the AP, then the AP finds an empty space in its list and fills the station id on the index. The end of the list is identified by 0xca. AP polls a station in CFP period from the beginning of the list, but note that it doesn't start from lowest address of the nodes. If the AP reaches the end of the polling list, then it starts from the beginning of the list to poll, and continues this operation until it reaches the end of the CFP period. The polling list and its content is depicted in Figure 4.

Figure 4: Polling List

Simulation setup

The Glomosim simulation is used to run PCF and DCF tests. The following parameters are used to configure the simulation environment. DSR routing protocol is used to form the routes between nodes. FTP and CBR tests are performed on PCF and DCF operations of 802_11 MAC protocol. All the simulation tests were run for 100 seconds. Routing protocol DSR was used for route discovery. This test was conducted by having a random waypoint model as the mobility pattern. The other parameters used for simulation are given below in Table 1.

Table 1: Simulation Parameters

umber of Nodes10
Node PlacementUniform
Mobility PatternRandom waypoint
Radio Bandwidth2Mbps
Network ProtocolIP
Routing ProtocolDSR
Beacon Interval100MS
Terrain dimensions400 x 400 m2
Beacon Size36 bytes
Association Frame Size28 bytes
CF-ACK/End Size20 bytes
Slot Time20MS
DIFSSIFS + 2 * Slot Time
PIFSSIFS + Slot Time
Simulation time100S

Simulation Results

FTP and CBR sessions were performed between different stations of BSA. The AP doesn't generate data from itself, but it polls the stations for data transfer. The packet transfer mechanism CBR and FTP are used to compare DCF and PCF operations.

For CBR sessions, the packet size used was 256 bytes. CBR started as soon as the simulation started and ended with the simulation, using 1-second delay between packets. All client stations transfered 100 packets and server stations were supposed to receive 100 packets (due to 1 second delay to transfer next packet from client).

Figure 5: CBR PDR for DCF and PCF

In this scenario, stations 1,2,3,5 act as CBR clients and 4,6,7,9 act as CBR server, which means that the traffic is sent from CBR clients. Figure 5 shows the result of this scenario. We can observe that the packet delivery ratio is higher in PCF and lower in DCF.

For FTP sessions, the packet size was determined by the simulator. But for the PDR ratio, we need to know the number of packets transferred and number of packets received by the ftp client and server respectively. Based on those two parameters, we calculated the PDR ratio for FTP. The ftp PDR is shown in Figure 6.

The PDR ratio increases for PCF round robin scheme than DCF due to ACK piggyback on the packet.

Figure 6: FTP PDR for DCF and PCF


This paper evaluated PCF and DCF operations. The scheme using PCF round robin had better PDR ratio than DCF. The challenge in PCF is to select a good algorithm to poll the stations rather than simple round robin. Algorithm selection needs to be selected based on environment. There are proposed algorithms such as FIFO, priority based polling, AP's queue based polling (if there is a packet in the AP's queue select that station for polling). Polling is a good proposal to achieve performance in a streaming application. PCF has overhead of unnecessarily polling a station even though it doesn't have data to transfer.


This work has been performed as a project for CMPE-257: Wireless and Mobile Networking course of UCSC extension. Thanks to Professor Katia Obraczka and Kumar Viswanath for their valuable comments and feedback.


For more complete information about compiler optimizations, see our Optimization Notice.