Quality-of-service (QOS) can be defined as a qualitative and quantitative set of measurements used to differentiate between services in a network. These measurements may be parameters, such as response time, latency, bandwidth requirement, jitter, etc. QOS helps in tiering/classifying services, optimizing bandwidth, and in assisting service providers to better control, manage, and generate new revenue based on actual resource usage. Since reliability and service guarantee are central to QOS, its utilization will enable networks to become more robust.
Current cable systems are designed to provide traditional broadcast of analog and digital television services. As such, there exist no service differentiation parameters to distinguish type of services. Recent developments in upgrading cable network architecture to bi-directional communication have paved the way for development of applications to provide customers with varied and high-grade interactivity. Two such applications are DOCSIS and PacketCable. DOCSIS is a platform for providing high-speed data access, such as Internet browsing, file downloads, etc. PacketCable will be implemented to provide packet-based IP voice communications, video conferencing, gaming, and other IP-based services. The PacketCable architecture is a multi-layered structure system overlayed on the DOCSIS platform. The requirements of the above-mentioned applications necessitate maintaining a high degree of service quality, bandwidth availability, and service prioritization on a real-time basis. In order to satisfy these requirements, service providers have to implement complete QOS initiatives.
This article deals with the implementation of QOS in hybrid fiber/coaxial (HFC) cable networks using DOCSIS and PacketCable as specific examples. Whenever DOCSIS is mentioned, this indicates DOCSIS 1.1 specifications; similarly, PacketCable indicates PacketCable 1.0 specifications.
DOCSIS is intended for bi-directional transfer of IP-based content between the cable headend and the subscriber. The main objective of DOCSIS is to provide a transparent high-speed data link to the Internet. The overall architecture is depicted in Figure 1. The major components of a DOCSIS network are the cable modem terminating system (CMTS), which resides at the cable headend or a regional hub, and a cable modem (CM), which is located in the customer premises. The link between the CM and the CMTS is the HFC network, also called the access network.
Figure 1. DOCSIS Overall Architecture
As shown in Figure 1, one end of the CMTS is terminated at the HFC network (i.e., the RF-side interface); the other end may be connected through an IP router to a backbone (i.e., network-side interface). The CM generally is connected to a computer using an Ethernet or universal serial bus (USB) interface. In addition, specifications are being developed for an internal card and for host-based cable modems.
The CMTS is the centerpiece of a DOCSIS network. The major responsibilities of the CMTS are allocating upstream bandwidth based on CM requests and network QOS policies, and forwarding the upstream IP packets to the IP backbone. It also classifies each packet arriving from the network-side interface and assigns a QOS level to it. In addition, it demodulates upstream burst packets, creates MPEG-2 transport stream packets, and modulates downstream packets.
The CM is responsible for transparent delivery of user data from the subscriber premises to the headend using DOCSIS specifications. The CM receives data from higher layer applications, properly formats it, and then sends it to the CMTS. The CM also is responsible for making requests for resource allocation on the upstream direction in order to establish a particular session and a configuration software file download.
DOCSIS employs a layered protocol structure (shown in Figure 2); the two main layers are the physical (PHY) layer and the data-link layer (DLL). These layers are defined to enable the transparent transport of IP packets over the HFC network. The layers above the DLL use well-established protocols, which already exist in data communication and networking environments.
Figure 2. DOCSIS Protocol Stack
The PHY layer can be subdivided into the MPEG-2 transport sub-layer (present in the downstream direction only) and the physical media dependent (PMD) sub-layer. The DOCSIS upstream PMD sub-layer uses the frequency division multiple access (FDMA)/time division multiple access (TDMA) burst-access mechanism. Two modulation formats, QPSK and 16 QAM with five symbol rates, are used. The lowest symbol rate is 160 KSymbols/sec; the highest symbol rate supported is 2.56 MSymbols/sec. The Reed-Solomon forward error correction (FEC) corrects for burst error. The number of Reed-Solomon parity check bytes is 2*T, where T is the maximum number of symbol errors that the FEC can correct. In DOCSIS, T should be no greater than 10. The upstream also implements a 15-bit seed value randomizer to distribute the symbols evenly in the respective constellation space. A variable length preamble is appended to the beginning of each burst after the data has been FEC encoded and randomized. The purpose of a preamble is to aid the burst receiver phased-lock loop (PLL) circuitry to synchronize accurately with the phase of the received data. All of the upstream parameters can be configured by various schemes implemented at the CMTS.
The DOCSIS downstream transmission format is based on the ITU-T J.83 Annex B standard for digital video transmission on cable systems. This standard uses a 6-MHz, 64/256-QAM digital modulation format. The channel coding utilizes a concatenated coding scheme in which the outer coding is a Reed-Solomon FEC code followed by convolutional interleaving, a randomizer, and finally a trellis-coded modulation (TCM) inner code. The TCM is used to improve the threshold signal-to-noise (SNR) ratio by increasing the distance between symbols in the constellation diagram.
As mentioned above, the MPEG-2 transport sublayer, which is present in the downstream flow only, is used to provide a common platform for the transfer of video and data over the HFC network. The MPEG-2 transport stream consists of continuous 188-byte packets. Of the 188 bytes, four bytes are used as the packet header followed by a payload of 184 bytes. The header contains a packet identifier (PID) field, which is 13 bits in length and is used to identify the stream type. A unique PID hex value of 0x1FFE is assigned to the DOCSIS stream.
The second layer used by DOCSIS is the DLL, which consists of three sublayers. These are the logical link control (LLC) sublayer, link layer security sublayer, and the media access control (MAC) sublayer. The MAC sublayer is essential to DOCSIS operation in the access network. In the downstream direction, the CMs listen to all traffic flow from the CMTS to which they are registered, and accept messages targeted to them. Traffic in the upstream direction consists of data transmitted from several CMs intended for the common CMTS. Hence, a multiple access scheme (like TDMA) is used. In order to transmit data in the upstream direction, the CM must first request bandwidth authorization from the CMTS, listen to the downstream bandwidth allocation message (MAP), and then transmit if allowed to do so.
The MAC frame format consists of a MAC header and a variable-length MAC payload. The same MAC frame format is used for upstream and downstream communication, such as upstream channel descriptor (UCD), upstream channel change (UCC) requests, dynamic service addition (DSA), dynamic service change (DSC), and dynamic service deletion (DSD) for QOS, etc.
DOCSIS employs data link encryption between the CM and CMTS, namely baseline privacy interface (BPI), which is a simple data privacy function. DOCSIS also uses the X.509 certificate method to authenticate CMs.
The PacketCable project conducted by CableLabs is aimed at identifying, qualifying, and supporting Internet-based voice and video products over cable systems. These products will represent new classes of services utilizing cable-based packet communication networks. Such services include telephone calls, video conferencing,
etc., and will be delivered using Internet protocol (IP) technology. Essentially, PacketCable is an overlay network that leverages the cable industry’s DOCSIS cable modem infrastructure. PacketCable architecture consists of multimedia clients, signaling and media gateways for multiple external networks, and multi-purpose servers for various features and interfaces to back-office systems.The PacketCable reference architecture model is shown in Figure 3. The architecture can be divided into three sections: the originating client-side access, the managed IP network, with an interface to the public switched telephone network (PSTN), and the terminating client-side access network.
Figure 3. PacketCable™ Reference Architecture
The HFC network provides access to the IP-managed network with DOCSIS-enabled QOS. The access network is defined to include the CM, multi-media terminal adapter (MTA), and the CMTS. In PacketCable 1.0, the subscriber equipment consists of an embedded MTA with a DOCSIS CM, MAC, and PHY.
The PacketCable-managed IP network provides interconnection between PacketCable network elements involved in call signaling, provisioning, and QOS establishment. The managed-IP network is defined to include the call management server (CMS), which contains a call agent (CA) to provide the telephony signaling services, and a gate controller (GC), which is responsible for the admission policy decision. The announcement server (ANS) is used to manage and to provide all announcements in the network.
The PSTN interface is a vital part of the PacketCable reference architecture. It consists of three main elements: the signaling gateway (SG), the media gateway (MG), and the media gateway controller (MGC). The functional components present in a PacketCable network are shown in Figure 4.
Figure 4. PacketCable Network Component Reference Model
An MTA is a PacketCable client device that contains a subscriber-side interface to the physical telephony equipment (e.g., telephone), and a network-side signaling interface to call control elements in the network. An MTA provides the codecs and all signaling and encapsulation functions required for media transport and call signaling. MTAs reside at the customer site and are connected to other PacketCable network elements via the DOCSIS network. PacketCable MTAs are required to support the network call signaling (NCS) protocol; PacketCable defines two types of MTAs: standalone (S-MTA) and embedded (E-MTA). PacketCable 1.0 specifications only require support for embedded MTAs.
The CMS provides call control and signaling-related services for the MTA, CMTS, and PSTN gateways in the PacketCable network. A PacketCable CMS may consist of one or more of the following logical PacketCable components: call agent (CMS/CA), gate controller (CMS/GC), and announcement controller (CMS/ANC). CMS/CA refers to the control component of the CMS responsible for providing signaling services using the NCS protocol to the MTA. The CMS/GC is a logical QOS management component within the CMS that coordinates all QOS authorization and control. The CMS/ANC is a logical component for controlling network announcement services. The ANC requests the announcement player (ANP) to play announcements based on call state as determined by the CMS.
PacketCable allows MTAs to interoperate with the current PSTN through use of PSTN gateways. The PSTN gateway is composed of three functional components: the media gateway controller (MGC), the media gateway (MG), and the signaling gateway (SG). The MGC is the PSTN gateway’s overall controller. It receives and mediates call-signaling information between the PacketCable
network and the PSTN. It maintains and controls the overall call state for calls requiring PSTN interconnection. The media gateway provides bearer connectivity between the PSTN and the PacketCable IP network. The MGC also instructs the MG to detect and to generate events and signals relevant to the call state known to the MGC. The SG function sends and receives circuit-switched network signaling at the edge of the PacketCable network. For PacketCable, the signaling gateway function only supports non-facility associated signaling in the form of signaling system #7 (SS7).The operation support system (OSS) back office contains service and network management components supporting the core business processes. The OSS’s main functional areas are: fault management, performance management, security management, accounting management, and configuration management. PacketCable defines a limited set of OSS functional components and interfaces to support MTA device provisioning and event messaging to carry billing information. For PacketCable, the term ticket granting server (TGS) is utilized for a Kerberos server. The dynamic host configuration protocol server (DHCP) is used during the MTA device provisioning process to dynamically allocate IP addresses and other client configuration information. The domain name system server (DNS) is used to map between IP addresses and ASCII domain names. The trivial file transfer protocol server (TFTP) or the hypertext transfer protocol server (HTTP) is used during the MTA device provisioning process to download configuration files to the MTA. An HTTP server may be used instead of a TFTP server to download configuration files to the MTA. The SYSLOG server (SYSLOG) is used to collect events, such as traps and errors, from an MTA. The record keeping server (RKS) receives PacketCable event messages from other PacketCable network elements such as the CMS, CMTS, and MGC. It assembles the event messages into coherent sets, or call detail records (CDRs), which are then made available to other back office systems, such as billing, fraud detection, and other systems.
The media server is a logical entity that holds media content for a specific multimedia service. In PacketCable, the media server consist of only an ANP, which is responsible for receiving and interpreting commands from the ANC and for delivering the appropriate announcement(s) to the MTA. The ANP also is responsible for accepting and reporting user inputs like dual-tone multi-frequency (DTMF) tones.