Here at Alianza, we have been working with Cable MSOs looking to have their VoIP services managed in the cloud. Throughout our company’s history, we have worked with numerous service providers that use different broadband access networks (DSL, WiMAX, LTE, etc.) and they invariably ask: “How can we assure quality of service with voice hosted outside our network?”
The interesting thing is that QoS issues generally occur at a bottleneck point or “choke point.” This slower part of the network requires QoS mitigation measures. For most practical purposes, the choke point exists between the end user’s network and the service provider core (i.e., the last mile).
In order to mitigate the problem and provide a quality service to the end-user, Alianza works with our service provider customers to ensure that QoS mechanisms are put in place over the last mile. For different types of service providers, this means different things. For older wireless networks, it may be a simple network range that is given higher priority. For WiMAX, service flows are the name of the game. In the cable space, it depends on the version of the PacketCable spec we are talking about. In this blog post, I’ll discuss what QoS measures are available for cable operators and some of the benefits and drawbacks of each.
The options for QoS are legion. I could spend a number of blog posts talking about them. However, after Alianza dug into the cable QoS options, we narrowed down the list to five possible solutions in two categories (and a few variants per category). All of these approaches are standard-based and we can work with any of these environments. The two categories are:
- Dynamically Defined – this type is dynamically defined and allocated based on voice calls and involves signaling requests between Alianza Cloud Voice Platform and the MSO network; there are 3 variants based on PacketCable spec and the equipment in the network:
- IMS with P-CSCF
- Non-IMS with SBC and Policy Server
- No Policy Server
- Statically Defined – this type is defined based on IP address and ports and then dynamically allocated based on voice calls; the requests reside solely within the MSO network between the CMTS and eMTA.
- Device-Based
- CMTS-Based
Let’s go over each one in detail…
Dynamically Defined: IMS with P-CSCF
The Proxy-Call Session Control Function (P-CSCF) is an element in an IMS network and is utilized in the PacketCable 2.0 architecture. The P-CSCF function is the first point of contact from the perspective of the SIP endpoint. In the Alianza Cloud Voice Platform, our SBC performs this function. In order to set up priority flows, the SBC sends Diameter messages to the Policy and Charging Rules Function (PCRF) using the Rx interface. In PacketCable 2.0 the PCRF function is often shared between the PacketCable Application Manager and the Policy Server. The Policy Server is then responsible for using the session information to discover the serving CMTS and enforcing the QoS through the use of PacketCable Multimedia (PCMM) Gates. This works well, but few Cable operators are PacketCable 2.0 compliant today. There is some additional burden to manage a signaling flow between the two networks. I am interested to see how the specification progresses given the lackluster adoption of IMS to date.
Dynamically Defined: Non-IMS with SBC and Policy Server
The functionally is nearly the same as the P-CSCF option. Under the PacketCable Multimedia Architecture, the Policy Server is responsible for setting up priority flows on behalf of the Application Manager. In this scenario, Alianza’s SBC acts as the Application Manager. Instead of Diameter, Alianza sends COPS messages to the policy server for QoS provisioning. The Policy Server is then responsible for using the session information to discover the serving CMTS and enforcing the QoS through the use of PacketCable Multimedia Gates. This is another standards-based approach and works fine, but has that same additional set of operational requirements.
Dynamically Defined: No Policy Server
Most cable networks are heterogeneous. In other words, various elements support different levels of PacketCable compliance. In addition, some elements of the PacketCable architecture may be missing in a particular cable provider’s environment because they are not needed. The policy server is one such element. The service provider may not have a policy server if its functionality is not required in their service offerings. If the CMTS of the cable operator is PCMM compliant, then it is possible to provision Gates through the COPS interface. However, because there is no policy server to determine the serving CMTS, the Alianza Cloud Voice Platform must have 1) a connection to each CMTS for COPS provisioning and 2) knowledge of which SIP endpoints are being served by each CMTS. We lean away from this configuration due to severe operational complexity but recognize that it is a viable option and we can support it.
Statically Defined: Device-Based
Some PacketCable specifications allow for the eMTA to configure various flows between that device at the customer premises and the CMTS. Under most circumstances, it makes sense to configure the device with a Dynamic UGS or UGS-AD flow specific to the Alianza solution. The Unsolicited Grant Service (UGS) provides dedicated bandwidth for voice traffic. The “AD” in UGS-AD stands for Activity Detection and saves bandwidth when voice traffic is not flowing. The UGS-AD flow is preferred for bandwidth reasons. The advantages of this approach are that the configuration is fairly straightforward and scalable and doesn’t require any new equipment. Drawbacks include any changes that need to be made in the device provisioning infrastructure to support the appropriate configuration.
Statically Defined: CMTS-Based
Similar to the device-based approach, the CMTS is capable of setting up flows based on device profiles. These device profiles are configured on the CMTS and devices of a particular configuration will be set up with this profile. In other words, devices could be automatically configured with a normal best-effort flow as well as a UGS/UGS-AD flow for voice traffic when the device boots. Of course, a UGS-AD flow would be preferred in this situation as well.
When choosing the QoS option that is most appropriate, one of the major factors comes back to what architecture or PacketCable spec a cable network is based on and where that MSO wants to take it. The flexibility of our platform allows us to work in any of these environments and evolve with our cable customers. QoS for cable VoIP works with a cloud solution as the key control mechanisms still reside in the cable network.
Contact us if you’re interested in more about cable VoIP 2.0 in the cloud.