Wireless LAN Standard

A wireless LAN standard has been in the making since 1990. In mid-1997, the IEEE 802.11 committee finally made its most significant progress in issuing a standard. The standard defines a transmission rate of up to 2 Mbps over infrared or radio frequency bands. The standard also includes the media access control protocol Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), which means devices implementing the standard can interoperate with wired Ethernet LANs.

The new standard specifies a choice of three different physical layers. Members of the 802.11 working group decided that a choice of physical-layer implementations was necessary so systems designers and integrators could choose a technology that matches the price, performance, and operations profile of a specific application.

The standard provides for an optical-based physical-layer implementation that uses infrared light to transmit data. It also provides two radio frequency (RF) based physical-layer choices: Direct Sequence Spread Spectrum (DSSS) and Frequency Hopping Spread Spectrum (FHSS). Both operate in the 2.4-GHz ISM band.

In the standard, a 2-Mbps peak data rate is specified for DSSS with optional fallback to 1 Mbps in very noisy environments. The standard defines the FHSS implementation to operate at 1-Mbps and allows for optional 2-Mbps operation in very clean environments.

The 802.11 media access control (MAC) can work seamlessly with standard Ethernet via a bridge to ensure that wireless and wired nodes on an enterprise LAN are logistically indistinguishable and can interoperate. The 802.11 MAC is necessarily different from the wired Ethernet MAC, but any such differences are masked by an access point that connects a wireless LAN channel to a wired LAN backbone.

The wireless LAN standard uses a carrier sense multiple access with collision-avoidance MAC scheme, whereas standard Ethernet uses a collision-detection scheme.

The roaming provisions built into 802.11 also provide several advantages. The 802.11 standard includes mechanisms to allow a client to roam among multiple access points that can operate on the same or separate channels. For example, an access point transmits a beacon signal at regular intervals that includes a time stamp for client synchronization, a traffic indication map, and indication of supported data rates. Roaming clients use the beacon to gauge the strength of their existing connection to an access point. If the connection is weak, the roaming station can attempt to associate itself with a new access point.

Although the 802.11 standard addresses roaming, it is with the understanding that all the access points in an installation are manufactured by the same vendor. The standard does not ensure that clients can roam among access points from different vendors. With the advent of 802.11 products, however, users may want to mix and match access points. For example, some customers might need standard commercial-grade bridges in the office but want ruggedized bridges for the factory floor.

To address multivendor roaming, Aironet Corp., Digital Ocean, Inc., and Lucent have collaborated to develop the Inter Access Point Protocol (IAPP) specification. That will extend the 802.11 multivendor interoperability benefits with comprehensive roaming protocols. Several others, including IBM, have voiced support for IAPP as a necessary step toward true multivendor interoperability.

The 802.11 specification adds features to the MAC that can maximize battery life in portable clients via power-management schemes. Power management causes problems with wireless LAN systems because typical power-management schemes place a system in sleep mode (low or no power) when no activity occurs for a user-definable time period. This can cause a sleeping system to miss critical data transmissions. To support clients that periodically enter sleep mode, the 802.11 standard specifies that access points include buffers to queue messages.

The 802.11 standard also addresses data security. The standard defines a mechanism through which the wireless LANs can achieve Wired Equivalent Privacy (WEP). The optional WEP mechanism is especially important because RF transmissions—even spread-spectrum transmissions—can be intercepted more easily than wired transmissions.

The next step in the evolution of the 802.11 standard will likely be the incorporation of higher data rates, expected in the 10 Mbps and above range in the 5.2-GHz band. The higher speed could encourage development of such applications as streaming video, telephony, and multimedia.

Real-Time Transport Protocol | VoIP Standards and Specifications

The RTP provides end-to-end network transport functions suitable for applications transmitting real-time audio or video packets over multicast or unicast network services. It was developed by the IETF and is used with the H.323’s recommended H.225 protocols to provide reliable communications. RTP by itself does not address resource reservation and does not guarantee QoS for real-time services. The packet transport is supplemented by a control protocol (RTCP) that monitors data delivery in a manner scalable to large multicast networks and provides minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. The following are the elements of RTP.

RTP Payload

The media payload is transported by RTP in a packet, such as audio samples or compressed video data. The payload format and interpretation are beyond the scope of this document.

RTP Packet

A packet consists of the fixed RTP header, a possibly empty list of contributing sources (see below), and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined. Typically, one packet of the underlying protocol contains a single RTP packet, but several RTP packets may be contained, if permitted by the encapsulation method.

RTCP Packet

A control packet consists of a fixed header part similar to that of RTP packets, followed by structured elements that depend on the RTCP packet type. Typically, multiple RTCP packets are sent together as a compound RTCP packet in a single packet of the underlying protocol; this is enabled by the length field in the fixed header of each RTCP packet. Figure 1 shows the RTP header.

Figure 1: The RTP header.

The RTP fixed header fields have certain functions. V (version): Identifies the RTP version. P (padding): When set, the packet contains one or more additional padding octets at the end that are not part of the payload. X (extension bit): When set, the fixed header is followed by exactly one header extension with a defined format. CSRC count: Contains the number of CSRC identifiers that follow the fixed header. M (marker): The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. Payload type: Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means. Sequence number: Increments by one for each RTP data packet sent and may be used by the receiver to detect packet loss and restore packet sequence. Timestamp: Reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. The resolution of the clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). SSRC (synchronization source): Identifies the synchronization source. This identifier is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. CSRC (contributing source): Contributing source identifiers list. Identifies the contributing sources for the payload contained in this packet.

VoIP Standards and Specifications

Internet telephony is the transport of telephone calls over the Internet. The process of supporting voice calls over the Internet using the Internet communications protocol IP, is known as Voice over IP (VoIP). The first business customer implementations of VoIP were long distance calls over an IP WAN as an alternative to traditional PSTN trunk facilities. Network gateway servers had converted PBX TDM/PCM signals into IP format for transport through a router network. VoIP offered no new features or functions, merely an alternative means of transport. VoIP was not used for station-to-station on-premises calls, and IP control signaling was not used for call set-up or feature activation. As the new technology evolved to include PBX system desktop call control signaling and communications over an IP network infrastructure, ToIP gradually started to replace VoIP. VoIP is still the most commonly used term, although ToIP is being used more to describe the workings of an IP-PBX system.

There are several sets of VoIP communications protocols that can be used by an IP-PBX system for call control signaling and communications transmission. Circuit switched PBXs were based on proprietary call control signaling to the digital desktops and used TDM/PCM standards for transmission across internal switching networks and to network with other communications systems over PSTN trunk carrier facilities. It was the intention of the early IP-PBX system developers to use open standard communications protocols over packet switched networks as a counter to the closed, proprietary nature of circuit switched PBXs. The communications protocol of choice used by most first-generation IP-PBX system designers was the ITU-T H.323 series of protocols. A competing standards body, the IEFT, developed Session Initiation Protocol (SIP). Many IP-PBX manufacturers are planning to offer SIP versions of their current systems based on H.323, but the first product offerings will not be commercially available until later this year. SIP may offer several advantages over the ITU-T’s recommendation, but the momentum of H.323 will delay saturation of the IEFT’s solution to VoIP communications systems for several years according to the major IP-PBX manufacturers.

ITU-T H.323

ITU-T H.323 is a set of protocols for voice, video, and data conferencing over packet switched networks such as Ethernet LANs and the Internet that do not provide a guaranteed QoS. The H.323 protocol stack is designed to operate above the transport layer of the underlying network. H.323 uses the IP for internetwork conferencing.

H.323 was originally developed as one of several videoconferencing recommendations issued by the ITU-T. The H.323 standard is designed to allow clients on H.323 networks to communicate with clients on other videoconferencing networks. The first version of H.323 was issued in 1996 and designed for use with Ethernet LANs. H.323 Version 1 borrowed much of its multimedia conferencing aspects from other H.32x series recommendations. H.323 is part of a larger series of communications standards that enable videoconferencing across a range of networks. This series also includes H.320 and H.324, which address ISDN and PSTN communications, respectively.

H.323 is known as a broad and flexible recommendation. Although H.323 specifies protocols for real-time point-to-point voice communication between two terminals on a packet switched network, it also includes support of internetwork multipoint conferencing among terminals that support not only audio (voice) but also video and data communications.

H.323 recommendations can be summarized as followed.

Point-to-Point and Multipoint Conferencing Support

H.323 conferences may be set up between two or more clients without any specialized multipoint control software or hardware. If an MCU is used, H.323 supports a flexible topology for multipoint conferences. A multipoint conference can be centralized so that new participants can join all the others in the conference. A multipoint conference may also be decentralized so that new participants can elect to join one or more participants, but not all participants, in the conference. The centralized approach is a star topology; the decentralized one is a mesh topology.

Internetwork Interoperability

H.323 clients are interoperable with clients on circuit switched networks such as those based on recommendations H.320 (ISDN), H.321 (ATM), and H.324 (PSTN/Wireless). For example, it is possible to call from an H.323 client to a regular telephone on a PSTN. At the corporate level, this internetworking capability allows enterprises to migrate voice and video from existing networks to their own data networks.

Heterogeneous Client Capabilities

An H.323 client must support audio communication. Support of video and data communications is optional. During call set-up, capabilities are exchanged and communication established based on the lowest common denominator.

Audio and Video Codecs

H.323 specifies a required audio and video codec, but there is no restriction on the use of other codecs. Clients are allowed to decide which codec to use.

Management and Accounting Support

H.323 calls can be restricted on a network based on the number of calls already in progress, bandwidth limitations, or time restrictions. Policy management guidelines are used for H.323 traffic control. H.323 also provides accounting facilities that can be used for billing purposes.

Security

H.323 provides authentication, integrity, privacy, and nonrepudiation support.

Supplementary Services

Recommendation H.323 provides a basic framework for the development of application services, similar to the call processing features typically supported by a PBX system. This effort began with H.323 Version 2, which standardized a few services with recommendation H.450, including call transfer and call forwarding.