Other signaling protocols include Media Gateway Control Protocol (MGCP) and Media Gateway Control (MeGaCo). These are just two examples, and I will briefly touch upon the two of these.
The Media Gateway Control Protocol is a merger of the Internet Protocol Device Control (IPDC) and the Signal Gateway Control Protocol (SGCP). It very closely resembles SIP functionality. IDPC is a suite of protocols that can, individually or together, perform connection, control, media control, and signaling transports between the circuit-switched network and the Internet. Signal Gateway Control Protocol (SGCP) is a UDP-based protocol designed to address the concept of a network that combines voice and data onto a single packet-switched IP network operating at a low level. There are two main components of a MGCP, the Call Agent and the Gateway. MGCP uses SDP to negotiate media streams and frames the media streams using RTP.
Megaco is a separate implementation of the Media Gateway Control Protocol. It is designed for controlling Media Gateways on IP networks and the PSTN. It provides voice over IP and faxing services between IP networks and PSTN. It is a joint project from both the IETF and the ITU. MegaCo is also known as H.248.
Showing posts with label 920-803. Show all posts
Showing posts with label 920-803. Show all posts
Components of a SIP Network
As I mentioned previously, devices on a SIP network are called User Agents. A User Agent Client and a User Agent Server are both required for communication.
SIP defines three server elements: a Registrar, a Proxy Server, or a Redirect Server. A Registrar server accepts REGISTER requests and is typically co-located with a proxy server or a redirect server. It can offer location services, and registers SIP parties in a SIP domain. A Proxy Server functions as both a server and a client that makes and receives requests on behalf of other SIP clients. It supports requests locally or forwards them to other servers. It can interpret and re-write a SIP request message before forwarding it to another server or User Agent. A Redirect server will accept SIP requests, read the information and map the address in the request to the next hop. It will then return an appropriate message to the client. The client can then directly contact the appropriate next hop. It does not forward SIP requests to other servers and it does not accept calls. A SIP Redirect Server will only respond with 3xx series responses. It is important to note that these three types of SIP servers are logically, and not physically distinct.
In addition to the three server types and the User Agents that are present in a SIP Network, there are also Session Border Controllers (SBC) and gateways on the network. A Session Border Controller is inserted into the signaling path and handles the signaling and media being sent across the network. The SBC can also perform anti-tromboning functions. Tromboning occurs when two devices on the same subnet are both trying to connect through a third server when they should be allowed to connect directly. By directing the two devices to speak directly to each other the trunks can be opened up for use by other devices. An SBC can also implement transcoding when required, but this is not recommended, as was discussed previously. An SBC can restrict call flow or allow connections to exist where they would not have otherwise been able to exist (due to a firewall between the two end-points, or other security policies). It is also interesting to note that the Session Border Controller can enforce interception of network sessions. This is interesting because, without the SBC, there would be no way to intercept the flow of data between two SIP devices as can be required by various law enforcement agencies. This is because under normal circumstances SIP will try to have end-points communicate directly with each other. A Gateway simply acts as a connecting point between a SIP network and a dissimilar network, such as H.323 or PSTN. Any calls that are being sent out to the PSTN will have to go through a gateway.
SIP defines three server elements: a Registrar, a Proxy Server, or a Redirect Server. A Registrar server accepts REGISTER requests and is typically co-located with a proxy server or a redirect server. It can offer location services, and registers SIP parties in a SIP domain. A Proxy Server functions as both a server and a client that makes and receives requests on behalf of other SIP clients. It supports requests locally or forwards them to other servers. It can interpret and re-write a SIP request message before forwarding it to another server or User Agent. A Redirect server will accept SIP requests, read the information and map the address in the request to the next hop. It will then return an appropriate message to the client. The client can then directly contact the appropriate next hop. It does not forward SIP requests to other servers and it does not accept calls. A SIP Redirect Server will only respond with 3xx series responses. It is important to note that these three types of SIP servers are logically, and not physically distinct.
In addition to the three server types and the User Agents that are present in a SIP Network, there are also Session Border Controllers (SBC) and gateways on the network. A Session Border Controller is inserted into the signaling path and handles the signaling and media being sent across the network. The SBC can also perform anti-tromboning functions. Tromboning occurs when two devices on the same subnet are both trying to connect through a third server when they should be allowed to connect directly. By directing the two devices to speak directly to each other the trunks can be opened up for use by other devices. An SBC can also implement transcoding when required, but this is not recommended, as was discussed previously. An SBC can restrict call flow or allow connections to exist where they would not have otherwise been able to exist (due to a firewall between the two end-points, or other security policies). It is also interesting to note that the Session Border Controller can enforce interception of network sessions. This is interesting because, without the SBC, there would be no way to intercept the flow of data between two SIP devices as can be required by various law enforcement agencies. This is because under normal circumstances SIP will try to have end-points communicate directly with each other. A Gateway simply acts as a connecting point between a SIP network and a dissimilar network, such as H.323 or PSTN. Any calls that are being sent out to the PSTN will have to go through a gateway.
Session Initiation Protocol
Session Initiation Protocol (SIP) is an alternative to H.323. It was created for the distribution of multimedia content. SIP supports a variety of architectures and protocols and is modeled after HTTP using plain text, which allows for easy packet inspection by administrators. It uses a Request-Response model (or INVITE model). It supports several types of proxy servers and operates on the Application layer of the OSI model. It leverages separate protocols that can be used without making any core protocol changes. It is totally independent of the voice path.
Every device on a SIP network is called a User Agent. A User Agent can serve two roles: If it is sending a request it is a User Agent Client (UAC) and if it is receiving a request it is a User Agent Server (UAS).
SIP supports two basic types of messages: Requests and Responses. SIP Requests and Responses are defined in the IETF RFC 3261. Every SIP message uses a start line that indicates if the message is a request or a response, as well as some other information including the version of SIP that is being used. I will start by going over requests and then discuss responses.
A request uses one of six methods. These methods are REGISTER, INVITE, ACK, CANCEL, BYE, and OPTIONS. REGISTER is quite obvious – it sends a message to a SIP Registration Server notifying it of its current IP address, as well as the URLs at which it wants to receive calls. INVITE is also fairly obvious; it indicates that a device wants to invite another user or service to participate in the session. ACK is an acknowledgement that the UAC has received a request, confirming that a message has been exchanged. CANCEL is used to terminate a pending request, but it does not terminate any already accepted calls. BYE end the call (this is what happens when you hang up). OPTIONS will query the capabilities of the UAS (the receiving end of a call) without setting up a call. There are additional SIP Extensions, defined by other RFCs, that include UPDATE (allowing the client to update the parameters of a session), INFO (carrying session-related control information during a session), PRACK (provides a Provisional Acknowledgement), and SUBSCRIB/NOTIFY (asking for notification from a remote node indicating that certain events have occurred). A request starts off with the method of the request, followed by the request URL and the SIP version.
A Response has a large number of possibilities. These possibilities are all covered in RFC 3261 as well. All responses have a three-digit code to identify what the response is. They are grouped into six categories, with each category being easily identified by the first digit in the code. A code beginning with a 1 is called a Provisional response, and indicates that a request has been received and is currently being processed, also called an informational response. A code that starts with 2 is a successful response, indicating that the UAS has received the request and understands it. A code beginning with 3 is a redirection response, indicating that further actions are required, usually by the sending User Agent, to complete the request. A 4 code indicates a failure. Often this is caused by bad syntax or an inability of the UAS to complete the request. A code starting with 5 is a server failure, indicating that the server was unable to process a request even though it looked like the request was valid. A code beginning with 6 indicates a global failure. Each of these six categories has a number of possible responses, as is indicated by the two remaining digits.
SIP uses two protocols to establish a conference call session: Session Announcement Protocol (SAP) and Session Description Protocol (SDP). SAP creates, modifies, and terminates sessions. It announces a conference session by periodically multicasting an announcement to a well-known multicast address port. SDP is a component of SAP, but can be used with RTSP, SIP, and as a standalone protocol. It is used to convey information to SIP entities and let them join and participate in a SIP session. SDP contains the purpose of the session, the name of the session, the media type pertaining to the session, formatted information for the session, and pertinent IP addresses and port numbers for the session.
Every device on a SIP network is called a User Agent. A User Agent can serve two roles: If it is sending a request it is a User Agent Client (UAC) and if it is receiving a request it is a User Agent Server (UAS).
SIP supports two basic types of messages: Requests and Responses. SIP Requests and Responses are defined in the IETF RFC 3261. Every SIP message uses a start line that indicates if the message is a request or a response, as well as some other information including the version of SIP that is being used. I will start by going over requests and then discuss responses.
A request uses one of six methods. These methods are REGISTER, INVITE, ACK, CANCEL, BYE, and OPTIONS. REGISTER is quite obvious – it sends a message to a SIP Registration Server notifying it of its current IP address, as well as the URLs at which it wants to receive calls. INVITE is also fairly obvious; it indicates that a device wants to invite another user or service to participate in the session. ACK is an acknowledgement that the UAC has received a request, confirming that a message has been exchanged. CANCEL is used to terminate a pending request, but it does not terminate any already accepted calls. BYE end the call (this is what happens when you hang up). OPTIONS will query the capabilities of the UAS (the receiving end of a call) without setting up a call. There are additional SIP Extensions, defined by other RFCs, that include UPDATE (allowing the client to update the parameters of a session), INFO (carrying session-related control information during a session), PRACK (provides a Provisional Acknowledgement), and SUBSCRIB/NOTIFY (asking for notification from a remote node indicating that certain events have occurred). A request starts off with the method of the request, followed by the request URL and the SIP version.
A Response has a large number of possibilities. These possibilities are all covered in RFC 3261 as well. All responses have a three-digit code to identify what the response is. They are grouped into six categories, with each category being easily identified by the first digit in the code. A code beginning with a 1 is called a Provisional response, and indicates that a request has been received and is currently being processed, also called an informational response. A code that starts with 2 is a successful response, indicating that the UAS has received the request and understands it. A code beginning with 3 is a redirection response, indicating that further actions are required, usually by the sending User Agent, to complete the request. A 4 code indicates a failure. Often this is caused by bad syntax or an inability of the UAS to complete the request. A code starting with 5 is a server failure, indicating that the server was unable to process a request even though it looked like the request was valid. A code beginning with 6 indicates a global failure. Each of these six categories has a number of possible responses, as is indicated by the two remaining digits.
SIP uses two protocols to establish a conference call session: Session Announcement Protocol (SAP) and Session Description Protocol (SDP). SAP creates, modifies, and terminates sessions. It announces a conference session by periodically multicasting an announcement to a well-known multicast address port. SDP is a component of SAP, but can be used with RTSP, SIP, and as a standalone protocol. It is used to convey information to SIP entities and let them join and participate in a SIP session. SDP contains the purpose of the session, the name of the session, the media type pertaining to the session, formatted information for the session, and pertinent IP addresses and port numbers for the session.
Key components of an H.323 Network
There are four major components to an H.323 network. These are Gateways, Gatekeepers, Multi-Point Control Units (MCUs), and IP Terminals and Clients. I would like to briefly discuss each of these components.
First of all, the H.323 Gateway transforms audio received from a device into a format that the data network can use. It has built-in intelligence to select CODECs and adjust protocols and timing between dissimilar computer systems and Voice over Data networks. It can connect divergent networks by translating signaling protocols and converting media formats, including Analog-to-IP and Digital-to-IP. Internal and external junctures are both required.
The Gatekeeper provides call control services. It maps phone numbers to IP addresses and translates between phone numbers and IP addresses. It provides call setup and trade-in functions, as well as managing bandwidth. Every end-point in a zone must register with the gatekeeper.
Multi-Point Control Units are actually comprised of two components. The Multi-Point Controller (MC) controls one or more Multi-Point Processors (MP).The MP encodes and routes audio and video data streams between device end points. There are two types of conferences that can be managed by the MCU: Centralized and Decentralized. Centralized conferences, including conference calls, use the MCU to create and control the conference. Participating phones or devices send their audio, video, data, and control streams to the MCU. This can place a very heavy load on the MCU as it must replicate the streams to all participating devices in the conference. The MC tracks the capabilities of each device and makes sure that the streams flowing to each terminal are appropriate for that terminal, while the MP can convert the streams between different CODECs and bit rates depending on the capabilities of each end-point. Decentralized conferencing works a little differently. Participating devices use multicast to send their streams directly to each other. The MCU ensures that each device is conforming to standards. This reduces the amount of bandwidth that is required to the MCU, but each terminal has increased bandwidth requirements. The terminals use H.245 to tell the MC how many information streams they can process simultaneously.
Finally, I would like to discuss the IP Terminals and clients. An H.323 terminal is any end-point that can support real-time two-way communication with another H.323 terminal, gateway, or MCU. There are three types of information flows that can be passed to an H.323 terminal: Audio, Data, and Video. Every terminal must register with a gatekeeper upon startup. Once the terminal is registered with the gatekeeper it is able to make or receive calls, depending of course upon the permissions it has and the setup of the network. When a terminal attempts to place a call it sends an Admission Request Signal (RAS). The gatekeeper responds with an Admission Confirmation Message (ACF). The terminal is then able to set up the call with the gatekeeper. The gatekeeper will send setup information to the receiving terminal. The receiving terminal will then have to send an ARQ of its own to the gatekeeper, and receive the ACF response. At this point both phones are alerted that the call can be completed, and the call is connected.
First of all, the H.323 Gateway transforms audio received from a device into a format that the data network can use. It has built-in intelligence to select CODECs and adjust protocols and timing between dissimilar computer systems and Voice over Data networks. It can connect divergent networks by translating signaling protocols and converting media formats, including Analog-to-IP and Digital-to-IP. Internal and external junctures are both required.
The Gatekeeper provides call control services. It maps phone numbers to IP addresses and translates between phone numbers and IP addresses. It provides call setup and trade-in functions, as well as managing bandwidth. Every end-point in a zone must register with the gatekeeper.
Multi-Point Control Units are actually comprised of two components. The Multi-Point Controller (MC) controls one or more Multi-Point Processors (MP).The MP encodes and routes audio and video data streams between device end points. There are two types of conferences that can be managed by the MCU: Centralized and Decentralized. Centralized conferences, including conference calls, use the MCU to create and control the conference. Participating phones or devices send their audio, video, data, and control streams to the MCU. This can place a very heavy load on the MCU as it must replicate the streams to all participating devices in the conference. The MC tracks the capabilities of each device and makes sure that the streams flowing to each terminal are appropriate for that terminal, while the MP can convert the streams between different CODECs and bit rates depending on the capabilities of each end-point. Decentralized conferencing works a little differently. Participating devices use multicast to send their streams directly to each other. The MCU ensures that each device is conforming to standards. This reduces the amount of bandwidth that is required to the MCU, but each terminal has increased bandwidth requirements. The terminals use H.245 to tell the MC how many information streams they can process simultaneously.
Finally, I would like to discuss the IP Terminals and clients. An H.323 terminal is any end-point that can support real-time two-way communication with another H.323 terminal, gateway, or MCU. There are three types of information flows that can be passed to an H.323 terminal: Audio, Data, and Video. Every terminal must register with a gatekeeper upon startup. Once the terminal is registered with the gatekeeper it is able to make or receive calls, depending of course upon the permissions it has and the setup of the network. When a terminal attempts to place a call it sends an Admission Request Signal (RAS). The gatekeeper responds with an Admission Confirmation Message (ACF). The terminal is then able to set up the call with the gatekeeper. The gatekeeper will send setup information to the receiving terminal. The receiving terminal will then have to send an ARQ of its own to the gatekeeper, and receive the ACF response. At this point both phones are alerted that the call can be completed, and the call is connected.
The H.323 Protocol Stack
I would like to go over some of the components of the H.323 protocol stack next. The H.323 protocol stack is very complex and includes a number of components.
There are five main components to an H.323 stack. These are the Control section, the Data section, the Audio section, the Video section, and the Audio/Video Control section.
The Control section and the Data section are sent using TCP. The Control section uses H.245 control multimedia communication. This can include such things as opening and closing audio channels, negotiating the audio and video CODECs, sending and receiving DTMF signals, and managing information lights (i.e. message waiting, etc.). The Data section uses the T.120 standard to send communications and application protocols and services that support real-time multi-point communication. T.120 is a real-time data protocol and allows for communication of data such as a virtual whiteboard or other multimedia communications.
The remaining components of the H.323 stack are sent using UDP. The Audio portion of the stack includes the audio CODEC. H.323 supports the main CODECs discussed previously: G.711, G.722, G.723.1, G.728, and G.729a/b. I won’t go into detail about these CODECs again, but this is the portion of the stack that contains the actual voice data.
The Video portion of the stack indicates the video CODEC that is used for video calls. H.323 supports the H.26x family of video CODECs. These CODECs were designed by the International Telecommunications Union for use with a variety of applications, and were incorporated into H.323 for use with video conferencing. H.261 is a video stream for transport using the Real-Time Transport Protocol with any underlying protocols that carry RTP. H.263 specifies the payload format for encapsulating H.263 bit streams in RTP.
Finally, we come to the Audio/Video Control section. This is further subdivided into two sections – RTCP and RTP. I have discussed both RTCP and RTP previously, and it should come as no surprise that these two components are a part of the H.323 stack. RTCP is used by RTP to control and synchronize the streaming of audio and video. It provides feedback information to the source to adapt flow to changing network conditions.
That just about covers the information about the H.323 Protocol Stack. Further information is always available with a simple Google search (or Bing, if you so desire…but I wouldn’t recommend it!).
There are five main components to an H.323 stack. These are the Control section, the Data section, the Audio section, the Video section, and the Audio/Video Control section.
The Control section and the Data section are sent using TCP. The Control section uses H.245 control multimedia communication. This can include such things as opening and closing audio channels, negotiating the audio and video CODECs, sending and receiving DTMF signals, and managing information lights (i.e. message waiting, etc.). The Data section uses the T.120 standard to send communications and application protocols and services that support real-time multi-point communication. T.120 is a real-time data protocol and allows for communication of data such as a virtual whiteboard or other multimedia communications.
The remaining components of the H.323 stack are sent using UDP. The Audio portion of the stack includes the audio CODEC. H.323 supports the main CODECs discussed previously: G.711, G.722, G.723.1, G.728, and G.729a/b. I won’t go into detail about these CODECs again, but this is the portion of the stack that contains the actual voice data.
The Video portion of the stack indicates the video CODEC that is used for video calls. H.323 supports the H.26x family of video CODECs. These CODECs were designed by the International Telecommunications Union for use with a variety of applications, and were incorporated into H.323 for use with video conferencing. H.261 is a video stream for transport using the Real-Time Transport Protocol with any underlying protocols that carry RTP. H.263 specifies the payload format for encapsulating H.263 bit streams in RTP.
Finally, we come to the Audio/Video Control section. This is further subdivided into two sections – RTCP and RTP. I have discussed both RTCP and RTP previously, and it should come as no surprise that these two components are a part of the H.323 stack. RTCP is used by RTP to control and synchronize the streaming of audio and video. It provides feedback information to the source to adapt flow to changing network conditions.
That just about covers the information about the H.323 Protocol Stack. Further information is always available with a simple Google search (or Bing, if you so desire…but I wouldn’t recommend it!).
Components and Structure of a WLAN
There are several main components of a WLAN. I would like to briefly touch upon these before I go any further.
First of all, there must be Mobile Units (MUs). These are also called stations, and can include any device that can associate with an Access Point and gain access to the wireless network. This can include laptops, PDAs, telephones, desktop PCs, and any other device that has a wireless network adapter. A WLAN MU must have a WLAN NIC installed to send and receive WLAN traffic. WLAN MUs must also include one ore more client software models that provide some extra functionality within the network.
Access Points, or APs, allow the MU to connect to the wired network by providing a point of access. Some APs are centrally managed, while others are managed individually. In a traditional WLAN implementation, each AP maintains its own intelligence. Independent servers located on a switched network provide security, such as traffic shaping and filtering, as well as SNMP management for the AP.
Access Ports are the next component I would like to mention. The wireless switch collects management intelligence from individual access points. By using access points to gather data tat is then moved to the switch, access points become smart antennas, or Access Ports, that are centrally managed from the switch. Because Access Ports receive their intelligence from the switch, upgrades are as simple as upgrading the software on the switch.
WLAN switches provide management, additional security, and campus area mobility for the WLAN.
Gateway and VPN Termination Points provide additional security for WLAN MUs to connect to the network. Some WLAN switches have VPN functionality built right in, so two separate boxes are not required.
Other servers can be required for a WLAN implementation. These are often shared with the wired network, and include DHCP servers, DNS Servers, and Remote Authentication Dial-In User Servers (RADIUS).
There are three main configurations for a WLAN: The Basic Service Set (BSS), the Extended Service Set (ESS), and the Independent Basic Service Set (IBSS). The BSS requires one access point for all MUs on the network. An ESS has multiple access points that can be accessed by multiple MUs on the network. The IBSS does not have an access point; instead devices connect directly to each other. This is often referred to as an Ad-Hoc Wireless connection.
Using Radio Frequencies, MUs connect to Access Points (or to each other in an ad-hoc network). Access points send out a beacon at frequent and periodic intervals. Mobile Units will connect to APs by scanning the airwaves to find available APs. Once the MU finds an AP that it wants to connect to it will begin the process of authentication and association.
There are two types of communications that are used by MUs to connect to APs. The first is narrow band communications. Narrow Band Communications use only enough of the RF to send information. It must be a high powered signal to be heard over other signals in the area. The higher power can lead to RF noise. It can also be easily jammed, and is susceptible to interference from other devices. Spread Spectrum is a more widely used technology. It uses a broader frequency range to send information at a lower power density. It is less susceptible to interference and is less likely to be intercepted than narrow band. Spread Spectrum can be further divided into two technologies: Frequency Hopping Spread Spectrum (FHSS) and Direct Sequence Spread Spectrum (DSSS). FHSS uses a pattern of frequency hopping to send data. This pattern is repeated until all frequencies in the band have been used and the hop sequence is complete, at which point the sequence is restarted. There are four components to a FHSS system that allow it to communicate: Channels, Hop Sequence, Dwell Time, and Hop Time. FHSS is not very widely used by devices, and is not commonly used in WLAN deployments. Some technologies, such as Bluetooth, do use FHSS. DSSS is the most common method of deploying a WLAN. It has a lower overall cost, more available hardware, and a better price-to-throughput ratio. DSSS sending stations multiply the information bit with a continuous string of pseudo-noise signals (Chips, discussed previously). The process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code, which determines how much spreading (how much of the frequency range is used) will occur. It also has information that determines the data rate of transmission.
In the United States, the FCC has allocated two frequency ranges for wireless devices. The first is ISM, which operates in the 2.4 GHz – 2.4835 GHz range. The second range is the UNII range, operating from 5 GHz – 6 GHz. In Europe and the rest of the world there are different regulations regarding these frequency ranges, but they are very close. The FCC also regulates how much power output devices can have to 100 mW, but has no further restrictions on FHSS and DSSS Power Density.
First of all, there must be Mobile Units (MUs). These are also called stations, and can include any device that can associate with an Access Point and gain access to the wireless network. This can include laptops, PDAs, telephones, desktop PCs, and any other device that has a wireless network adapter. A WLAN MU must have a WLAN NIC installed to send and receive WLAN traffic. WLAN MUs must also include one ore more client software models that provide some extra functionality within the network.
Access Points, or APs, allow the MU to connect to the wired network by providing a point of access. Some APs are centrally managed, while others are managed individually. In a traditional WLAN implementation, each AP maintains its own intelligence. Independent servers located on a switched network provide security, such as traffic shaping and filtering, as well as SNMP management for the AP.
Access Ports are the next component I would like to mention. The wireless switch collects management intelligence from individual access points. By using access points to gather data tat is then moved to the switch, access points become smart antennas, or Access Ports, that are centrally managed from the switch. Because Access Ports receive their intelligence from the switch, upgrades are as simple as upgrading the software on the switch.
WLAN switches provide management, additional security, and campus area mobility for the WLAN.
Gateway and VPN Termination Points provide additional security for WLAN MUs to connect to the network. Some WLAN switches have VPN functionality built right in, so two separate boxes are not required.
Other servers can be required for a WLAN implementation. These are often shared with the wired network, and include DHCP servers, DNS Servers, and Remote Authentication Dial-In User Servers (RADIUS).
There are three main configurations for a WLAN: The Basic Service Set (BSS), the Extended Service Set (ESS), and the Independent Basic Service Set (IBSS). The BSS requires one access point for all MUs on the network. An ESS has multiple access points that can be accessed by multiple MUs on the network. The IBSS does not have an access point; instead devices connect directly to each other. This is often referred to as an Ad-Hoc Wireless connection.
Using Radio Frequencies, MUs connect to Access Points (or to each other in an ad-hoc network). Access points send out a beacon at frequent and periodic intervals. Mobile Units will connect to APs by scanning the airwaves to find available APs. Once the MU finds an AP that it wants to connect to it will begin the process of authentication and association.
There are two types of communications that are used by MUs to connect to APs. The first is narrow band communications. Narrow Band Communications use only enough of the RF to send information. It must be a high powered signal to be heard over other signals in the area. The higher power can lead to RF noise. It can also be easily jammed, and is susceptible to interference from other devices. Spread Spectrum is a more widely used technology. It uses a broader frequency range to send information at a lower power density. It is less susceptible to interference and is less likely to be intercepted than narrow band. Spread Spectrum can be further divided into two technologies: Frequency Hopping Spread Spectrum (FHSS) and Direct Sequence Spread Spectrum (DSSS). FHSS uses a pattern of frequency hopping to send data. This pattern is repeated until all frequencies in the band have been used and the hop sequence is complete, at which point the sequence is restarted. There are four components to a FHSS system that allow it to communicate: Channels, Hop Sequence, Dwell Time, and Hop Time. FHSS is not very widely used by devices, and is not commonly used in WLAN deployments. Some technologies, such as Bluetooth, do use FHSS. DSSS is the most common method of deploying a WLAN. It has a lower overall cost, more available hardware, and a better price-to-throughput ratio. DSSS sending stations multiply the information bit with a continuous string of pseudo-noise signals (Chips, discussed previously). The process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code, which determines how much spreading (how much of the frequency range is used) will occur. It also has information that determines the data rate of transmission.
In the United States, the FCC has allocated two frequency ranges for wireless devices. The first is ISM, which operates in the 2.4 GHz – 2.4835 GHz range. The second range is the UNII range, operating from 5 GHz – 6 GHz. In Europe and the rest of the world there are different regulations regarding these frequency ranges, but they are very close. The FCC also regulates how much power output devices can have to 100 mW, but has no further restrictions on FHSS and DSSS Power Density.
Issues facing WLAN technology
It should come as no surprise to anyone that there are several issues faced with a WLAN deployment. These issues can be very complex, so a careful understanding of RF technology is needed to successfully deploy a WLAN. There are several factors that can affect the radio waves being sent out by WLAN devices, causing corruption, loss, gain, and many other issues. I will discuss these issues now.
First I would like to touch upon loss. Loss occurs when there is a decrease in signal strength. Loss can occur both before and after the signal hits the air. It can happen for a variety of reasons, such as resistance in electrical cables and obstacles. Like all electrical signals, RF signals weaken as they get further away from the source. Obstacles, such as brick walls, will decrease the strength as well. As an example, the apartment in which I live is in a brick building. Forty years ago, when the building was converted from a single-family home into a multi-unit dwelling, there was an extension built onto the back of this brick building to provide a kitchen area as well as a fire escape. I have most of my computers in the front half of this building, but we often take my wife’s laptop into the back part of the building, as it is handy to look up recipes and perform other tasks while in the kitchen or dining room. Something I noticed right away was that as soon as I left the room containing our wireless router the signal strength went from five bars down to two bars. By the time I reached the back of the house I was no longer able to access the wireless network, as the signal strength had degraded so much in that short distance. When the signal passed through the brick wall, I experienced obstruction loss. As I moved further away from the access point I experienced path loss.
Gain is another factor affecting RF behaviors. Gain is almost the opposite of loss, but not quite. Gain is an increase in the amplitude of the RF signal. It can be caused by the use of an amplifier or a high antenna. An antenna can not amplify a signal, but it can focus it, thereby increasing the amplitude. The ability of an antenna to focus a signal is called gain. It is possible that a device may be able to receive a signal that has significant gain but it will not be able to establish two-way communication. If you are implementing a situation where gain is required, it is optimal to implement gain on both ends.
Lobe refers to the amount of coverage area of an RF signal sent from an antenna. An antenna with gain can focus the area of coverage and narrow (or focus) the lobe so that it has less coverage vertically, but more coverage horizontally. This will increase the range of the signal while decreasing the amount of up-and-down coverage area. This is ideal for long-range wireless communications from one point to another, as the signal can be focused directly on the receiving antenna.
Refraction occurs when an RF signal passes through an obstacle and bends. Refraction can cause the RF signal to be diverted from its intended destination. This is particularly a problem on long-distance point-to-point links.
Diffraction occurs when an RF signal bends as it passes around an obstacle. Diffraction can result in the distortion of an RF signal.
Scattering occurs when an RF signal bounces off a rough surface, or off of particles in the air. Both situations cause the RF signal to scatter in many directions.
Absorption occurs when an RF signal is absorbed by an object and is not allowed to pass through at all. The problem here should be obvious!
Finally, reflection can occur when an RF signal bounces off a large obstacle, causing degradation of signal strength. The receiving end receives the data through both the direct wave and the reflected wave and attempts to process both signals simultaneously. This can cause a multi-path signal, which can become a serious problem. If the multi-path signal is 180 degrees out of phase with the original signal, the two signals can cancel each other out! Mathematically speaking, the degradation of signal strength occurs at a fourth power of distance, or Strength = -1/d4.
There are also some delay issues that are expected with a WLAN. As mentioned earlier, WLANs use ACK packets to signify that the data has been correctly received. If a packet is not received, an automatic repeat request (ARQ) is used by the WLAN to request the retransmission of the packet. In a VoIP environment delays can be experienced while the data is being retransmitted. Delays can also be experienced because forward and reverse direction MAC flows that the WLAN uses to maintain link reliability and control use bandwidth as well. Since stations are always contending for access to the media we can experience further delays. Typical WLAN delays include:
1. Interframe Space (50 μs)
2. Back off (average of 80 μs)
3. Synchronization Preamble (192 μs)
4. Data (approximately 171 μs)
5. Gap between Data and ACK (10 μs)
6. Next Preamble (192 μs)
7. MAC ACR (11 μs)
As we can see, we can expect an average delay of 706 μs. In addition we can expect to see further delays on our WLAN as we add more MUs to the network, each trying to compete with each other for access to the medium.
First I would like to touch upon loss. Loss occurs when there is a decrease in signal strength. Loss can occur both before and after the signal hits the air. It can happen for a variety of reasons, such as resistance in electrical cables and obstacles. Like all electrical signals, RF signals weaken as they get further away from the source. Obstacles, such as brick walls, will decrease the strength as well. As an example, the apartment in which I live is in a brick building. Forty years ago, when the building was converted from a single-family home into a multi-unit dwelling, there was an extension built onto the back of this brick building to provide a kitchen area as well as a fire escape. I have most of my computers in the front half of this building, but we often take my wife’s laptop into the back part of the building, as it is handy to look up recipes and perform other tasks while in the kitchen or dining room. Something I noticed right away was that as soon as I left the room containing our wireless router the signal strength went from five bars down to two bars. By the time I reached the back of the house I was no longer able to access the wireless network, as the signal strength had degraded so much in that short distance. When the signal passed through the brick wall, I experienced obstruction loss. As I moved further away from the access point I experienced path loss.
Gain is another factor affecting RF behaviors. Gain is almost the opposite of loss, but not quite. Gain is an increase in the amplitude of the RF signal. It can be caused by the use of an amplifier or a high antenna. An antenna can not amplify a signal, but it can focus it, thereby increasing the amplitude. The ability of an antenna to focus a signal is called gain. It is possible that a device may be able to receive a signal that has significant gain but it will not be able to establish two-way communication. If you are implementing a situation where gain is required, it is optimal to implement gain on both ends.
Lobe refers to the amount of coverage area of an RF signal sent from an antenna. An antenna with gain can focus the area of coverage and narrow (or focus) the lobe so that it has less coverage vertically, but more coverage horizontally. This will increase the range of the signal while decreasing the amount of up-and-down coverage area. This is ideal for long-range wireless communications from one point to another, as the signal can be focused directly on the receiving antenna.
Refraction occurs when an RF signal passes through an obstacle and bends. Refraction can cause the RF signal to be diverted from its intended destination. This is particularly a problem on long-distance point-to-point links.
Diffraction occurs when an RF signal bends as it passes around an obstacle. Diffraction can result in the distortion of an RF signal.
Scattering occurs when an RF signal bounces off a rough surface, or off of particles in the air. Both situations cause the RF signal to scatter in many directions.
Absorption occurs when an RF signal is absorbed by an object and is not allowed to pass through at all. The problem here should be obvious!
Finally, reflection can occur when an RF signal bounces off a large obstacle, causing degradation of signal strength. The receiving end receives the data through both the direct wave and the reflected wave and attempts to process both signals simultaneously. This can cause a multi-path signal, which can become a serious problem. If the multi-path signal is 180 degrees out of phase with the original signal, the two signals can cancel each other out! Mathematically speaking, the degradation of signal strength occurs at a fourth power of distance, or Strength = -1/d4.
There are also some delay issues that are expected with a WLAN. As mentioned earlier, WLANs use ACK packets to signify that the data has been correctly received. If a packet is not received, an automatic repeat request (ARQ) is used by the WLAN to request the retransmission of the packet. In a VoIP environment delays can be experienced while the data is being retransmitted. Delays can also be experienced because forward and reverse direction MAC flows that the WLAN uses to maintain link reliability and control use bandwidth as well. Since stations are always contending for access to the media we can experience further delays. Typical WLAN delays include:
1. Interframe Space (50 μs)
2. Back off (average of 80 μs)
3. Synchronization Preamble (192 μs)
4. Data (approximately 171 μs)
5. Gap between Data and ACK (10 μs)
6. Next Preamble (192 μs)
7. MAC ACR (11 μs)
As we can see, we can expect an average delay of 706 μs. In addition we can expect to see further delays on our WLAN as we add more MUs to the network, each trying to compete with each other for access to the medium.
Wireless LAN
The Wireless LAN is a relatively new technology that uses radio frequencies as a medium instead of physical wires. WLANs use the same principles as an Ethernet network, with a couple of minor changes. Ethernet uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD). This is not a possibility, as there is no way to accurately detect a collision on a Radio Frequency. Instead, WLAN technology uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to ensure that packets are not dropped due to a collision. A WLAN device, or Mobile Unit (MU), uses two methods of collision avoidance: Physical Carrier Sense and Virtual Carrier Sense.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Wireless LAN
The Wireless LAN is a relatively new technology that uses radio frequencies as a medium instead of physical wires. WLANs use the same principles as an Ethernet network, with a couple of minor changes. Ethernet uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD). This is not a possibility, as there is no way to accurately detect a collision on a Radio Frequency. Instead, WLAN technology uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to ensure that packets are not dropped due to a collision. A WLAN device, or Mobile Unit (MU), uses two methods of collision avoidance: Physical Carrier Sense and Virtual Carrier Sense.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
Network Policies and Management
A Network Policy is a set of rules governing the network. It can include traffic monitoring and controlling mechanisms. We should implement network policies in order to help implement QoS in a controlled manner. Network policies can also help with security implementations.
A Policy Decision Point (PDP) is the point in the network where decisions about policy are made. This is not to say that the PDP makes the policy – it just enforces them! A PDP can be almost any device in a network, including routers, switches, gateways, and servers. A PDP lets us enable multiple-media applications, WAN efficiency, and alignment of resources to business priorities, just name a few.
Policies are stored in a Policy Repository, which is an LDAP database. These policies are accessed by the PDP (sometimes referred to as a Policy Server). The PDP then distributes the policies to network devices, also referred to as Policy Enforcement Points. Typical policy management functions include:
1. Maximization of current bandwidth usage
2. Mapping network resources for increased performance without bandwidth cost
3. Identifying traffic flows for applications and services
4. Supporting advanced traffic prioritization
5. Administering rules or policies for network behavior
This is not a comprehensive list. There are many more functions of network policies, and I won’t begin to discuss them here. Nearly every corporation with a data or voice network has network policies. Often they are invisible to the end user; sometimes they are put in writing so that users can see them. Network policies are an excellent way to manage network traffic and should almost always be used to ensure Quality of Service.
Network management is also critical to network design. This includes the ability to manage individual devices on the network (with or without being physically present at the device), using fault management techniques, and identifying problems on a proactive basis. Of course, these are not the only things we need to think about when discussing network management, but they are very important. The last one is probably the most important – if we wait for a problem to arise before we fix it, we are asking for trouble. Fixing problems proactively is the key to ensuring network stability.
A Policy Decision Point (PDP) is the point in the network where decisions about policy are made. This is not to say that the PDP makes the policy – it just enforces them! A PDP can be almost any device in a network, including routers, switches, gateways, and servers. A PDP lets us enable multiple-media applications, WAN efficiency, and alignment of resources to business priorities, just name a few.
Policies are stored in a Policy Repository, which is an LDAP database. These policies are accessed by the PDP (sometimes referred to as a Policy Server). The PDP then distributes the policies to network devices, also referred to as Policy Enforcement Points. Typical policy management functions include:
1. Maximization of current bandwidth usage
2. Mapping network resources for increased performance without bandwidth cost
3. Identifying traffic flows for applications and services
4. Supporting advanced traffic prioritization
5. Administering rules or policies for network behavior
This is not a comprehensive list. There are many more functions of network policies, and I won’t begin to discuss them here. Nearly every corporation with a data or voice network has network policies. Often they are invisible to the end user; sometimes they are put in writing so that users can see them. Network policies are an excellent way to manage network traffic and should almost always be used to ensure Quality of Service.
Network management is also critical to network design. This includes the ability to manage individual devices on the network (with or without being physically present at the device), using fault management techniques, and identifying problems on a proactive basis. Of course, these are not the only things we need to think about when discussing network management, but they are very important. The last one is probably the most important – if we wait for a problem to arise before we fix it, we are asking for trouble. Fixing problems proactively is the key to ensuring network stability.
Traffic Flow Design Considerations
Traffic engineering involves the measurement and control of traffic. Main VoIP traffic sources are IP phones and VoIP Trunks. We need to be able to perform traffic engineering on individual nodes and consider the traffic between nodes. Traffic measurement is an analysis of existing traffic flow and the patterns of a network. This will help us to determine how many users and calls a VoIP network can support. Some operational metrics from the system include the number of calls and users, the duration of calls, the number of concurrent calls, call volume profiles, location and call flow, and the number and length of faxes sent and received. In order to assemble this traffic information and make a judgment we need to look at a number of design considerations:
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
Traffic Shaping at Level 4 and Above
Best Effort Networks, operating in layers 2, 3, and 4, are prone to delay and packet loss under congestion. These layers are used for IP traffic.
RTP Prioritization provides a strict priority queuing scheme for voice traffic. It identifies voice traffic by RTP port numbers and classifies traffic by specifying an RTP port range. If traffic matches the specified range, it is classified as voice and is placed in low latency queuing Priority Queue. If traffic does not fall within the specified port range it is classified by service policy of low latency queuing scheme.
TCP/IP Classification prioritizes packets by the packet header. There are four fragmentation methods:
1. Frame Relay Fragmentation is limited to Frame Relay connections. It enables data frames to be fragmented into smaller pieces and interleaved with real-time frames. It also enables real-time voice packets and non-real-time data packets to be carried together on lower speed links without causing excessive delay in real-time links.
2. ATM Fragmentation is limited to ATM Connections. It fragments packets into 53-byte cells for the interleaving of real-time and data packets.
3. PPP Fragmentation is limited to PPP links and splits packets into multiple smaller packets and encapsulates them into PPP frames before queuing them for transmission. Higher priority VoIP packets interrupt and transmit ahead of the larger, lower-priority data packets that were already queued and can interleave packets to minimize delay.
4. Protocol (IP) Fragmentation only transmits the layer 4 and higher protocol information in the first packet in a series of fragments.
Policy Management is another method of Layer 4 QoS. You can implement policy management on network components, such as devices, rules, actions, and policies. Policy management can actually be used on any layer of the OSI Model. Policy management controls traffic flow based on traffic conditions, schedules, and actions.
RTP Prioritization provides a strict priority queuing scheme for voice traffic. It identifies voice traffic by RTP port numbers and classifies traffic by specifying an RTP port range. If traffic matches the specified range, it is classified as voice and is placed in low latency queuing Priority Queue. If traffic does not fall within the specified port range it is classified by service policy of low latency queuing scheme.
TCP/IP Classification prioritizes packets by the packet header. There are four fragmentation methods:
1. Frame Relay Fragmentation is limited to Frame Relay connections. It enables data frames to be fragmented into smaller pieces and interleaved with real-time frames. It also enables real-time voice packets and non-real-time data packets to be carried together on lower speed links without causing excessive delay in real-time links.
2. ATM Fragmentation is limited to ATM Connections. It fragments packets into 53-byte cells for the interleaving of real-time and data packets.
3. PPP Fragmentation is limited to PPP links and splits packets into multiple smaller packets and encapsulates them into PPP frames before queuing them for transmission. Higher priority VoIP packets interrupt and transmit ahead of the larger, lower-priority data packets that were already queued and can interleave packets to minimize delay.
4. Protocol (IP) Fragmentation only transmits the layer 4 and higher protocol information in the first packet in a series of fragments.
Policy Management is another method of Layer 4 QoS. You can implement policy management on network components, such as devices, rules, actions, and policies. Policy management can actually be used on any layer of the OSI Model. Policy management controls traffic flow based on traffic conditions, schedules, and actions.
Implementing QoS At Layer 3
At Layer 3, Differentiated Services (DiffServ) provides a scalable mechanism for prioritizing packets and providing QoS on a VoIP network. There are three main levels identified by DiffServ. The highest priority level is Expedited Forwarding (EF). Expedited Forwarding packets get priority over all other packets. Assured Forwarding (AF) is the mid-level prioritization. Anything that is not EF or AF is classified as Default, and receives the lowest priority. The DiffServ identifier is found within the DiffServ Code Point (DSCP) found in the header of the IP packet.
DiffServ identifies Per-Hop Behaviors (PHB) for each packet that is sent through. A packet classified as EF will receive the highest priority, and is ideal for low-latency applications such as VoIP. An EF package will almost never be discarded from a DiffServ-capable device.
Assured Forwarding packets are subdivided into three behavior groups – Low Drop, Medium Drop, and High Drop. Each of these groups is further divided into four classes, Class 1, Class 2, Class 3, and Class 4. This gives us a total of twelve AF classifications. The drop precedence of these classifications is often defined by the queuing methods of QoS defined in the previous post. The most common methods are Fair Queuing or Weighted Fair Queuing. The level of forwarding assurance is determined by the load of the AF class and the drop precedence of the packet (in the case of congestion within a class).
A Default (DE) packet is sent using a best-effort behavior. If no DiffServ argument is included in a packet it is assumed to be part of the default category.
There are multiple points where a package can be marked for DiffServ. It can be marked using the end point within the device or application from which it originates, it can be marked using intelligent switches where the device is connected to a network based on its TCP/UDP Port, IP Address, or VLAN. The packet can be marked at a core or edge router where the packet encounters links. Traffic entering a network is classified, and possibly conditioned, at the boundaries of the network and is assigned to different behavior aggregates identified by a single DSCP. DiffServ edge router and switch interfaces can be configured to trust or distrust previously marked DSCP or 802.1p tagged packets. If the packet is trusted, the DSCP tag will remain the same. If it is distrusted, the DiffServ router will assign a new DSCP tag.
There are three types of nodes on a DiffServ domain: Edge nodes, Boundary Nodes, and Interior Nodes. The Edge node is the first IP Aware device that applies QoS policies. Edge Nodes and Boundary Nodes are configured to trust or distrust the DSCP identification and forward the packets from one node to another.
DiffServ identifies Per-Hop Behaviors (PHB) for each packet that is sent through. A packet classified as EF will receive the highest priority, and is ideal for low-latency applications such as VoIP. An EF package will almost never be discarded from a DiffServ-capable device.
Assured Forwarding packets are subdivided into three behavior groups – Low Drop, Medium Drop, and High Drop. Each of these groups is further divided into four classes, Class 1, Class 2, Class 3, and Class 4. This gives us a total of twelve AF classifications. The drop precedence of these classifications is often defined by the queuing methods of QoS defined in the previous post. The most common methods are Fair Queuing or Weighted Fair Queuing. The level of forwarding assurance is determined by the load of the AF class and the drop precedence of the packet (in the case of congestion within a class).
A Default (DE) packet is sent using a best-effort behavior. If no DiffServ argument is included in a packet it is assumed to be part of the default category.
There are multiple points where a package can be marked for DiffServ. It can be marked using the end point within the device or application from which it originates, it can be marked using intelligent switches where the device is connected to a network based on its TCP/UDP Port, IP Address, or VLAN. The packet can be marked at a core or edge router where the packet encounters links. Traffic entering a network is classified, and possibly conditioned, at the boundaries of the network and is assigned to different behavior aggregates identified by a single DSCP. DiffServ edge router and switch interfaces can be configured to trust or distrust previously marked DSCP or 802.1p tagged packets. If the packet is trusted, the DSCP tag will remain the same. If it is distrusted, the DiffServ router will assign a new DSCP tag.
There are three types of nodes on a DiffServ domain: Edge nodes, Boundary Nodes, and Interior Nodes. The Edge node is the first IP Aware device that applies QoS policies. Edge Nodes and Boundary Nodes are configured to trust or distrust the DSCP identification and forward the packets from one node to another.
QoS At Layer 2
There are methods of implementing quality of service at different layers. I would like to begin by talking about the methods of implementing QoS at Layer 2.
The Ethernet Standard specifies a frame as having a maximum size of 1,518 bytes. The IEEE defined an additional 4-byte tag for Ethernet Headers, increasing the maximum size to 1,522 bytes. This tag contains two valuable pieces of information that pertain to QoS, the 802.1w VLAN ID Field, and the 802.1p Priority Field.
I will begin by discussing the 802.1p Priority field. Three bits in the IEEE Ethernet Protocol Specification can be used to prioritize packets at the user level. The three bits allow for up to eight levels of prioritization (0-7). Any 802.1p switch is capable of reading this field and can then retransmit the packet across the network with the higher priority. The higher the number in the priority field, the higher priority the switch will give to the packet. The IEEE has made some recommendations for the numbering system to be used here, but it is at the discretion of the network administrator. IEEE recommendations are to use 0 for Best Effort, 1 for Background, 2 as a spare, 3 as Excellent Effort, 4 as Controlled Load, 5 as Video, 6 as Voice, and 7 as Network Control.
The 802.1q specification, also known as VLAN Tagging, refers to the process of identifying which VLAN a packet is coming from. A VLAN, or Virtual LAN, makes a physical switch into smaller logical groupings. For example, a 24-port switch may be divided into three smaller 8-port virtual switches to eliminate leakage of data from one section to the next. This is very useful in a VoIP deployment, as data and voice VLANs can be created to minimize the effect of data transmission on the voice network. VLANs work to reduce the number of collisions and lost packets on a network. There are two types of VLAN – Port-based and policy-based. A Port-based VLAN will assign certain ports on a switch to be members of a VLAN. This is the most common type of VLAN. A policy-based VLAN can be based on a variety of information, such as IP Address, MAC Address, or Protocol (i.e. IP vs. IPX). Most new switches support Port-based VLANs. It is possible to improve QoS by putting IP phones on a separate VLAN from data and other devices, thereby avoiding collisions with these devices.
To ensure QoS we can also select queuing methods for the packets that come into our router. There are six methods of queuing for QoS:
1. First-in First-Out is a straight-forward method of queuing. The first packet received by a switch is the first on sent out by the switch
2. Priority Queuing tells the switch to process high priority traffic first
3. Custom Queuing lets the administrator assign traffic to a certain queue to control how much data is sent each time to a particular queue
4. Fair Queuing uses a round-robin approach – each queue receives the same amount of bandwidth
5. Weighted Round Robin lets the administrator allocate different amounts of bandwidth to different priority queues while ensuring that lower priority queues still receive some bandwidth
6. Weighted Fair Queuing identifies logical conversations (high volume traffic between 2 peers) and makes sure that those conversations do not monopolize the link.
The Resource Reservation Protocol (RSVP) is a method used to reserve resources (or bandwidth) on an RSVP-Compliant router. Resources are allocated on a first-come-first-serve basis. A device requests a certain amount of bandwidth, and the router replies that the bandwidth is now reserved. It will not release the bandwidth until the device is done. This protocol does not carry data; it only acts as a control mechanism for RDP packets. It is not very widely used today.
Traffic Shaping is used to help alleviate network congestion. Network congestion can occur when multiple users contend for access to the same resources. Traffic Shaping lets you determine which packets are dropped due to congestion and which packets receive priority. It can take action based on various characteristics of traffic. It also relies on queuing mechanisms.
IP Address prioritization is as simple as it sounds – packets from certain IP addresses are given priority over packets from other IP addresses. This is ideal for devices with static IP Addresses, such as Call Servers, Signaling Servers, VoIP Gateways, etc. A Network Administrator can configure routers to filter and prioritize all packets originating from these IP Addresses and know they are from VoIP devices.
The Ethernet Standard specifies a frame as having a maximum size of 1,518 bytes. The IEEE defined an additional 4-byte tag for Ethernet Headers, increasing the maximum size to 1,522 bytes. This tag contains two valuable pieces of information that pertain to QoS, the 802.1w VLAN ID Field, and the 802.1p Priority Field.
I will begin by discussing the 802.1p Priority field. Three bits in the IEEE Ethernet Protocol Specification can be used to prioritize packets at the user level. The three bits allow for up to eight levels of prioritization (0-7). Any 802.1p switch is capable of reading this field and can then retransmit the packet across the network with the higher priority. The higher the number in the priority field, the higher priority the switch will give to the packet. The IEEE has made some recommendations for the numbering system to be used here, but it is at the discretion of the network administrator. IEEE recommendations are to use 0 for Best Effort, 1 for Background, 2 as a spare, 3 as Excellent Effort, 4 as Controlled Load, 5 as Video, 6 as Voice, and 7 as Network Control.
The 802.1q specification, also known as VLAN Tagging, refers to the process of identifying which VLAN a packet is coming from. A VLAN, or Virtual LAN, makes a physical switch into smaller logical groupings. For example, a 24-port switch may be divided into three smaller 8-port virtual switches to eliminate leakage of data from one section to the next. This is very useful in a VoIP deployment, as data and voice VLANs can be created to minimize the effect of data transmission on the voice network. VLANs work to reduce the number of collisions and lost packets on a network. There are two types of VLAN – Port-based and policy-based. A Port-based VLAN will assign certain ports on a switch to be members of a VLAN. This is the most common type of VLAN. A policy-based VLAN can be based on a variety of information, such as IP Address, MAC Address, or Protocol (i.e. IP vs. IPX). Most new switches support Port-based VLANs. It is possible to improve QoS by putting IP phones on a separate VLAN from data and other devices, thereby avoiding collisions with these devices.
To ensure QoS we can also select queuing methods for the packets that come into our router. There are six methods of queuing for QoS:
1. First-in First-Out is a straight-forward method of queuing. The first packet received by a switch is the first on sent out by the switch
2. Priority Queuing tells the switch to process high priority traffic first
3. Custom Queuing lets the administrator assign traffic to a certain queue to control how much data is sent each time to a particular queue
4. Fair Queuing uses a round-robin approach – each queue receives the same amount of bandwidth
5. Weighted Round Robin lets the administrator allocate different amounts of bandwidth to different priority queues while ensuring that lower priority queues still receive some bandwidth
6. Weighted Fair Queuing identifies logical conversations (high volume traffic between 2 peers) and makes sure that those conversations do not monopolize the link.
The Resource Reservation Protocol (RSVP) is a method used to reserve resources (or bandwidth) on an RSVP-Compliant router. Resources are allocated on a first-come-first-serve basis. A device requests a certain amount of bandwidth, and the router replies that the bandwidth is now reserved. It will not release the bandwidth until the device is done. This protocol does not carry data; it only acts as a control mechanism for RDP packets. It is not very widely used today.
Traffic Shaping is used to help alleviate network congestion. Network congestion can occur when multiple users contend for access to the same resources. Traffic Shaping lets you determine which packets are dropped due to congestion and which packets receive priority. It can take action based on various characteristics of traffic. It also relies on queuing mechanisms.
IP Address prioritization is as simple as it sounds – packets from certain IP addresses are given priority over packets from other IP addresses. This is ideal for devices with static IP Addresses, such as Call Servers, Signaling Servers, VoIP Gateways, etc. A Network Administrator can configure routers to filter and prioritize all packets originating from these IP Addresses and know they are from VoIP devices.
Port Numbers
Port Numbers are very important in all IP communications. Ports are a numerical value from 0 to 65,535. Since any IP device may have multiple simultaneous communications, or multiple devices behind NAT may be accessing resources simultaneously, port numbers help to determine which application needs to receive which data. Port numbers are divided into three categories: well-known, registered, and Dynamic (or Private) ports. Well-known ports are ports 0-1,023. They are registered with the IANA and are used for specific applications. Ports 1,024-49,151 are registered ports, and are also registered with the IANA. Ports 49,152-65,535 are dynamic ports that can be used for any application. There are two ports identified in a packet, the source port number and the destination port number. Two or more IP-enabled devices can use the same port number, as the IP address for the packet will remain unique. As a combination of the two, we have a unique method of identifying which application should receive data based on the IP address and the port number.
The RTP Header
The Real-Time Transport Protocol header contains a lot of necessary information for a VoIP (or any other real-time) communication. Major components include the RTP Timeclock, the RTP Timestamp, the Synchronization Source, the Contributing Source, the Payload Identification, the Sequence ID, and feedback on jitter.
The RTP Timeclock is an autonomous clock source that determines how many clock ticks have occurred. The RTP timestamp is a counter value that shows when a packet was created, and supports both silence suppression and jitter calculation. The Synchronization source (SSRC) is a unique, randomly-generated identifier that the RTP client uses to identify an RTP session, including which parties are talking and which are silent. The Contributing Source (CSRC) is an identifying list found after the RTP Packet Header, it preserves the identity of the original source. The Payload Identification is a traffic identifier, it identifies the CODEC being used. The Sequence ID is part of the header information, and contains information regarding the order that the packets were sent in. The Feedback on Jitter portion of the RTP header provides potential adjustments that will be required for the possible buffer adjustment.
Since RTP is a connectionless protocol it does not provide feedback to the sending computer. To address this issue the Real Time Control Protocol (RTCP) has been added. RTCP provides end-to-end delivery services for real-time traffic, including monitoring QoS and providing some feedback in QoS reports. It also prvides additional information about the sender, such as the name, telephone number, etc.
The RTP Timeclock is an autonomous clock source that determines how many clock ticks have occurred. The RTP timestamp is a counter value that shows when a packet was created, and supports both silence suppression and jitter calculation. The Synchronization source (SSRC) is a unique, randomly-generated identifier that the RTP client uses to identify an RTP session, including which parties are talking and which are silent. The Contributing Source (CSRC) is an identifying list found after the RTP Packet Header, it preserves the identity of the original source. The Payload Identification is a traffic identifier, it identifies the CODEC being used. The Sequence ID is part of the header information, and contains information regarding the order that the packets were sent in. The Feedback on Jitter portion of the RTP header provides potential adjustments that will be required for the possible buffer adjustment.
Since RTP is a connectionless protocol it does not provide feedback to the sending computer. To address this issue the Real Time Control Protocol (RTCP) has been added. RTCP provides end-to-end delivery services for real-time traffic, including monitoring QoS and providing some feedback in QoS reports. It also prvides additional information about the sender, such as the name, telephone number, etc.
Transport and Session Layer Technologies
Transport and Session are layers 4 and 5 of the OSI model. The Transport Layer (Layer 4) establishes, maintains, and terminates communication between networked machines. The Session Layer (Layer 5) initiates contact between applications and governs the exchange of data between programs. The IP Suite compresses the upper three layers (Application, Presentation, and Session) into one layer called Application. The transport layer remains the same. The Network layer is called the Internet Layer (but performs the same functions), and the bottom two layers, Data Link and Physical, are grouped into one layer called the Network Interface Layer. In the IP suite transport layer there are two methods of delivery: TCP and UDP. TCP stands for Transmission Control Protocol. This is the most common method of delivery in data networks. Each packet sent is acknowledged by the receiving end and missing packets are re-transmitted. UDP, or User Datagram Protocol, is referred to as a connectionless protocol. It does not try to retransmit missing data; instead it assumes that all the data that was sent was received. While this may not sound like the best idea it is an optimal solution for VoIP and other time-sensitive applications, as it does not waste bandwidth with acknowledgements and retransmission of packets. Using this best-effort method, UDP is able to present our VoIP applications with a steady stream of voice packets with minimal delay.
The IP suite is a connectionless Layer 3 protocol with no continuing connection between endpoints. As such, there can be multiple Layer 2 protocols used, including Ethernet, ATM, PPP, Multi-Protocol Label Switching (MPLS), Frame Relay, and Wireless protocols. I would like to take some time now to discuss some of these protocols.
Frame Relay is a cost-effective alternative to a leased line. It can work at speeds from 56kbps to 45Mbps. It provides some QoS capabilities, including prioritization (802.11p) and DiffServ. It exists at Layer 2 so there is less processing to perform at each node. It is considered to be a best-effort protocol, as once a packet enters the network it is not guaranteed any priority over other packets. The delays are higher and more variable than the PSTN. This can lead to an increased chance of serialization delay. Frame relay does offer error correction. When purchasing a Frame Relay connection you purchase a Converted Information Rate (CIR). This is your guaranteed throughput on the relay. If the CIR is too low there is a chance the packets may be dropped, resulting in poor voice quality.
Asynchronous Transfer Mode, or ATM, is available from service providers in four distinct levels of service. The first, Constant Bit Rate (CBR) specifies a fixed bit rate so that data is sent at a constant rate, similar to a leased line. A Variable Bit Rate (VBR) provides a specified throughput capacity, but the data is not sent evenly. VBR is a popular choice for voice and video conferencing data. Unspecified Bit Rate (UBR) does not guarantee throughput rates. It is generally used for applications that can tolerate delays, such as file transfer and other data applications. Available Bit Rate provides a guaranteed minimum capacity and allows for the ability to burst data throughput rates when the network capacity is available. ATM speeds range from 25Mbps to 622Mbps. It has sophisticated QoS services, including DiffServ. Using CBR or VBR you can also receive a guarantee of prioritization. ATM is, unfortunately, not always available and is both difficult to set up and very costly. The equipment required to run ATM is very costly on its own. ATM does have a larger header than many alternatives, and is also subject to serialization delays. ATM will have a lower serialization delay than Frame Relay, however.
Point-to-Point Protocol, or PPP, is used to transmit datagrams between peer routers or other devices over dedicated switched lines. This also the method used to connect dial-up Internet connections. It uses a dedicated link, and therefore can provide the greatest QoS. It is full duplex and can be dedicated or circuit switched.
Wireless LAN is a relatively new technology. WLANs function on radio broadcast frequencies. Devices share the physical layer (the radio band). They must contend for use of the media. There is no collision detection with a WLAN, so collision avoidance methods are used – devices must wait for an inter-frame spacing interval before they transmit, and they must not transmit while other devices are transmitting.
Multi-Protocol Label Switching (MPLS) is a newer transport method. It provides a data transport mechanism for both circuit-based and packet-switched environments, and supports more than one transport method. It can use IP, ATM, SONET, and Ethernet.
Finally, there are common residential connections, namely Cable and DSL. These are best-effort methods, and do not provide and QoS. They are able to provide high-bandwidth Internet access, but minimum transmission speeds are not guaranteed.
The IP suite is a connectionless Layer 3 protocol with no continuing connection between endpoints. As such, there can be multiple Layer 2 protocols used, including Ethernet, ATM, PPP, Multi-Protocol Label Switching (MPLS), Frame Relay, and Wireless protocols. I would like to take some time now to discuss some of these protocols.
Frame Relay is a cost-effective alternative to a leased line. It can work at speeds from 56kbps to 45Mbps. It provides some QoS capabilities, including prioritization (802.11p) and DiffServ. It exists at Layer 2 so there is less processing to perform at each node. It is considered to be a best-effort protocol, as once a packet enters the network it is not guaranteed any priority over other packets. The delays are higher and more variable than the PSTN. This can lead to an increased chance of serialization delay. Frame relay does offer error correction. When purchasing a Frame Relay connection you purchase a Converted Information Rate (CIR). This is your guaranteed throughput on the relay. If the CIR is too low there is a chance the packets may be dropped, resulting in poor voice quality.
Asynchronous Transfer Mode, or ATM, is available from service providers in four distinct levels of service. The first, Constant Bit Rate (CBR) specifies a fixed bit rate so that data is sent at a constant rate, similar to a leased line. A Variable Bit Rate (VBR) provides a specified throughput capacity, but the data is not sent evenly. VBR is a popular choice for voice and video conferencing data. Unspecified Bit Rate (UBR) does not guarantee throughput rates. It is generally used for applications that can tolerate delays, such as file transfer and other data applications. Available Bit Rate provides a guaranteed minimum capacity and allows for the ability to burst data throughput rates when the network capacity is available. ATM speeds range from 25Mbps to 622Mbps. It has sophisticated QoS services, including DiffServ. Using CBR or VBR you can also receive a guarantee of prioritization. ATM is, unfortunately, not always available and is both difficult to set up and very costly. The equipment required to run ATM is very costly on its own. ATM does have a larger header than many alternatives, and is also subject to serialization delays. ATM will have a lower serialization delay than Frame Relay, however.
Point-to-Point Protocol, or PPP, is used to transmit datagrams between peer routers or other devices over dedicated switched lines. This also the method used to connect dial-up Internet connections. It uses a dedicated link, and therefore can provide the greatest QoS. It is full duplex and can be dedicated or circuit switched.
Wireless LAN is a relatively new technology. WLANs function on radio broadcast frequencies. Devices share the physical layer (the radio band). They must contend for use of the media. There is no collision detection with a WLAN, so collision avoidance methods are used – devices must wait for an inter-frame spacing interval before they transmit, and they must not transmit while other devices are transmitting.
Multi-Protocol Label Switching (MPLS) is a newer transport method. It provides a data transport mechanism for both circuit-based and packet-switched environments, and supports more than one transport method. It can use IP, ATM, SONET, and Ethernet.
Finally, there are common residential connections, namely Cable and DSL. These are best-effort methods, and do not provide and QoS. They are able to provide high-bandwidth Internet access, but minimum transmission speeds are not guaranteed.
Bandwidth Requirements
I would like to talk a little bit about the bandwidth requirements for a VoIP network. Bandwidth is a measurement of how much traffic can go through your network.
For lower bandwidth connections (i.e. less than 1Mbps) it is recommended that no more than 50-55% of the total available bandwidth be used for voice traffic. For connections greater than 1 Mbps you can use up to 85% of your available bandwidth for voice traffic. This leaves some headroom on the links to handle bursts of traffic without overloading the link. A bottleneck can occur at any point on the network, including device to switch, switch to switch, switch to gateway, and many more. As such we need to ensure that there is sufficient bandwidth in every pipe on our network to handle the traffic that is being sent.
In addition to the amount of bandwidth required by the data being transmitted, there is additional bandwidth required for every packet sent based on which layer 2 method you are using. For a Frame Relay connection there is a requirement of 6 bytes of overhead. For Point-to-Point Protocol (PPP) there is a requirement for 8 bytes of overhead. Full Duplex Ethernet can be either 38 bytes of 44 bytes – the additional 6 bytes are only used if you have implemented 802.1p, or packet prioritization.
The amount of bandwidth that is required must include the amount of bandwidth required for the CODEC and the amount of bandwidth required for the transport of the packet, including the layer 2 overhead.
Each packet has the following components:
Voice Payload à This is a variable size, and depends on the configuration of your VoIP implementation
RTP Header à 12 bytes, this contains information about the source & destination
UDP Header à 8 bytes, this contains information on the ports used at the source and destination
IPv4 Header à 20 Bytes, included in all IPv4 packets. An IPv6 header is even larger, as the header must include larger addresses and other information
In addition, there are two further components, the Frame Check Sequence of 4 Bytes and the Interframe Gap of 12 Bytes
As we can see, the packet size is 40 bytes plus the size of the payload. As I mentioned earlier, the size of the payload is variable, and depends on the sample length and the CODEC bit rate. The payload size can be calculated using the following formula:
Payload = Bit Rate * Sample Length (s) / 8 bits per byte
This will give us the number of Bytes of payload that needs to be included in the package. We then add to this the amount of overhead from Layer 2 and the amount of IP overhead to give us our total packet size. As an example, let’s take a 20 ms sample size using G.729 (8kbps) over Ethernet using 802.1p:
Payload = 8kbps * 0.02s / 8
Payload = 8000 bps * 0.02s / 8
Payload = 160 bps / 8 = 20 Byte payload size
We then add our overhead to the payload:
Packet size = Payload + Layer 2 overhead + IP Overhead + FCS + IFG
Packet size = 20 Bytes + 44 Bytes + 40 Bytes + 4 Bytes + 12 Bytes
Packet size = 120 Bytes for 20 ms of voice traffic
We can then take this and determine how much bandwidth is required by converting this to bps. We need to determine how many packets per second of voice. As we have seen, 20ms is 0.02 seconds of data, which means that we are using 50 packets per second. So, we multiply our 120 Bytes/packet * 50 packets/second to give us 6000 Bytes per second. We then multiply by 8 to give us bits per second ~ 48000 bps of bandwidth for each direction of a call.
It should also be noted that if we are using the Real-Time Control Protocol we need to add an additional 146 bytes of data to our packet size.
Voice Activity Detection can reduce our bandwidth requirements, as was mentioned before. It enables a data network carrying voice traffic to detect the absence of audio. When audio is absent, it will instead send a signal that indicates that there is no noise, thereby reducing the payload size. A conservative estimate of the bandwidth savings gained using VAD is 30%. VAD is also referred to as Silence Suppression.
EDIT: A Bandwidth calculator is available here.
For lower bandwidth connections (i.e. less than 1Mbps) it is recommended that no more than 50-55% of the total available bandwidth be used for voice traffic. For connections greater than 1 Mbps you can use up to 85% of your available bandwidth for voice traffic. This leaves some headroom on the links to handle bursts of traffic without overloading the link. A bottleneck can occur at any point on the network, including device to switch, switch to switch, switch to gateway, and many more. As such we need to ensure that there is sufficient bandwidth in every pipe on our network to handle the traffic that is being sent.
In addition to the amount of bandwidth required by the data being transmitted, there is additional bandwidth required for every packet sent based on which layer 2 method you are using. For a Frame Relay connection there is a requirement of 6 bytes of overhead. For Point-to-Point Protocol (PPP) there is a requirement for 8 bytes of overhead. Full Duplex Ethernet can be either 38 bytes of 44 bytes – the additional 6 bytes are only used if you have implemented 802.1p, or packet prioritization.
The amount of bandwidth that is required must include the amount of bandwidth required for the CODEC and the amount of bandwidth required for the transport of the packet, including the layer 2 overhead.
Each packet has the following components:
Voice Payload à This is a variable size, and depends on the configuration of your VoIP implementation
RTP Header à 12 bytes, this contains information about the source & destination
UDP Header à 8 bytes, this contains information on the ports used at the source and destination
IPv4 Header à 20 Bytes, included in all IPv4 packets. An IPv6 header is even larger, as the header must include larger addresses and other information
In addition, there are two further components, the Frame Check Sequence of 4 Bytes and the Interframe Gap of 12 Bytes
As we can see, the packet size is 40 bytes plus the size of the payload. As I mentioned earlier, the size of the payload is variable, and depends on the sample length and the CODEC bit rate. The payload size can be calculated using the following formula:
Payload = Bit Rate * Sample Length (s) / 8 bits per byte
This will give us the number of Bytes of payload that needs to be included in the package. We then add to this the amount of overhead from Layer 2 and the amount of IP overhead to give us our total packet size. As an example, let’s take a 20 ms sample size using G.729 (8kbps) over Ethernet using 802.1p:
Payload = 8kbps * 0.02s / 8
Payload = 8000 bps * 0.02s / 8
Payload = 160 bps / 8 = 20 Byte payload size
We then add our overhead to the payload:
Packet size = Payload + Layer 2 overhead + IP Overhead + FCS + IFG
Packet size = 20 Bytes + 44 Bytes + 40 Bytes + 4 Bytes + 12 Bytes
Packet size = 120 Bytes for 20 ms of voice traffic
We can then take this and determine how much bandwidth is required by converting this to bps. We need to determine how many packets per second of voice. As we have seen, 20ms is 0.02 seconds of data, which means that we are using 50 packets per second. So, we multiply our 120 Bytes/packet * 50 packets/second to give us 6000 Bytes per second. We then multiply by 8 to give us bits per second ~ 48000 bps of bandwidth for each direction of a call.
It should also be noted that if we are using the Real-Time Control Protocol we need to add an additional 146 bytes of data to our packet size.
Voice Activity Detection can reduce our bandwidth requirements, as was mentioned before. It enables a data network carrying voice traffic to detect the absence of audio. When audio is absent, it will instead send a signal that indicates that there is no noise, thereby reducing the payload size. A conservative estimate of the bandwidth savings gained using VAD is 30%. VAD is also referred to as Silence Suppression.
EDIT: A Bandwidth calculator is available here.
Quality of Service
As I have mentioned before, packets are transmitted from one end and recompiled at the destination. Not all packets will necessarily take the same path to their destination, which means that they may not all arrive in the same order they were sent in. We can also experience packet loss. In a data network, if a packet is lost or discarded, it is simply re-sent. In a VoIP environment this is not an option. All packets are time-critical and must be received in a timely fashion. We can’t wait for a packet to be re-sent! Quality of Services tries to ensure that time-sensitive packets are given priority over data packets. Other considerations include the amount of packet overhead and the size of the packets. A smaller packet size is more tolerant to packet loss, but every packet has a fixed amount of overhead. For Ethernet, this is 40 bytes. Packet size must be considered when we calculate the bandwidth requirements for our network.
There are several methods that can be used to ensure quality of service in a VoIP network. First I would like to look at Call Admission Control (CAC). CAC can help prevent network congestion by limiting the number of calls that can be active through various nodes in the network. Without CAC, voice quality in the network will decline as the number of calls increases above the recommended utilization. CAC can be defined by a number of rules, including (but not limited to) time of day restrictions, user-level restrictions, VLAN restrictions, IP restrictions, and many more. Policies regarding CAC should be developed at the time of implementation to ensure that problems do not arise down the road. If an organization outgrows it’s CAC policy more bandwidth may be required to grow the voice network.
A firewall may be another factor that affects Quality of Service. Firewalls restrict traffic coming onto and leaving the network based on security rules. An improperly configured firewall may block voice traffic in one direction or another, or both. This can result in one-way speech or no-way speech. It is necessary to open the required ports on the firewall to allow voice traffic to pass through. An even more effective method of managing your firewall would be to have a firewall that specifically recognizes VoIP packets and allows them through.
Network Address Translation (NAT) is another common problem with VoIP implementations. NAT allows multiple devices on a private network to have access to a public network through a single public IP address. VoIP does not work well with NAT, as the originating IP address does not correspond with the external IP address, and the originator is deeply embedded into the packet when it is sent through the NAT server. When the packet is returned to the NAT server, the server is unable to identify where the packet should be sent, resulting in one-way speech. Some new NAT servers are able to understand and process VoIP communications, however.
Packet Delay is also another important consideration with regards to Quality of Service. As delay increases users will start to experience loss, delay, and jitter. With any VoIP implementation there is a fixed delay as the packets cross the network. Fixed delay is also referred to as latency, and is defined as the minimum time it takes from speaking at one end to being heard at the other end. There are many factors that affect packet delay, including the CODEC, network topology, serialization delay, propagation distance, and link delay. As delay increases, the usability of the voice signal decreases. A general rule of thumb with regards to delay is:
Toll Quality < 100 ms < Good Quality < 150 ms < Potentially Useful < 400 ms < Poor Quality
Additionally, Serialization Delay is an issue caused when data is going from a high-speed pipe to a low-speed pipe. The high speed pipe can quickly overwhelm the low speed pipe with information, particularly if QoS policies are not maintained. This can result in jitter and packet loss as the low speed pipe tries to handle all of the data that the high speed pipe is feeding through to it. Serialization delay issues can be solved fairly easily. First you must implement fragmentation. This divides the large frames into smaller frames, which allows for interleaving. Interleaving is the process of allowing smaller frames to be transmitted in between the fragments of the larger frames. If you fragment without interleaving you will actually increase serialization delay, however, as each packet will still have a fixed amount of overhead. Additional overhead will cause more data to be transmitted across the network, resulting in further serialization delay. Nortel recommends only implementing fragmentation on links that require it, primarily links with less than 1Mbps of bandwidth. Fragmentation is set by using the Maximum Transmission Unit (MTU) setting. There are a few formulas for calculating MTU and serialization delay:
Serialization Delay: MTU (B) x 8 / link speed (bps) = Delay (s)
Serialization Delay: MTU (b) / link speed (bps) = Delay (s)
Ideal MTU: link speed (bps) * 0.01s / 8 = Ideal MTU (b)
Packet Loss Concealment is another solution for QoS. Packet Loss Concealment is a method by which the CODEC will guess as to what the missing packet contains. It is not supported by all CODECs, but is an effective way to ignore lost packets without sacrificing much call quality. G.711 does not support PLC, as it transmits PCM data, but G.729 does.
Finally, there is a single solution to a large number of QoS issues: Increase bandwidth. When more bandwidth becomes available, almost all QoS issues disappear.
There are several methods that can be used to ensure quality of service in a VoIP network. First I would like to look at Call Admission Control (CAC). CAC can help prevent network congestion by limiting the number of calls that can be active through various nodes in the network. Without CAC, voice quality in the network will decline as the number of calls increases above the recommended utilization. CAC can be defined by a number of rules, including (but not limited to) time of day restrictions, user-level restrictions, VLAN restrictions, IP restrictions, and many more. Policies regarding CAC should be developed at the time of implementation to ensure that problems do not arise down the road. If an organization outgrows it’s CAC policy more bandwidth may be required to grow the voice network.
A firewall may be another factor that affects Quality of Service. Firewalls restrict traffic coming onto and leaving the network based on security rules. An improperly configured firewall may block voice traffic in one direction or another, or both. This can result in one-way speech or no-way speech. It is necessary to open the required ports on the firewall to allow voice traffic to pass through. An even more effective method of managing your firewall would be to have a firewall that specifically recognizes VoIP packets and allows them through.
Network Address Translation (NAT) is another common problem with VoIP implementations. NAT allows multiple devices on a private network to have access to a public network through a single public IP address. VoIP does not work well with NAT, as the originating IP address does not correspond with the external IP address, and the originator is deeply embedded into the packet when it is sent through the NAT server. When the packet is returned to the NAT server, the server is unable to identify where the packet should be sent, resulting in one-way speech. Some new NAT servers are able to understand and process VoIP communications, however.
Packet Delay is also another important consideration with regards to Quality of Service. As delay increases users will start to experience loss, delay, and jitter. With any VoIP implementation there is a fixed delay as the packets cross the network. Fixed delay is also referred to as latency, and is defined as the minimum time it takes from speaking at one end to being heard at the other end. There are many factors that affect packet delay, including the CODEC, network topology, serialization delay, propagation distance, and link delay. As delay increases, the usability of the voice signal decreases. A general rule of thumb with regards to delay is:
Toll Quality < 100 ms < Good Quality < 150 ms < Potentially Useful < 400 ms < Poor Quality
Additionally, Serialization Delay is an issue caused when data is going from a high-speed pipe to a low-speed pipe. The high speed pipe can quickly overwhelm the low speed pipe with information, particularly if QoS policies are not maintained. This can result in jitter and packet loss as the low speed pipe tries to handle all of the data that the high speed pipe is feeding through to it. Serialization delay issues can be solved fairly easily. First you must implement fragmentation. This divides the large frames into smaller frames, which allows for interleaving. Interleaving is the process of allowing smaller frames to be transmitted in between the fragments of the larger frames. If you fragment without interleaving you will actually increase serialization delay, however, as each packet will still have a fixed amount of overhead. Additional overhead will cause more data to be transmitted across the network, resulting in further serialization delay. Nortel recommends only implementing fragmentation on links that require it, primarily links with less than 1Mbps of bandwidth. Fragmentation is set by using the Maximum Transmission Unit (MTU) setting. There are a few formulas for calculating MTU and serialization delay:
Serialization Delay: MTU (B) x 8 / link speed (bps) = Delay (s)
Serialization Delay: MTU (b) / link speed (bps) = Delay (s)
Ideal MTU: link speed (bps) * 0.01s / 8 = Ideal MTU (b)
Packet Loss Concealment is another solution for QoS. Packet Loss Concealment is a method by which the CODEC will guess as to what the missing packet contains. It is not supported by all CODECs, but is an effective way to ignore lost packets without sacrificing much call quality. G.711 does not support PLC, as it transmits PCM data, but G.729 does.
Finally, there is a single solution to a large number of QoS issues: Increase bandwidth. When more bandwidth becomes available, almost all QoS issues disappear.
CODECs
There are four main CODECs used in VoIP. These are G.711, G.729a/b, G.726, and G.723.1.
G.711 is a 64kbps PCM encoding. It uses the most bandwidth and does not offer any compression. It has the best voice quality, as voice signals are transmitted without any loss due to compression. It is also the most fault-tolerant CODEC. If one packet is lost, it will not represent any noticeable amount of disruption to the conversation, as it does not contain a lot of voice data. G.711 has the least processing delay of any CODEC as it does not have to compress the samples, simply sending them along the network uncompressed. This is only recommended for high-speed (100Mbps) LAN implementations, as it does require a great deal of bandwidth. Attempting to transmit G.711 across low-bandwidth pipes will result in undesired jitter.
G.726 can compress data down to 40, 32, 24, or 16 kbps. It uses ADPCM encoding which works by looking at the difference between the previous sample and the current sample, and only sending the difference. It uses less bandwidth than G.711, but sacrifices voice quality.
G.729a/b is able to compress data down to an 8kbps stream. It uses CS-ACELP encoding which works by matching sound patterns in the voice sample to a codebook. It then sends the code (not the sample) across the network, where the receiving end looks up the code and reproduces the sound based on the code. G.729 has near-toll quality sound, meaning that it is almost as good as using an analog phone. It also uses a technology called silence suppression to further increase bandwidth savings. Silence suppression is quite simple – in any conversation there is usually only one end talking, so half of the bandwidth would be zero noise. To deal with this, G.729 sends a silence signal to the other end, which plays a white noise to indicate that there is no voice coming from the other end. G.729 offers the best balance of quality and bandwidth savings, and is the most commonly implemented CODEC in VoIP.
G.723.1 is a standard that covers two encoding rates. It can operate at 5.38kbps using CS-ACELP encoding, much like G.729. It can also operate at 6.4 kbps using MPMLQ encoding. MPMLQ also uses a codebook to translate voice signals into data, but uses a different compression scheme. G.723.1 has the lowest bandwidth requirements, but at the same time has the lowest voice quality of the different CODECs.
So that is a summary of the different CODECs used for VoIP. G.711 is the CODEC of choice when bandwidth is not an issue, and G.729 is the CODEC of choice when bandwidth is an issue.
It should also be noted that transcoding may occur from one CODEC to another as the voice signal is carried across the network. For example, internal communications on the high-speed LAN may be in G.711, but the signal may need to be transmitted at a higher compression rate using G.729 when it is sent across the WAN. When transcoding occurs, there is additional delay caused while the signal is converted. As such, it is generally a good idea to use one CODEC for the entire network. As such, it is recommended to use the most optimal CODEC for ALL parts of the network, not for each segment.
G.711 is a 64kbps PCM encoding. It uses the most bandwidth and does not offer any compression. It has the best voice quality, as voice signals are transmitted without any loss due to compression. It is also the most fault-tolerant CODEC. If one packet is lost, it will not represent any noticeable amount of disruption to the conversation, as it does not contain a lot of voice data. G.711 has the least processing delay of any CODEC as it does not have to compress the samples, simply sending them along the network uncompressed. This is only recommended for high-speed (100Mbps) LAN implementations, as it does require a great deal of bandwidth. Attempting to transmit G.711 across low-bandwidth pipes will result in undesired jitter.
G.726 can compress data down to 40, 32, 24, or 16 kbps. It uses ADPCM encoding which works by looking at the difference between the previous sample and the current sample, and only sending the difference. It uses less bandwidth than G.711, but sacrifices voice quality.
G.729a/b is able to compress data down to an 8kbps stream. It uses CS-ACELP encoding which works by matching sound patterns in the voice sample to a codebook. It then sends the code (not the sample) across the network, where the receiving end looks up the code and reproduces the sound based on the code. G.729 has near-toll quality sound, meaning that it is almost as good as using an analog phone. It also uses a technology called silence suppression to further increase bandwidth savings. Silence suppression is quite simple – in any conversation there is usually only one end talking, so half of the bandwidth would be zero noise. To deal with this, G.729 sends a silence signal to the other end, which plays a white noise to indicate that there is no voice coming from the other end. G.729 offers the best balance of quality and bandwidth savings, and is the most commonly implemented CODEC in VoIP.
G.723.1 is a standard that covers two encoding rates. It can operate at 5.38kbps using CS-ACELP encoding, much like G.729. It can also operate at 6.4 kbps using MPMLQ encoding. MPMLQ also uses a codebook to translate voice signals into data, but uses a different compression scheme. G.723.1 has the lowest bandwidth requirements, but at the same time has the lowest voice quality of the different CODECs.
So that is a summary of the different CODECs used for VoIP. G.711 is the CODEC of choice when bandwidth is not an issue, and G.729 is the CODEC of choice when bandwidth is an issue.
It should also be noted that transcoding may occur from one CODEC to another as the voice signal is carried across the network. For example, internal communications on the high-speed LAN may be in G.711, but the signal may need to be transmitted at a higher compression rate using G.729 when it is sent across the WAN. When transcoding occurs, there is additional delay caused while the signal is converted. As such, it is generally a good idea to use one CODEC for the entire network. As such, it is recommended to use the most optimal CODEC for ALL parts of the network, not for each segment.
Subscribe to:
Posts (Atom)