In this section we provide the architectural details on how the LAN was organized and discuss how we supported the QoS plan. Our goal was to ensure that as little jitter or loss as possible was introduced into the network and that QoS was provided for all voice calls over as much of the network as was possible. Small amounts of jitter could be compensated for in the receive buffers. Small amounts of loss are handled by the codec, although this loss was very little.

The network was designed using Ethernet switches with dedicated full duplex ports for each endpoint device. The LAN design (Figure 3) consists of the core, distribution, and access switches. All the routing is done in the core; the distribution acts as the aggregation point for all the access switches out in the communication closets, and the access layer is the connection point for all the users. In this particular design, we focused on four communication closets spread out across the campus. All connectivity between switches is Gigabit Ethernet linked by fiber. The access switches all deliver 100 Mb switched to the desktop and phones.

Figure 3: LAN design diagram
click image for larger view
 

A switch located in the data center connects the IP PBX, the Gateway between the IP PBX, and the traditional PBX and the PIMG. All these devices are on the same VLAN, and QoS was enabled for any voice traffic in this segment. This allows for the end-to-end QoS for all the endpoints except for one communications closet.

In the network supporting the pilot user community there is a mixture of PoE and non-PoE access switches in the communication closets. There are four closets: North, South, East, and West, providing access for four different types of use cases identified:

1. Softphones with QoS: All the users in the East communications closet were using softphones on their laptops with headsets. For these users, it was essential to prioritize the voice traffic over their data traffic. This meant enabling QoS on the switches end-to-end from this closet. At the client, we installed the packet scheduler and made sure that the softphone client is marking packets.
2. Hardware IP Phones with PoE: All the users in the West communications closet were using hardware IP phones with PoE. The access switch in the West closet had to be capable of providing the industry-standard 802.3af PoE. The QoS mechanism used in this case was to segment all the hardware IP phones onto a dedicated VLAN using 802.1q and to use priority queuing for voice, to prevent contention with the data traffic.
3. Hardware IP phones without PoE: All the users in the North communications closet were using hardware IP phones but did not have PoE capability. These phones use AC adapters. The QoS mechanism used is the same as that used in the West communications closet including segmented VLANs and priority queuing.
4. Softphones without QoS: The South communications closet did not contain access switches that were capable of prioritizing voice traffic before forwarding it on to the distribution switches. Therefore, we deployed softphones without QoS to any users serviced out of the South closet. This model enabled us to contrast voice quality for users that had some form of QoS mechanism in place end-to-end versus those users that did not have end-to-end QoS.

In addition, we tested Wi-Fi phones in the lab with a dedicated access point so there was no other traffic but voice. The voice quality results were good but we did not perform extensive testing since we had a bigger problem to solve: secure device authentication was not ready in time to deploy users with phones. We decided instead to push Wi-Fi phone deployment to the next phase of the project.

Where the switch was capable of 802.1q and DiffServ, the PCs were also plugged into the switch of the hardware IP phones. This allowed the PC to be set up on a different VLAN than the hardware IP phone. This approach is excellent for a campus with wire runs of one port per cubicle/office or in cases where limiting the number of access switch ports is required to support both voice and data. With this approach the same functionality of using two different network ports is realized at half the real estate.

In summary, the philosophy behind the design was to ensure QoS on a link-by-link basis end-to-end. We enabled DiffServ, which enabled the prioritization of voice traffic over data traffic anywhere that there might have been contention for the network. VLAN separation was also enabled to provide easy differentiation and greater security of the voice network.

The uplinks were all Gigabit and lightly utilized, so we were able to ensure that enough bandwidth for the voice calls was available. Figure 4 shows the portion of the network with DiffServ enabled and how the prioritized packet travels through access, distribution, and the core.

Figure 4: End-to-end packet flow
click image for larger view
 

Figure 5 shows the relationship between the voice quality and various components.

Figure 5: How voice quality maps to components
click image for larger view
 

QoS must be comprehended by all IP telephony end points. All IP endpoints in the pilot were QoS-aware, including all IP phones, softphones, and Wi-Fi IP phones. The following sections describe the QoS considerations we followed for each type of endpoint.

Hardware IP Phones

We used a virtual VLAN segmentation (IEEE 802.1Q) to create a separate broadcast domain. That allowed us to segment voice traffic from network broadcast messages and data traffic. We used a separate VLAN for each supported network access switch. In other words, there was a VLAN for each communications closet.

Softphones

For softphones, we enabled end-to-end QoS in every component in the network. We set up the network and all of its components to distinguish voice and prioritize it above other kinds of traffic. The IEEE standards for QoS are 802.1p and 802.1Q, where a Layer 2 tag is used to specify packet priority. In 802.1p, CoS 5 identifies voice traffic. Using DiffServ, the voice packet is marked with Class EF, which gets priority on a QoS-enabled network. Unlike a hardphone, the softphone resides on a laptop or other computer that is probably running other applications. Like the network, the client environment must recognize and prioritize voice, and the selected softphone must support it.

Non-IP Hardware Phones

Part of the QoS plan included identifying and segmenting the voice traffic on the network from data traffic, and giving voice traffic its own dedicated, logical route. We performed that sort of segmentation only for IP hardphones, not for all voice traffic.