- The Importance of Standards
- The IEEE 802 LAN Standards Family
- Introduction to the IEEE 802.11 Standard
- IEEE 802.11 Topology
- IEEE 802.11 Logical Architecture
- IEEE 802.11 Services
This chapter is from the book
This chapter is from the book
This chapter is from the book
The IEEE 802 LAN Standards Family
The IEEE 802 Local and Metropolitan Area Network Standards Committee is a major working group charted by IEEE to create, maintain, and encourage the use of IEEE and equivalent IEC/ISO standards. The IEEE formed the committee in February 1980, and this committee meets as a plenary body at least three times per year. The IEEE 802 committee produces the series of standards known as IEEE 802.x, and the JTC 1 series of equivalent standards is known as ISO 8802-nnn.
IEEE 802 includes a family of standards, as depicted in Figure 3.3. The MAC and Physical layers of the 802 standard were organized into a separate set of standards from the LLC because of the interdependence between medium access control, medium, and topology.
){kind=link}
Figure 3.3 The IEEE 802 family of standards falls within the scope of layers 1 and 2 of the OSI Reference Model.
NOTE
Visit the IEEE 802 LAN/MAN Standards Committee Web site at http://standards.ieee.org/getieee802/ for more information on 802 LAN standards.
IEEE 802.2 LLC Overview
The LLC is the highest layer of the IEEE 802 Reference Model and provides functions similar to the traditional data link control protocol: HDLC (High-Level Data Link Control). ISO/IEC 8802-2 (ANSI/IEEE Standard 802.2), dated May 7, 1998, specifies the LLC. The purpose of the LLC is to exchange data between end users across a LAN using an 802-based MAC controlled link. The LLC provides addressing and data link control, and it is independent of the topology, transmission medium, and medium access control technique chosen.
Higher layers, such as TCP/IP, pass user data down to the LLC expecting error-free transmission across the network. The LLC in turn appends a control header, creating an LLC protocol data unit (PDU). The LLC uses the control information in the operation of the LLC protocol (see Figure 3.4). Before transmission, the LLC PDU is handed down through the MAC service access point (SAP) to the MAC layer, which appends control information at the beginning and end of the packet, forming a MAC frame. The control information in the frame is needed for the operation of the MAC protocol.
){kind=link}
Figure 3.4 The LLC provides end-to-end link control over an 802.11-based wireless LAN.
IEEE 802.2 LLC Services
The LLC provides the following three services for a Network Layer protocol:
- Unacknowledged connectionless service
- Connection-oriented service
- Acknowledged connectionless service
These services apply to the communication between peer LLC layers--that is, one located on the source station and one located on the destination station. Typically, vendors will provide these services as options that the customer can select when purchasing the equipment.
All three LLC protocols employ the same PDU format that consists of four fields (see Figure 3.5). The Destination Service Access Point (DSAP) and Source Service Access Point (SSAP) fields each contain 7-bit addresses that specify the destination and source stations of the peer LLCs. One bit of the DSAP indicates whether the PDU is intended for an individual or group station(s). One bit of the SSAP indicates whether it is a command or response PDU. The format of the LLC Control field is identical to that of HDLC, using extended (7-bit) sequence numbers. The Data field contains the information from higher-layer protocols that the LLC is transporting to the destination.
){kind=link}
Figure 3.5 The LLC PDU consists of data fields that provide the LLC functionality.
The Control field has bits that indicate whether the frame is one of the following types:
- Information Used to carry user data.
- Supervisory Used for flow control and error control.
- Unnumbered Various protocol control PDUs.
Unacknowledged Connectionless Service
The unacknowledged connectionless service is a datagram-style service that does not involve any error-control or flow-control mechanisms. This service does not involve the establishment of a data link layer connection (such as between peer LLCs). This service supports individual, multicast, and broadcast addressing. This service simply sends and receives LLC PDUs with no acknowledgement of delivery. Because the delivery of data is not guaranteed, a higher layer, such as TCP, must deal with reliability issues.
The unacknowledged connectionless service offers advantages in the following situations:
If higher layers of the protocol stack provide the necessary reliability and flow-control mechanisms, then it would be inefficient to duplicate them in the LLC. In this case, the unacknowledged connectionless service would be appropriate. TCP and the ISO transport protocol, for example, already provide the mechanisms necessary for reliable delivery.
It is not always necessary to provide feedback pertaining to successful delivery of information. The overhead of connection establishment and maintenance can be inefficient for applications involving the periodic sampling of data sources, such as monitoring sensors. The unacknowledged connectionless service would best satisfy these requirements.
Case Study 3.3:
Using Unacknowledged Connectionless Service to Minimize Overhead
The executive office building of a high-rent advertising agency in Southern California has 20 sensors to monitor temperatures throughout its building as an input to the heating and air conditioning system. These sensors send short information packets every minute to an application on a centralized server that updates a temperature table in a database. The heating and air conditioning system uses this information to control the temperature in different parts of the building.
For this application, the server does not need to acknowledge the receipt of every sensor transmission because the information updates are not critical. The system can maintain a comfortable temperature throughout the building even if the system misses a temperature update from time to time.
Additionally, it is not feasible to require the sensors to establish connections with the server to send the short information packets. As a result, designers of the system chose to use the LLC unacknowledged connectionless service to minimize overhead on the network, making the limited wireless network bandwidth available to other applications.
Connection-Oriented Service
The connection-oriented service establishes a logical connection that provides flow control and error control between two stations needing to exchange data. This service does involve the establishment of a connection between peer LLCs by performing connection establishment, data transfer, and connection termination functions. The service can connect only two stations; therefore, it does not support multicast or broadcast modes. The connection-oriented service offers advantages mainly if higher layers of the protocol stack do not provide the necessary reliability and flow-control mechanisms, which is generally the case with terminal controllers.
Flow control is a protocol feature that ensures that a transmitting station does not overwhelm a receiving station with data. With flow control, each station allocates a finite amount of memory and buffer resources to store sent and received PDUs.
Networks, especially wireless networks, suffer from induced noise in the links between network stations that can cause transmission errors. If the noise is high enough in amplitude, it causes errors in digital transmission in the form of altered bits. This will lead to inaccuracy of the transmitted data, and the receiving network device may misinterpret the meaning of the information.
The noise that causes most problems with networks is usually Gaussian and impulse noise. Theoretically, the amplitude of Gaussian noise is uniform across the frequency spectrum, and it normally triggers random single-bit independent errors. Impulse noise, the most disastrous, is characterized by long quiet intervals of time followed by high amplitude bursts. This noise results from lightning and switching transients. Impulse noise is responsible for most errors in digital communication systems and generally provokes errors to occur in bursts.
To guard against transmission errors, the connection-oriented and acknowledged-connectionless LLCs use error control mechanisms that detect and correct errors that occur in the transmission of PDUs. The LLC ARQ mechanism recognizes the possibility of the following two types of errors:
Lost PDU A PDU fails to arrive at the other end or is damaged beyond recognition.
Damaged PDU A PDU has arrived, but some bits are altered.
When a frame arrives at a receiving station, the station checks whether there are any errors present by using a Cyclic Redundancy Check (CRC) error detection algorithm. In general, the receiving station will send back a positive or negative acknowledgement, depending on the outcome of the error detection process. In case the acknowledgement is lost in route to the sending station, the sending station will retransmit the frame after a certain period of time. This process is often referred to as Automatic Repeat Request (ARQ).
Overall, ARQ is best for the correction of burst errors because this type of impairment occurs in a small percentage of frames, thus not invoking many retransmissions. Because of the feedback inherent in ARQ protocols, the transmission links must accommodate half-duplex or full-duplex transmissions. If only simplex links are available because of feasibility, then it is impossible to use the ARQ technique because the receiver would not be able to notify the transmitter of bad data frames.
NOTE
When single-bit errors predominate or when only a simplex link is available, forward error correction (FEC) can provide error correction. FEC algorithms provide enough redundancy in data transmissions to enable the receiving station to correct errors without needing the sending station to retransmit the data.
FEC is effective for correcting single-bit errors, but it creates a great deal of overhead in the transmissions to protect against multiple errors, such as burst errors. The IEEE LLC, though, specifies only the use of ARQ-based protocols for controlling errors.
The following are two approaches for retransmitting unsatisfactory blocks of data using ARQ:
Continuous ARQ With this type of ARQ, often called a sliding window protocol, the sending station transmits frames continuously until the receiving station detects an error. The sending station is usually capable of transmitting a specific number of frames and maintains a table indicating which frames have been sent.
The system implementor can set the number of frames sent before stopping via configuration parameters of the network device. If a receiver detects a bad frame, it will send a negative acknowledgement back to the sending station requesting that the bad frame be sent again. When the transmitting station gets the signal to retransmit the frame, several subsequent frames may have already been sent (due to propagation delays between the sender and receiver); therefore, the transmitter must go back and retransmit the bad data frame.
There are a couple of ways the transmitting station can send frames again using continuous ARQ. One method is for the source to retrieve the bad frame from the transmit buffer and send it and all frames following it. This is called the go-back-n technique. A problem is that when n (the number of frames the transmitter sent after the bad frame plus one) becomes large, the method becomes inefficient. This is because the retransmission of just one frame means that a large number of possibly good frames will also be resent, thus decreasing throughput.
The go-back-n technique is useful in applications for which receiver buffer space is limited because all that is needed is a receiver window size of one (assuming frames are to be delivered in order). When the receive node rejects a bad frame (sends a negative acknowledgment), it does not need to buffer any subsequent frames for possible reordering while it is waiting for the retransmission, because all subsequent frames will also be sent.
An alternative to the continuous go-back-n technique is a method that selectively retransmits only the bad frame, then resumes normal transmission at the point just before getting the notification of a bad frame. This approach is called selective repeat. It is obviously better than continuous go-back-n in terms of throughput because only the bad frame needs retransmission. With this technique, however, the receiver must be capable of storing a number of frames if they are to be processed in order. The receiver needs to buffer data that has been received after a bad frame was requested for retransmission since only the damaged frame will be sent again.
- Stop-and-wait ARQ With this method, the sending station transmits
a frame, then stops and waits for some type of acknowledgment from the receiver
on whether a particular frame was acceptable or not. If the receiving station
sends a negative acknowledgment, the frame will be sent again. The transmitter
will send the next frame only after it receives a positive acknowledgment from
the receiver.
An advantage of stop-and-wait ARQ is that it does not require much buffer space at the sending or receiving station. The sending station needs to store only the current transmitted frame. However, stop-and-wait ARQ becomes inefficient as the propagation delay between source and destination becomes large. For example, data sent on satellite links normally experiences a round-trip delay of several hundred milliseconds; therefore, long block lengths are necessary to maintain a reasonably effective data rate. The trouble is that with longer frames, the probability of an error occurring in a particular block is greater. Thus, retransmission will occur often, and the resulting throughput will be lower.
Case Study 3.4:
Using Automatic Repeat Request (ARQ) to Reduce Errors
A mobile home manufacturer in Florida uses robots on the assembly line to perform welding. Designers of the robot control system had to decide to use ARQ or FEC for controlling transmission errors between the server and the robots. The company experiences a great deal of impulse noise from arc welders and other heavy machinery.
In the midst of this somewhat hostile environment, the robots require error-free information updates to ensure they function correctly. Designers of the system quickly ruled out the use of FEC because of the likely presence of burst errors due to impulse noise. ARQ, with its capability to detect and correct frames having lots of bit errors, was obviously the best choice.
Acknowledged Connectionless Service
As with the The unacknowledged connectionless service, the acknowledged connectionless service does not involve the establishment of a logical connection with the distant station. But the receiving stations with the acknowledged version do confirm successful delivery of datagrams. Flow and error control is handled through use of the stop-and-wait ARQ method.
The acknowledged connectionless service is useful in several applications. The connection-oriented service must maintain a table for each active connection for tracking the status of the connection. If the application calls for guaranteed delivery, but there is a large number of destinations needing to receive the data, then the connection-oriented service may be impractical because of the large number of tables required. Examples that fit this scenario include process control and automated factory environments that require a central site to communicate with a large number of processors and programmable controllers. In addition, the handling of important and time-critical alarm or emergency control signals in a factory would also fit this case. In all these examples, the sending station needs an acknowledgment to ensure successful delivery of the data; however, an urgent transmission cannot wait for a connection to be established.
NOTE
A company having a requirement to send information to multiple devices needing positive acknowledgement of the data transfer can use the acknowledged connectionless LLC service. For example, a marina may find it beneficial to control the power to different parts of the boat dock via a wireless network. Of course, the expense of a wireless network may not be justifiable for this application alone.
Other applications, such as supporting data transfers back and forth to the cash register at the gas pump and the use of data collection equipment for inventorying rental equipment, can share the wireless network to make a more positive business case. For shutting off the power on the boat dock, the application would need to send a message to the multiple power controllers, and then expect an acknowledgement to ensure the controller receives the notification and that the power is shut off. For this case, the connectionless transfer, versus connection-oriented, makes more sense because it wouldn't be feasible to make connections to the controllers to support such a short message.
LLC/MAC Layer Service Primitives
Layers within the 802 architecture communicate with each other via service primitives having the following forms:
Request A layer uses this type of primitive to request that another layer perform a specific service.
Confirm A layer uses this type of primitive to convey the results of a previous service request primitive.
Indication A layer uses this type of primitive to indicate to another layer that a significant event has occurred. This primitive could result from a service request or from some internally generated event.
Response A layer uses this type of primitive to complete a procedure initiated by an indication primitive.
These primitives are an abstract way of defining the protocol, and they do not imply a specific physical implementation method. Each layer within the 802 model uses specific primitives. The LLC layer communicates with its associated MAC layer through the following specific set of service primitives:
MA-UNITDATA.request The LLC layer sends this primitive to the MAC layer to request the transfer of a data frame from a local LLC entity to a specific peer LLC entity or group of peer entities on different stations. The data frame could be an information frame containing data from a higher layer or a control frame (such as a supervisory or unnumbered frame) that the LLC generates internally to communicate with its peer LLC.
MA-UNITDATA.indication The MAC layer sends this primitive to the LLC layer to transfer a data frame from the MAC layer to the LLC. This occurs only if the MAC has found that a frame it receives from the Physical layer is valid and has no errors and the destination address indicates the correct MAC address of the station.
MA-UNITDATA-STATUS.indication The MAC layer sends this primitive to the LLC layer to provide status information about the service provided for a previous MA-UNITDATA.request primitive.