Downloads |
Table Of Contents
Cisco BTS 10200 Softswitch PacketCable Guide, Release 6.0.x
Cisco BTS 10200 Softswitch in the PacketCable Network
Description of the Event Message Feature
Event Message Generation Details and Content
Timestamp Support for Event Messages
Event Message Storage on the CA
PCMM-Based QoS for Type 1 Clients
SOAP/XML Interface for CMS Subscriber Provisioning
Prerequisites for CMS Subscriber Provisioning
Limitations on CMS Subscriber Provisioning
Provisioning Basic PacketCable and DQoS Features
Provisioning the CMS Interfaces to the CMTS and eMTA
Provisioning DQoS Parameters for Codec Negotiation Service
Provisioning TGCP Interfaces to TGWs
Provisioning the Keepalive AUEP Ping Option
Provisioning MGCP Command Timeout and QoS Parameters
Provisioning the Aggregation ID Subnet
Provisioning CMTS Discovery Using the Static Subnet Table
Provisioning Subscriber ID Parameters and DQoS Measurement Counter
Provisioning Security Interfaces
Provisioning Parameters for Secured Media
Provisioning Security Interfaces to the MTA
Provisioning Security Interfaces to the CMTS
Provisioning Security Interfaces to the TGW
Provisioning Security Interfaces to the RKS
Provisioning IPsec Security Associations and Ciphersuite Algorithms
Provisioning Support for EM Transmission and Storage
Provisioning the System to Generate EMs for Billing
Provisioning Media_Alive Verification for EMs
Provisioning PCMM-Based QoS for Type 1 Clients
Provisioning AuditConnection Parameters
Operations, Billing, and EM Transfer Procedures
PacketCable Billing Data and Formats in Deployments Using CDBs
Reset, Control, and Status Commands
Manual Recovery and Transfer of Stored EMs
Sending Billing Files to the RKS via FTP
Content of EMs Sent to the RKS
Viewing Media_Alive Verification for EMs
Creating Reports and Displays of Measurements
Measurements for the DQoS Feature on COPS Interface
Measurements for the EM Feature
Events and Alarms Specific to PacketCable-Based Network Elements and PCMM Features
Events and Alarms for the EM Feature
Events and Alarms for the Security Interface Feature
EM Generation Details and Content
References to Industry Standards
Cisco BTS 10200 Softswitch PacketCable Guide, Release 6.0.x
Revised: March 31, 2008, OL-15919-01This document describes how the Cisco BTS 10200 Softswitch implements PacketCable-based interfaces and functions. It also provides provisioning and operating information for PacketCable features and event messages (EMs). It is intended for use by service provider management, system administration, and engineering personnel who are responsible for designing, installing, provisioning, and maintaining networks that use the Cisco BTS 10200 Softswitch system in a PacketCable-based network.
Document Change History
The following table lists the revision history for the Cisco BTS 10200 Softswitch PacketCable Guide, Release 6.0.x.
OL-15919-01
31 Mar 2008
Initial
•
Initial document for Release 6.0.x
•
Contents
Operations, Billing, and EM Transfer Procedures
EM Generation Details and Content
References to Industry Standards
Technical Overview
This section provides technical information about the implementation of PacketCable features. It covers the following topics.
•
•
•
Note
Cisco BTS 10200 Softswitch in the PacketCable Network
The Cisco BTS 10200 Softswitch is a class-independent network-switching element. In a PacketCable-based network, it functions as both a call management server (CMS) and a media gateway controller (MGC). It provides call control, call routing, and signaling for several types of multimedia terminal adapters (MTAs) and embedded MTAs (eMTAs), cable modem termination systems (CMTSs), and trunking gateways (TGWs) in PacketCable-based networks. It provides interfaces to record keeping servers (RKSs) and key distribution centers (KDCs). The Cisco BTS 10200 Softswitch also communicates with announcement servers, Signaling System 7 (SS7)-based signaling gateways, Media Gateway Control Protocol (MGCP)-based media gateways, and Session Initiation Protocol (SIP) networks.
Figure 1 shows a typical network with PacketCable-based network elements and the applicable external interfaces of the Cisco BTS 10200 Softswitch. In the PacketCable-based network, the Cisco BTS 10200 Softswitch performs the functions of both the CMS and MGC. The Cisco BTS 10200 Softswitch also provides provisionable options for customizing the external interfaces.
Figure 1 Example of PacketCable-Based Network Architecture
PacketCable-Based Interfaces
The Cisco BTS 10200 Softswitch supports signaling on specific PacketCable-based interfaces shown in Figure 1. The following list summarizes the supported protocols for each of the links:
•
•
•
•
•
•
Additional interfaces are defined for the PacketCable Multimedia (PCMM) quality of service (QoS) features in the "PCMM-Based QoS for Type 1 Clients" section.
The Simple Object Access Protocol/Extensible Markup Language (SOAP/XML) interface for CMS subscriber provisioning is defined in the "SOAP/XML Interface for CMS Subscriber Provisioning" section.
For a description of Cisco BTS 10200 Softswitch support for CALEA, see the Cisco BTS 10200 Softswitch System Description. For provisioning procedures related to CALEA support, see the Cisco BTS 10200 Softswitch Provisioning Guide.
Note
Additional Network Interfaces
The following additional interfaces are not part of the PacketCable feature set, but they provide other important functions useful in the service provider network:
•
•
•
–
–
•
This interface provides communication with Operations Support System (OSS) and office applications servers.Gate Coordination Functions
In the PacketCable environment, the Cisco BTS 10200 Softswitch performs the gate coordination functions of a CMS, including the gate controller (GC). GC signaling is based on the COPS stack. Each CMTS informs the CMS when a gate is successfully opened or closed. Two gate coordination messages are used, Gate-Open and Gate-Close. Gate coordination is required to avoid several theft-of-service scenarios, as described in Appendix K of the PacketCable Dynamic Quality-of-Service Specification, PKT-SP-DQOS-I07-030815, August 15, 2003.
Note
Gate-Open Process
The normal coordination process for Gate-Open signaling, illustrated in Figure 2, has four main steps:
1.
2.
3.
4.
Figure 2 Gate Coordination Signaling Example (Gate-Open)
If the Gate-Open message arrives at the Cisco BTS 10200 Softswitch before it has sent a resource-commit request to the MTA, the Cisco BTS 10200 Softswitch sends a GATE-DELETE message to the CMTS with Unexpected Gate-Open included in the reason code.
Gate-Close Process
During a call, if the Cisco BTS 10200 Softswitch receives a Gate-Close message from the CMTS, it allows the call to proceed on a best-effort basis, without a guaranteed level of service. (It tears down the call only when one of the parties in the call goes on-hook.)
Security Interface Features
Note
The implementation of PKT-SP-SEC-I09-030728, PacketCable Security Specification, July 28, 2003, provides a security scheme for the voice-over-cable network built on a set of security protocols. These protocols, based on the following documents, provide authentication (to help prevent theft of bandwidth, denial-of-service attack, replay, and so forth) and enable message integrity, privacy, and confidentiality.
•
–
–
•
–
–
The Cisco BTS 10200 Softswitch performs the security functions of a CMS and a MGC in the PacketCable environment. It supports security in accordance with PKT-SP-SEC-I09-030728 for both signaling and media:
•
•
The system supports IPsec features for encryption and authentication on specific PacketCable-based interfaces (see Figure 1). There are two aspects to the security features; the security protocol itself (IPsec), and the key management (Kerberos or IKE). The following list summarizes the supported security type for each of the links:
•
•
•
•
•
•
As shown in Figure 1, there is no interface between the KDC and the Cisco BTS 10200 Softswitch. To ensure secure NCS signaling, a dynamic key exchange is performed. This exchange provides for IPsec security operations between the MTA and the Cisco BTS 10200 Softswitch. (These procedures are described in the CableLabs document PacketCable Security Specification, PKT-SP-SEC-I09-030728, under "Kerberized IPsec" and other sections.)
•
•
Note
Note
Event Message Feature
This section describes Cisco BTS 10200 Softswitch support for the EM feature.
Billing Data Options
The Cisco BTS 10200 Softswitch can provision billing support using either of the following billing data generation methods:
•
•
The Cisco BTS 10200 Softswitch should be provisioned to generate either EMs or CDBs, but not both.
Caution
The content of the CDBs is outside the scope of this document. See the Cisco BTS 10200 Softswitch Billing Interface Guide for information about CDBs.
Description of the Event Message Feature
EMs are real-time data records containing information about network usage and activities. (They must not be confused with system event messages that report events and sometimes trigger alarms.) EMs are used in PacketCable networks to collect resource usage data for billing purposes. In the PacketCable architecture, EM generation is based on the half-call model. A single EM can contain complete usage data or it might contain only part of the usage information.
The RKS is a PacketCable network element that receives EMs from network elements, such as the CMS, the MGC, and the CMTS. The physical Cisco BTS 10200 Softswitch contains both CMS and MGC logical network elements. The EMs generated by both the CMS and MGC are sent to the RKS. The RKS correlates the information in multiple EMs and provides the complete record of service for a call, which is referred to as a CDR.
For information about EM-related operations on the Cisco BTS 10200 Softswitch, see the "Operations, Billing, and EM Transfer Procedures" section.
Figure 3 illustrates the PacketCable network elements that are involved in the EM process.
Figure 3 Event Message Interfaces
The EM related interfaces illustrated here are described as follows:
1.
2.
3.
4.
5.
PacketCable EMs can support billing and settlement activities for single-zone architectures. The originating and terminating CMSs exchange unique BCIDs and (FEIDs) for each half of the call. The originating CMS sends a BCID and an FEID in the INVITE message. The Cisco BTS 10200 Softswitch allocates the BCID for calls it originates or terminates. Along with the FEID, the BCID is used across network elements to reference calls. The FEID is provisioned on a system-wide basis (a single setting for the Cisco BTS 10200 Softswitch) as defined in the "Provisioning the System to Generate EMs for Billing" section.
Event Message Generation Details and Content
See the "EM Generation Details and Content" section for information on EM data.
Timestamp Support for Event Messages
The system-generated timestamps for EMs are based on the host operating system (OS) time and time zone. This data is not affected by command line interface (CLI) provisioning. The Solaris OS obtains the time automatically through Network Time Protocol (NTP) services.
Caution
Event Message Transport
Remote Access Dial-In User Service (RADIUS) is a client/server protocol used for Authorization, Authentication, and Accounting (AAA). The RADIUS protocol is an industry standard for remote access AAA defined in a set of Internet Engineering Task Force (IETF) standards: RFC 2865 and RFC 2866.
The RADIUS transport protocol is used between the Cisco BTS 10200 Softswitch (CMS/MGC) and the RKS. The system sends EMs to an RKS without waiting for acknowledgment of the previous message. The maximum number of pending ACK messages is 256.
EMs are first sent to the primary RKS. If the specified number of retry attempts fail, the EMs are sent to the secondary RKS. If one RKS is found to be unreachable, then the other RKS is considered for subsequent messages. If both the primary and secondary RKSs become unreachable, the EMs are stored in an error file on the hard disk (as described in the "Event Message Storage on the CA" section) and a timer is started. When the timer expires, newly arriving EMs are sent to the primary RKS.
If EMs are being sent to the primary RKS and the primary RKS goes down, the Cisco BTS 10200 Softswitch sends subsequent EMs to the secondary RKS. When the primary RKS comes back up, the Cisco BTS 10200 Softswitch continues to send EMs to the secondary RKS. (It does not automatically begin sending them to the primary RKS.) Provisioning of timers and retry attempts is described in the "Provisioning Support for EM Transmission and Storage" section.
Event Message Storage on the CA
Note
EMs are stored in the network element (CA) that generates them until they are transferred to the RKS. After receipt of the EMs is acknowledged by the RKS, they are deleted. The number of EMs generated by the Cisco BTS 10200 Softswitch depends on the number of calls processed. Multiple EMs are generated for each call. Depending on provisioning in the call-agent-profile table and the type of call, EMs can be generated by the CMS or MGC (or both) within the CA. The exact storage requirement varies depending on the rate of EM generation and how long the Cisco BTS 10200 Softswitch is required to keep the records before transferring them to an RKS.
The Cisco BTS 10200 Softswitch generates and stores EMs with the following characteristics:
•
•
•
Caution
The procedure for doing this is provided in the "Manual Recovery and Transfer of Stored EMs" section.
•
–
50 percent (minor alarm), 70 percent (major alarm), or 100 percent (critical alarm).–
–
PCMM-Based QoS for Type 1 Clients
This section describes the implementation of the PacketCable Multimedia (PCMM) feature that provides quality of service (QoS) for type 1 clients managed by the Cisco BTS 10200 Softswitch. This feature is applicable to endpoints using SIP, MGCP, or H.323 as the call signaling protocol.
Note
Figure 4 provides a sample system context for this feature.
Figure 4 Network Architecture with Policy Server and PCMM Interfaces
As shown in Figure 4, the PCMM implementation requires the Cisco BTS 10200 Softswitch to communicate with a policy server (PS), which is a third party device. For calls originating on, or terminating to a type 1 client, the Cisco BTS 10200 Softswitch acts as an application manager (AM) and sends requests to the PS for admission control through PCMM-based signaling. The PS in turn requests the CMTS to allocate bandwidth and other resources as in the request. After resources are allocated, the results are provided to the AM (via the PS) and the Cisco BTS 10200 Softswitch continues with call signaling to set up the call.
For the CLI provisioning procedure related to PCMM-based functions, see the "Provisioning PCMM-Based QoS for Type 1 Clients" section.
For maintenance commands related to the CMTS and PS, see the "Reset, Control, and Status Commands" section.
SOAP/XML Interface for CMS Subscriber Provisioning
This section describes the implementation of PacketCable CMS subscriber provisioning on the Cisco BTS 10200 with a Simple Object Access Protocol/Extensible Markup Language (SOAP/XML) interface.
This initial release supports only the Pkt-p1 interface to the PS/CMS and only the PcspService Object, without extensions. It supports a subset of the call feature objects in the ListOfCallFeatures element.
In the Pkt-p1 interface, the Cisco BTS 10200 Softswitch plays the role of CMS. Any third-party PS using SOAP Version 1.1 can provision the BTS. The requests and responses between the CMS and the PS are encapsulated in SOAP Version 1.1 messages. A secure transport protocol is provided by IPsec.
SOAP/XML Interface
Currently, a user can connect to a Cisco BTS 10200 CORBA server to access command templates and enter command executions, allowing system-to-system provisioning. The feature described in this document allows the XML commands to be transported by the SOAP transport protocol, rather than CORBA. Users of this feature communicate with a BTS SOAP server, which resides on the Cisco BTS 10200 EMS.
The Cisco BTS 10200 XML schema is a general purpose schema currently used by the XML/CORBA interface. The XML schema does not change with the incorporation of the SOAP transport protocol.
SOAP/XML Adapter and specifications are documented in the Cisco BTS 10200 Softswitch SOAP Adapter Interface Specification Programmer Guide.
System Components
CMS subscriber provisioning involves the interface between the following components:
•
•
CMS Subscriber Provisioning
CMS subscriber provisioning includes the operations necessary to provide a specified service to a customer and provides two main functions:
•
•
Call Features
The following call features are supported by the PacketCable CMS subscriber provisioning interface. The following list provides the name of each feature in PacketCable terminology, followed by the corresponding Cisco BTS 10200 feature in parentheses:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Prerequisites for CMS Subscriber Provisioning
This section lists requirements that must be met before provisioning the CMS subscriber.
•
•
Limitations on CMS Subscriber Provisioning
This section lists limitations. These are conditions for which the CMS subscriber provisioning is not designed to work.
•
•
•
•
Planning
Delivery of the features and functions described in this document requires interoperability with the network elements connected to the Cisco BTS 10200 Softswitch. See the "Component Interoperability" section in the Cisco BTS 10200 Softswitch Release Notes, which lists the specific peripheral platforms, functions, and software loads that have been tested by Cisco for interoperability with the Cisco BTS 10200 Softswitch.
Note
Installation
Installation of Cisco BTS 10200 Softswitch software follows a standard process. For details, see the Application Installation Procedure in the Cisco BTS 10200 Softswitch documentation set. Of the three main PacketCable feature areas (DQoS, EM, and security), two of them (DQoS and EM) are always installed, and do not require the setting of any special flags during software installation. However, the third area (security) is not installed unless a special flag (IPSEC_ENABLED) is set in the opticall.cfg file during software installation.
Caution
Provisioning Procedures
This section explains how to perform the following procedures:
•
•
•
•
These tasks include examples of CLI commands that illustrate how to provision the specific feature. Most of these tables have additional tokens that are not included in the examples. For a complete list of all CLI tables, tokens, descriptions, valid ranges, and default values, see the Cisco BTS 10200 Softswitch CLI Database.
Note
Provisioning Basic PacketCable and DQoS Features
This section describes how to provision the Cisco BTS 10200 Softswitch interfaces to connect to other PacketCable-based network elements (NEs) and how to select DQoS options. It includes the following tasks:
•
•
•
•
•
•
•
•
Provisioning CMS Parameters
This section describes how to provision DQoS functionality for the CMS logical entity on the Cisco BTS 10200 Softswitch (Call Agent).
SUMMARY STEPS
1.
2.
3.
4.
5.
Note
DETAILED STEPS
Provisioning the CMS Interfaces to the CMTS and eMTA
This section describes how to provision the interfaces to the CMTS and eMTA nodes. Specific tables are provisioned for each of these interfaces:
•
•
–
–
–
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Note
DETAILED STEPS
Step 1
Creates the CMTS (aggregation device) and enables DQoS support.
Caution
Step 2
add aggr id=cmts777;tsap-addr=ADDRESS123.cisco.com; aggr-profile-id=aggrprofile001
The TSAP-ADDR can be a DNS or IP address. If you enter a domain name system (DNS) address, it must be a fully qualified domain name (FQDN).
Step 3
add mgw-profile id=<id>; mgcp-version=<version>; mgcp-variant=<variant>; mgcp-default-pkg=LINE; mgcp-conn-id-at-gw-supp= [y | n];
Example:add mgw-profile id=mgwprofile777; mgcp-version=MGCP-1-0; mgcp-variant=NCS-1-0; mgcp-default-pkg=LINE; mgcp-conn-id-at-gw-supp=n;Creates the mgw-profile for this type of eMTA, and specifies values for the optional parameters.
The default values for these parameters might be adequate for your specific case. In each case, you can use the show command to find out how the parameter is currently set. See the Cisco BTS 10200 Softswitch CLI Database for parameter definitions and valid ranges.
Step 4
show mgw-profile;
Example:show mgw-profile id=mgwprofile777;
Shows the provisioned values for the parameters in the mgw-profile table.
Verify that the following values are present:
vendor=Cisco [or applicable vendor name]
mgcp-version=MGCP-1-0
mgcp-variant=NCS-1-0
mgcp-default-pkg=LINE
codec-neg-supp=y
pc-mptime-supp=y
mgcp-xdlcx-supp=n
domain-name-caching-supp=y
mgcp-conn-id-at-gw-supp=y
Step 5
change mgw-profile id=<id>; mgcp-version=<version>; mgcp-variant=<variant>;
Example:change mgw-profile id=mgwprofile777; mgcp-version=MGCP-1-0; mgcp-variant=NCS-1-0;
(Optional) If any of the mgw-profile token values (from Step 4) need to be changed, use the change mgw-profile command.
Step 6
add mgw id=<id>; tsap-addr=<tsap-addr>; call-agent-id=<id>; mgw-profile-id=<id>; type=rgw; aggr-id=<id>; node=<node>;
Example:add mgw id=CiscoGW50; tsap-addr=192.168.26.104; call-agent-id=CA146; mgw-profile-id=mgwprofile777; type=rgw; aggr-id=cmts777; node=main0044;
Creates the mgw id for a single eMTA, and specifies values for the other required parameters.
Be sure to set type=rgw or an eMTA.
You must enter the value for aggr-id to identify the appropriate CMTS for this eMTA.
The node token allows you to identify a hybrid fiber coax (HFC) node to which the eMTA is assigned. Typically, each eMTA is assigned to a node, and one or more nodes are assigned to a CMTS.
Step 7
add termination prefix=<prefix>; port-start=<port>; port-end=<port>; type=LINE; mgw-id=<id>;
Example:add termination prefix=aaln/; port-start=1; port-end=2; type=LINE; mgw-id=CiscoGW50;
Creates the line termination for the eMTA and specifies values for the required parameters.
For eMTA terminations, always enter type=LINE.
Step 8
control mgw id=<id>; target-state=INS; mode=forced;
Example:control mgw id=CiscoGW50; target-state=INS; mode=forced;
Brings the eMTA in service (INS state).
Step 9
status mgw id=<id>;
Example:status mgw id=CiscoGW50;
Verifies that the administrative state is INS.
Step 10
equip subscriber-termination id=<id>;
Example:equip subscriber-termination id=sub3456;
Equips the termination.
Step 11
control subscriber-termination id=<id>; target-state=INS; mode=forced;
Example:control subscriber-termination id=sub3456; target-state=INS; mode=forced;
Places it in service (INS state).
Step 12
status subscriber-termination id=<id>;
Example:status subscriber-termination id=sub3456;
Verifies that the administrative state is INS.
Provisioning DQoS Parameters for Codec Negotiation Service
The Quality of Service (qos) table is used in providing the codec negotiation service. Codec negotiation is the process the Cisco BTS 10200 Softswitch uses to find a common codec for the compression or decompression of a signal between two gateways. The Subscriber Profile (subscriber-profile) and Subscriber (subscriber) tables point to the qos table.
The following commands allow you to specify the required characteristics for these tables.
SUMMARY STEPS
1.
2.
3.
Note
DETAILED STEPS
Provisioning TGCP Interfaces to TGWs
This section describes how to provision the TGCP interfaces to the TGWs.
The mgw-profile table provides templates for defining each type of TGW by hardware vendor. It identifies the specifications and settings necessary for communications between the Cisco BTS 10200 Softswitch (which functions as the MGC) and each type of TGW. Several tokens in this table have values that can be overwritten after the Cisco BTS 10200 Softswitch (MGC) queries the TGW for supported capabilities. If the TGW returns a value different from the value originally provisioned in the Cisco BTS 10200 Softswitch, the returned value automatically replaces the originally provisioned value.
SUMMARY STEPS
1.
2.
3.
4.
5.
Note
DETAILED STEPS
