Cisco BTS 10200 Softswitch

Table Of Contents

Cisco BTS 10200 Softswitch Sh Interface Feature Module

Introduction

Understanding the Sh Interface

BTS 10200 and HSS Communications

Sh Interface Commands

BTS 10200 Clustering

Limitations

Prerequisites

Provisioning

Adding Subscribers to HSS

Operating

Moving Subscriber Groups from BTS 10200 to BTS 10200

Purging Subscribers

Ensuring Data Match

Auditing and Synching Subscribers

Measurement Counters

Troubleshooting

Disaster Recovery

Cisco BTS 10200 Softswitch Sh Interface Feature Module

---

Revised: December 12, 2008

Introduction

This document describes the Sh interface between the Cisco BTS 10200 Softswitch acting as a Telephony Application Server (TAS) and a Home Subscriber Server (HSS). This document applies to BTS 10200 Release 6.0 MR1. It includes the following topics:

•Understanding the Sh Interface

•Limitations

•Prerequisites

•Provisioning

•Operating

•Measurement Counters

•Troubleshooting

Understanding the Sh Interface

HSS is an external database that stores BTS 10200 TAS subscriber profiles. HSS does not handle calls, but supports IP Multimedia Subsystem (IMS) network entities (like BTS 10200 and other switches) that do. HSS uses the subscriber profiles to locate subscribers. The BTS 10200 and HSS interact as follows:

1. An operator provisions TAS subscriber profiles on the BTS 10200.

2. The BTS 10200 stores the TAS subscriber profiles in its own databases on the Element Management System (EMS) and Call Agent (CA) or Feature Server (FS). These are the database tables:

–Emergency ANI

–HSS Public ID

–Screen List Editing (SLE)

–Single Number Reach (SNR)

–SIP Trigger Profile

–Speed Call: 1-Digit (SC1D)

–Speed Call: 2-Digit (SC2D)

–Subscriber

–Subscriber Feature Data

–Subscriber Service Profile

–Subscriber Time-Of-Day Schedule

3. The BTS 10200 pushes updated subscriber data to the HSS when either of the following occurs:

–An operator enters commands to retrieve, add, change, or delete subscriber data.

–A TAS subscriber uses their handset to control their calling features.

The BTS 10200 is the master database for subscribers. Provisioned subscriber data is saved in the BTS10200 first, then pushed to HSS for storage.

When the HSS is unreachable, you can still provision on the BTS 10200. The BTS 10200 queues transactions and when HSS becomes available, the BTS 10200 pushes the queued data to the HSS.

Table 1 describes the kind of subscriber data Sh requests by the BTS 10200 return.

Table 1 Subscriber Data from Sh Requests

Name	Description
Repository data	Transparent service data
Public identifiers	Subscriber's Public User Identities (PUIs)
IMS User State	not supported in current release
S-CSCF Name	not supported in current release
Initial Filter Criteria	not supported in current release
Location Information	not supported in current release
User State	not supported in current release
Charging information	not supported in current release
MSISDN	not supported in current release

BTS 10200 and HSS Communications

The HSS and BTS 10200 communicate using the Sh interface over the Diameter protocol. Diameter is a peer-to-peer protocol. The HSS and BTS 10200 communicate about subscriber data as follows:

•BTS 10200 queries subscriber profiles stored on the HSS.

•BTS 10200 registers/deregisters for subscriber profile updates.

•BTS 10200 updates subscriber profiles stored on the HSS.

•HSS notifies BTS 10200 when subscriber profiles change on the HSS.

The BTS 10200 generates and responds to Diameter command codes. Diameter uses these command codes to identify its message types.

The BTS 10200 connects to more than one HSS as a Diameter peer:

•Priority based—Primary and secondary HSSs mean all Diameter requests go to the primary. If the primary goes down, all requests go to the secondary.

•Round Robin—BTS 10200 sends Diameter requests evenly between operational HSSs.

Sh Interface Commands

The Sh interface operates in data handling mode or subscription/notification mode.

•Data handling is performed by a:

–Sh Pull request (Sh-Pull)—Retrieves data from the HSS

–Sh Update request (Sh-Update)—Sends data to the HSS

•Subscription/Notification (Sh-SubNotif) subscribes the BTS 10200 to get notified by the HSS when subscriber data updates.

•Notification (Sh-Notif) notifies the BTS 10200 when subscriber data is updated on the HSS by other network entities.

Each time the BTS 10200 requests access to subscriber data, the HSS uses a list to verify it has permission. HSS manages permissions using Sh-Pull, Sh-Update, and Sh-SubNotif. For example, the BTS 10200 may have permission to perform Sh-Pull, but not Sh-Update.

Table 2 describes Sh interface commands used to manage subscribers between the BTS 10200 and HSS.

Table 2 Sh Interface Commands by Pair

Command	Originator	Description	Response
User-Data-Request (UDR)	BTS 10200	This command requests data for a subscriber.	UDA
User-Data-Answer (UDA)	HSS	This command is a response to UDR.	N/A

Command	Originator	Description	Response
Profile-Update-Request (PUR)	BTS 10200	This command updates subscriber data.	PUA
Profile-Update-Answer (PUA)	HSS	This command is a response to PUA.	N/A

Command	Originator	Description	Response
Subscribe-Notifications- Request (SNR)	BTS 10200	This command subscribes/unsubscribes for notifications when a subscriber's information changes.	SNA
Subscribe-Notification- Answer (SNA)	HSS	This command is a response to SNR.	N/A

Command	Originator	Description	Response
Push-Notification-Request (PNR)	HSS	This command sends subscriber data changes to the BTS 10200.	PNA
Push-Notification-Answer (PNA)	BTS 10200	This command is a response to PNR.	N/A

BTS 10200 Clustering

Clustering (grouping) BTS 10200s improves service availability and allows you to be flexible in provisioning subscribers and features. In a cluster, each BTS 10200 serves its own subscribers. Clustering requires no special provisioning, it is simply a matter of how you organize your network.

You can move some or all of these subscribers to another BTS 10200 in the cluster during a planned migration or disaster recovery. Because each BTS 10200 stores its subscriber data in the HSS, during migration or disaster recovery, the destination BTS 10200 pulls subscriber data from the HSS.

See Moving Subscriber Groups from BTS 10200 to BTS 10200 for more information.

Each BTS 10200 has its own BTS-id. This BTS-id is checked against the subscriber group owner to determine whether that BTS 10200 owns the subscriber. To update a subscriber's data, make changes on the BTS 10200 that owns the subscriber's public-ID. Other BTS 10200s have read-only access to each other's subscribers. However, a subscriber with the handset provisioning feature can update their data via any BTS 10200 in the cluster.

Limitations

Release 6.0 MR1 of the BTS 10200 only supports HSS interaction for TAS subscribers; it does not support the following subscriber types:

•Cable (MTA)

•Centrex Group

•H.323

•ISDN

•IVR's access DN for IVR

•MGCP (IAD)

•MLHG

•NCS

•PBX

•Remote Call Forwarding's (RCF's) virtual subscribers

•Remote Activation of Call Forwarding's (RACF's) access DN

•SIP (non-TAS)

---

Note The transaction queue HDM process must be fully initialized before the CLI/CPM/CPI processes can write HSS requests into TRANSACTION_QUEUE table for BTS-to-HSS requests. In case when platform has just started or re-started, if the user requests some BTS-to-HSS commands, the commands will fail in the time elapse when the HDM process is not fully initialized. The HDM process takes some time to fully initialize.

---

Prerequisites

Table 3 lists tasks to complete before you begin provisioning TAS subscribers to work with the HSS.

Table 3 Pre-provisioning Checklist.

Tasks
	The BTS 10200 has been installed/upgraded to support the Diameter protocol.
	The BTS 10200 and HSS are connected.

  

Provisioning

This section explains how to perform provisioning tasks for this feature.

Adding Subscribers to HSS

Each TAS HSS subscriber must:

•Belong to a subscriber group, the BTS 10200 stores this as the Subscriber-serving-group-id in the HSS Public-ID table.

•Be assigned an owner BTS 10200, the BTS 10200 stores this as the Table Subscriber-serving-group.

Each TAS HSS subscriber group must have a:

•DNS name—Ensure this matches the AS name in the Initial Filter Criteria.

•CNAME record

Before adding a subscriber to the HSS, ensure the BTS-PUBLIC-ID table is already provisioned with the subscriber group's public-ID.

Table 5 describes tables on the BTS 10200 required for HSS subscribers:

Table 4 Required HSS Database Tables

Required HSS Database Tables
The following tables are directly required: •SUBSCRIBER_PROFILE •QOS •LANGUAGE •COS_RESTRICT •DN2SUBSCRIBER—Remove any entry here before converting a non-HSS subscriber into a TAS subscriber. •APP_SERVER •VOICE_MAIL_ID •PRIVACY_MANAGER_ID
The following tables are indirectly required: •SIP_TRIGGER_PROFILE •SERVICE •FEATURE •MGW •OFFICE_CODE •NDC •EXCHANGE_CODE

Table 5 describes BTS 10200 database tables on the BTS 10200 that point to table entries on the HSS.

Table 5

BTS 10200 Database Table Name	HSS Database Table Entry
ANI_SCREENING	dummy non-HSS subscriber
AOR2SUB	non-HSS subscriber
CENTREX_GRP	dummy non-HSS subscriber
DN2SUBSCRIBER
EMERGENCY_ANI
EXT2SUBSCRIBER	non-HSS subscriber
H323_TERM	non-HSS subscriber
HSS_PUBLIC_ID
MAC2SUB	non-HSS subscriber
MLHG	dummy non-HSS subscriber
POP	dummy non-HSS subscriber
SC1D	HSS table
SC2D	HSS table
SIP_TRIGGER_PROFILE
SLE	HSS table
SNR
SUBSCRIBER
SUBSCRIBER_FEATURE_DATA	HSS table
SUBSCRIBER_SERVICE_PROFILE	HSS table
SUBSCRIBER_SIP_TRIGGER_PROFILE	HSS table
SUBSCRIBER_TOD_SCHEDULE	HSS table
TERMINATION	part of Subscriber table + termination table status
TRUNK_GRP	dummy non-HSS subscriber

BTS 10200 Database Tables and HSS Database Table Entries

---

Step 1 Add the TAS subscriber.
CLI> add subscriber id=209-222-3601; category=INDIVIDUAL; term_type=TAS

Step 2 Add the BTS 10200 public-ID.
CLI> add bts-public-id public-id=abc@cisco.com; sub-id=209-222-3601; ring_type=xxx

Step 3 Add the subscriber's group.
CLI> add subscriber-serving-group id=g1; owner=CA146;

Step 4 Create the HSS public-ID.
CLI> create hss-public-id public-id=abc@cisco.com; subscriber-serving-group-id=g1; first-update=y

Step 5 Push the HSS public-ID from the BTS 10200 to the HSS. (optional)

CLI> push hss-public-id public-id=abc@cisco.com;

---

Operating

This section explains how to perform operational tasks for this feature.

•Moving Subscriber Groups from BTS 10200 to BTS 10200

•Purging Subscribers

•Ensuring Data Match

•Auditing and Synching Subscribers

Moving Subscriber Groups from BTS 10200 to BTS 10200

When moving subscribers from one BTS 10200 to another BTS 10200 in the cluster, divide subscribers into groups. Use one of the following criteria that best meets your needs:

•Geography

•Rate Center

•Administrative grouping

When choosing group size, consider the following:

•Large groups mean fewer groups, but large ones.

–Fewer groups mean less chance of operator error.

–Fewer groups mean a large amounts of subscribers per group. A disaster suddenly increases the load on the BTS 10200.

•Small groups mean many groups, but small ones.

–Many groups mean more chances of operator error.

–Many groups mean smaller amounts of subscribers per group. A disaster results in an even load distribution to multiple BTS 10200s

---

Step 1 Stop provisioning.

Step 2 On the current BTS 10200, in the table_subscriber_serving_group, change the owner to the future owner BTS 10200.

Step 3 On the future owner BTS 10200, enter the following to pull the data from the HSS:
CLI> pull hss-public-id public-id=abc@cisco.com

Step 4 On the current BTS 10200, change the DNS Group1 name to point to the future owner BTS 10200:

Step 5 On the future owner BTS 10200, change the owner of Group1 in table subscriber-serving-group to the future owner BTS 10200.

---

Purging Subscribers

Any BTS 10200 in a cluster can download subscriber data, but one BTS 10200 lacks capacity to store all subscribers in a cluster. When a BTS 10200 reaches maximum capacity it will be unable to pull new subscriber data from the HSS. To avoid this, manually purge all subscribers not owned by this BTS 10200.

Purging an HSS public-ID does the following:

•Removes the public-ID from the HSS-public-id and BTS-public-id tables

•Deletes the public-ID's subscriber-related tables

•Deletes all subscribers referenced by the public-id from the SUBSCRIBER table

To purge an HSS public-ID, enter the following:

CLI> purge hss-public-id public-id=xxxx;

To delete subscriber-related tables for all subscribers in this serving group:

CLI> purge hss-public-id subscriber-serving-group=xxxx;

Ensuring Data Match

Before Moving Subscriber Groups from BTS 10200 to BTS 10200 do the following procedure.

---

Step 1 On the current BTS 10200, create a list of public-ids in Group1.

Step 2 Copy the list to the future owner BTS 10200.

Step 3 Using the list, the future owner BTS 10200 pulls each subscriber's data from the HSS.

---

Auditing and Synching Subscribers

The BTS 10200's EMS does periodic background audits with the HSS. If the EMS finds an inconsistency, it synchronizes the data. If the BTS 10200 owns the subscriber group, its data overwrites that on the HSS. If the BTS 10200 does not own the subscriber group, the HSS data overwrites that on the BTS.

For each ServingIndication the BTS 10200 sends a User-Data-Request to the HSS. The local subscriber table is compared to the User-Data-Answer and no update is made to HSS-REPOSITORY-DATA table.

If the BTS 10200 owns the subscriber group for this public-id, the BTS 10200 sends a Profile-Update-Request to the HSS for each serving indication.

If the BTS 10200 does not own the subscriber group for this public-id, the BTS 10200 sends a User-Data-Request to the HSS for each subscriber group. If there is a mismatch, the HSS-REPOSITORY-DATA table updates.

To perform a data audit with the HSS, enter the following:

CLI> audit hss-public-id public_id=xxxx;

CLI> audit hss-public-id all=Y;

To synchronize with the HSS, enter the following:

CLI> sync hss-public-id public_id=xxxx;

CLI> sync hss-public-id all=Y

Measurement Counters

The BTS 10200 keeps counters for both base Diameter messages and Sh Diameter messages. You can reset (clear) measurement counters for both types.

Table 6 lists the measurement counters related to Diameter messages:

Table 6 Diameter Message Measurement Counters

Name	Description
DI_TX_DEVICE_WATCHDOG_REQ	Diameter Device-Watchdog-Request transmitted
DI_RX_DEVICE_WATCHDOG_REQ	Diameter Device-Watchdog-Request received
DI_RX_DEVICE_WATCHDOG_ANS	Diameter Device-Watchdog-Answer received
DI_TX_DEVICE_WATCHDOG_ANS	Diameter Device-Watchdog-Answer transmitted
DI_RX_CAPABILITY_EXCHANGE_REQ	Diameter Capability-Exchange-Request received
DI_TX_CAPABILITY_EXCHANGE_REQ	Diameter Capability-Exchange-Request transmitted
DI_RX_CAPABILITY_EXCHANGE_ANS	Diameter Capability-Exchange-Answer received
DI_TX_CAPABILITY_EXCHANGE_ANS	Diameter Capability-Exchange-Answer transmitted
DI_RX_DISCONNECT_PEER_REQ	Diameter Disconnect Peer Request received
DI_RX_DISCONNECT_PEER_ANS	Diameter Disconnect Peer Answer transmitted
DI_RX_SESSION_TERMINATION_REQ	Diameter Session-Termination-Request received
DI_RX_SESSION_TERMINATION_ANS	Diameter Session-Termination-Answer received
DI_RX_ABORT_SESSION_REQ	Diameter Session-Termination-Answer transmitted
DI_TX_ABORT_SESSION_REQ	Diameter Abort-Session-Request received
DI_RX_ABORT_SESSION_ANS	Diameter Abort-Session-Answer received
DI_TX_ABORT_SESSION_ANS	Diameter Abort-Session-Answer transmitted
DI_USER_DATA_REQ	Diameter User-Data-Request
DI_USER_DATA_ANS	Diameter User-Data-Answer
DI_PROFILE_UPDATE_REQ	Diameter Profile-Update-Request
DI_PROFILE_UPDATE_ANS	Diameter Profile-Update-Answer
DI_SUBSCRIBER_NOTIFICATION_REQ	Diameter Subscriber-Notification-Request
DI_SUBSCRIBER_NOTIFICATION_ANS	Diameter Subscriber-Notification-Answer
DI_PROFILE_NOTIFICATION_REQ	Diameter Profile-Notification-Request
DI_PROFILE_NOTIFICATION_ANS	Diameter Profile-Notification-Answer
DI_SH_ERROR_MSG	Diameter Sh Interface error message

Troubleshooting

This section explains how to troubleshoot disaster recovery.

Disaster Recovery

The Diameter Request policy PRIORITY-ORDER means the BTS 10200 always selects the Diameter peer with the highest priority as long as the peer is operational. It prevents switchover if all the peers go down.If the BTS 10200 cannot establish a connection with the highest priority peer, it resends the pending transactions to the peer with the second-highest priority. If the higher priority peer comes back up, the BTS 10200 sends new Diameter requests to the higher priority peer.

During switchover the BTS 10200 does the following:

1. Tears down Diameter connections on the previously-active side.

2. Creates Diameter connections from newly-active side to all Diameter peers IN-SERVICE.
or
If peers are unreachable, the BTS 10200 active side does not switchover. Instead it attempts to reestablish the connection with its peers using DIA_REATTEMPT-INTERVAL and DIA_RETRY_COUNT.
DIA_REATTEMPT-INTERVAL—number of seconds until the DIA_RETRY_COUNT is
DIA_RETRY_COUNT

3. The BTS 10200 active side re-attempts to setup the Diameter connection.

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)

Copyright © 2008 Cisco Systems, Inc. All rights reserved.