Cisco Broadband Local Integrated Services Solutions (BLISS) is a service provider solution that delivers voice, video, and data services over a converged broadband access network. The bundled services can be delivered over the last mile through a variety of access mechanisms including T1/E1, cable, and Metro Ethernet. Cisco BLISS for Cable has been adapted specifically to the needs of the cable industry. Cisco has aggressively pursued component qualification against PacketCable™ specifications, the requirements for the cable industry. Cisco BLISS for Cable focuses on the North American Cable Operators/Multiple Systems Operators (MSOs) market and delivers the following incremental benefits to MSOs:
•
Leverages investments made in upgrading the cable access plant
•Expands the set of services deliverable to end customer to include local voice services
•Delivers an integrated, tested solution to cable operators, which decreases risk and expedites time-to-market
•Enables operators to bundle services that increase revenue
•Adheres to cable industry standards to ensure interoperability and deliver important services
Cisco BLISS for Cable architecture builds upon the PacketCable™ standards and uses a Media Gateway Control Protocol (MGCP)-based centralized call control architecture.
Cisco BLISS for Cable Release 2.2 builds upon Cisco BLISS for Cable Releases 1.0, 1.5, and 2.0 and expands the framework to include new elements, features and cable access technology using packetized data transmission over the cable television hybrid fiber coaxial (HFC) network.
Cisco BLISS for Cable Release 2.2 features include
•New Solution Components and Protocols:
–Cisco IP transfer point (ITP) signaling gateway (SG): A-links
–Cisco MGX 8880 with VxSM
–High availability cable modem termination system (CMTS)
–Call admission control (CAC) for CMTS
–Enhanced network management system (NMS) tools (JacobsRimell and Auspice)
–External log server
–T.38 fax relay call agent-controlled mode across SIP trunk interface
•Telephony Features:
–Block toll free calls per subscriber
–Star code to access voice mail
–Single vertical service code (VSC) to activate or deactivate both call forwarding on no answer (CFNA) and call forwarding on busy (CFB)
–Stand-alone call redirection to voice-mail
–No solicitation announcement
–Incoming privacy indicator flag on call detail record (CDR)
•Operations, Architecture, and Security Features:
–Call data block (CDB) filename based on PC filenaming conventions
–.DONE indicator after successful transmission of call DB records to billing mediation server
–Trace active call per directory number and trunk identification
–Network continuity test and TDM test enhancements
–Support for Communications Assistance for Law Enforcement Act (CALEA)
–30 originating point codes
•Scalability Features:
–Subscriber database (DB) expansion to 125k subscriber lines
–Large-hardware support: Sun 1280 (eight processors)
Architectural Overview
Cisco BLISS for Cable architecture is based on the CableLabs® PacketCable™ 1.5 architecture and utilizes the CableLabs® DOCSIS™ 1.1 HFC access network architecture, along with MSOC backbone architecture. Within Cisco BLISS for Cable, the Cisco BTS 10200 performs the functions of the call management server (CMS) and the media gateway controller (MGC) as defined in the PacketCable™ 1.5 specifications.
Cisco BLISS for Cable architecture consists of multiple functional planes:
•Customer premise equipment (CPE) layer and access gateways provide uplink technology.
•Aggregation layer provides aggregation of traffic from all of the CPE uplinks.
•Core switching layer provides the packet backbone.
•Trunking layer provides the interface between the public-switched telephone network (PSTN) and the Internet service provider (ISP).
•Call control and management provides the call control/signaling support, feature server interfaces, and support for network resource interfaces such as announcement servers and CALEA servers.
•Network management layer provides the EMS and network management components.
Solution Interoperability
Cisco BLISS for Cable relies on interoperability with various partner systems to provide particular functions. The partner systems may include multimedia terminal adapters (MTAs), announcement systems, interactive voice response (IVR) systems, voice-mail systems, billing mediation systems, and electronic surveillance systems.
QoS
Voice quality is primarily affected by three factors: delay, jitter, and loss. Cisco is a clear market leader with a superior quality of service (QoS) mechanism implemented in Cisco BLISS for Cable, which satisfies the ITU-T standard G.114 recommendations for delay.
IP Network QoS Design
With Cisco BLISS for Cable, the voice and data traffic generated from the cable modem is assigned the following IP precedence values:
•Bearer real-time traffic: IP precedence 5
•Voice signaling traffic: IP precedence 3
•Data traffic coming from the cable modem: IP precedence 0
To provide appropriate latency and jitter characteristics throughout the Cisco BLISS for Cable architecture, low-latency queuing (LLQ) is the primary queuing technique for all output service policies (queue structures for system backhaul links) on all platforms except the Cisco GSR 12000 Series routers, where the modified deficit round robin (MDRR) 
queuing strategy is used to provide a strict queue.
LLQ provides a combination of a priority queue (one that is completely serviced first, without deference to any other queues) for real-time traffic (namely RTP) and class-based weighted fair queuing (CBWFQ) for all other traffic types.
Weighted random early detection (WRED) is employed as the primary congestion avoidance technique. This QoS mechanism provides the ability to drop lower-priority traffic classes more aggressively than higher-priority traffic classes by looking at the average queue size.
Queue depth is analyzed against a minimum and maximum threshold. For an average queue depth below the minimum threshold, packets are queued. For an average queue depth above the maximum threshold, packets are dropped. When the average queue depth is between the minimum and maximum, a drop probability is used to determine the linear rate of drop. DiffServ-compliant WRED uses differentiated services code point (DSCP) to determine the drop probability.
Dynamic Quality of Service
DQoS Concept
A key feature of a PacketCable™ network is a dynamic quality of service (DQoS) capability that is similar to the dynamic services provided by DOCSIS 1.1. However, DOCSIS 1.1 DQoS authorizes and provisions services only in the cable network and does not reserve the resources needed to propagate a call from one endpoint to another across the network.
PacketCable™ DQoS extends the DOCSIS 1.1 services across the entire network so that resources can be dynamically authorized and provisioned from one endpoint to another. This prevents possible theft-of-service attacks and guarantees customers the services that they are authorized to use.
The PacketCable™ DQoS model uses a two-stage resource reservation process, in which resources are first reserved and then committed. This allows a bidirectional reservation process that ensures that resources are available at both endpoints of the connection before the call is actually placed.
When an MTA makes a call request, the local CMTS communicates with the gate controller to authorize the call's resources. After the resources are authorized, the CMTS reserves the local resources while it negotiates with the remote end for the resources required at that end.
The CMTS uses DOCSIS 1.1 dynamic service addition (DSA) messages to reserve the resources and then uses dynamic service change (DSC) messages to commit the resources.
When all required resources are available, the local CMTS and remote CMTS both commit the resources, allowing traffic to flow. Usage accounting and billing do not begin until the remote MTA picks up and the call is actually in progress.
The DQoS model ensures that both endpoints of a call, as well as the backbone network, have reserved the same bandwidth and that the bandwidth is reserved only while the call is in progress. When a call terminates, all portions of the network can release the call's resources and make them available for other users.
Making a Call Using DQoS
DOCSIS 1.1 networks use service flows to implement different QoS policies, but service flows exist only within the cable network. To control the service flows and to extend them across the entire network, a PacketCable™ network creates and maintains "gates."
A gate is a logical entity created on the CMTS at each side of a connection that authorizes and establishes a particular DQoS traffic flow. The CMTS communicates with the gate controller to coordinate the creation of matching gates at each end of the connection.
Gates are unidirectional, so separate gates are required for the downstream and upstream traffic flows. The same gate ID, however, is usually used for both the downstream and upstream gates for a call. Each CMTS maintains its own set of gates, so a bidirectional traffic flow requires four gates to be created: two gates on the local CMTS and two gates on the remote CMTS.
For a typical call, gates progress through the following stages to create a DQoS traffic flow:
1. The local MTA makes a call request.
2. The gate controller sends a Gate-Allocation command to the CMTS, which creates a gate in response and sets its state to Allocated.
3. The call management server, which might be the same server as the gate controller, parses the call request to translate the destination phone number into the appropriate destination gateway.
4. The gate controller verifies that the MTA that is making the call request is authorized for the required resources.
5. The gate controller sends a Gate-Set command to the CMTS, which sets the gate state to Authorized.
6. The CMTS on each side of the connection reserves the local resources needed for the call, setting the gate state to Reserved.
7. As the remote CMTS and local CMTS perform gate coordination, their respective gates are set to the Local_Committed and Remote_Committed states.
8. When both sides have reserved all required resources, each CMTS sets its gate state to Committed, allowing traffic to flow.
Security
Within Cisco BLISS for Cable, the following PacketCable™ security measures are implemented:
•Signaling Security is based on IPsec encapsulating security payload (ESP) (3DES, HMAC-MD5) transport mode. Security association (SA) is unidirectional.
•IPsec Key management is either Kerberos (KDC) or IKE (pre-shared key):
–NCS Signaling Security uses Kerberized IPSec
–IPsec/IKE is used over the COPS and RADIUS interfaces
•Media Security uses AES (encrypted RTP and RTCP). This affects DQoS bandwidth/flows-spec calculation.
•Media Security Ciphersuite negotiation is in NCS Signaling (LCO and SDP). Null Ciphersuites are supported but still signaling in SDP.
•All PacketCable™ 1.0 Security requirements for CMS are implemented.
Information about Security Interface Features on the Cisco BTS 10200 Softswitch is available here .