4.1 User Messages
SMS/800 is responsible for administering both customer-specific data and noncustomer- specific (e.g., administrative) data in the CMSDB. Hence, SMS/800 must have the ability to send commands to update both types of data. The CMSDB does not send commands to SMS/800 and, therefore, SMS/800 does not respond to commands from the CMSDB. The CMSDB, however, does generate exception, scheduled, and measurement reports, which are sent to SMS.
The user messages between SMS/800 and the CMSDB define a protocol that is implemented as part of the application software. This "message layer" protocol takes on the form of commands and responses that must be understood by SMS/800 and the CMSDB, and correlated so that the status of records at the SCPs is known by SMS/800 at all times. The user relies on the lower level protocols for correct message transport between SMS/800 and CMSDB. The protocol requires the message layer to accept duplicate messages.
Message types are divided into commands sent from SMS/800 to the CMSDB, responses the CMSDB makes to these commands, and reports the CMSDB sends on a scheduled or event-driven basis. See the following subsections for details.
NOTE All SMS/800 - SCP messages are SCP CMSDB messages, except for the ISA messages, which are SCP Node messages.
4.1.1 CPR Data Maintenance Commands
For maintaining CPR data, SMS/800 uses an update-UCR (UPD-UCR) command and an audit-CPR command.
The normal throttling level is assigned to the UPD-UCR command and a low throttling level is assigned to the audit-CPR command. Users of SMS/800 may assign different throttling levels as required on an individual command basis.
4.1.1.1 Update Customer Record Command
The UPD-UCR command is used to replace a CPR or delete a CPR. When replacing the CPR in the CMSDB, if the CPR does not exist it is added or it is modified if it does.
Updates to CPRs are by complete CPR replacement in the CMSDB. Even parameter updates, which are usually for emergency purposes, are accomplished by the UPD-UCR command. New values for the predefined fields in a CPR (i.e., switch node, terminating telephone number and percent allocation) are updated by completely replacing the existing CPR with an updated CPR.
A customer sample at the SCP is initiated for a customer by SMS/800 sending an UPD- UCR command for the particular CPR in question. An UPD-UCR command is used to set the sample rate to non-zero (i.e., 1-100), thus initiating sampling. Sampling is terminated by sending another UPD-UCR command to reset the sample rate to zero.
An UPD-UCR command is also used to set the threshold level class for network management purposes. The threshold level class is based on the number of access lines a customer has for their service. Once calls to a customer's destination number exceed the threshold level, the destination number is placed under surveillance automatically by network management controls in the CMSDB.
NOTE The threshold level is calculated based on the number of Lines field on the Basic Customer Record (CAD) that the Resp Org entered for each Destination number of a specific customer record (CR).
The success or failure of an UPD-UCR command is acknowledged by a response message from the CMSDB. The response message is Response to Customer Update (RSP-RCU). The RSP-RCU response indicates that the corresponding UPD-UCR command was either accepted and properly installed in the CMSDB, or rejected because of failure of a validity check in the CMSDB. An example of a validity check is: unassigned dialed NPA-XXX code to this CMSDB. The RSP-RCU response also acknowledges failure from implementation considerations, such as insufficient file space, disk errors, etc.
NOTE For example, an SCP may choose to not handle 866-555. In that case, it would reject any update to 866-555-xxxx. The list of assigned NPA-NXXs is entered in SMS/800 and then sent to the SCP via the Master Number List (MNL).
4.1.1.2 Audit Customer Record Command
The second command related to CPR maintenance is the audit-CPR (AUD-CPR) command. AUD-CPR is used to verify that the copy of the CPR in the CMSDB matches the SMS/800 record that is designated as being active in the CMSDB. The AUD-CPR command causes the translated CPR from SMS/800 to be compared to the installed version in the CMSDB. As the CMSDB may perform additional processing on a translated CPR from SMS, the comparison occurs at the SCP.
The results of the comparison are acknowledged by CMSDB sending to SMS/800 a RSP- AUD response. The RSP-AUD response indicates success or failure of the comparison.
Note that the AUD-CPR command compares the elements of the CPR in the CMSDB to what SMS/800 sends, and therefore can be used to verify parameter settings that may have been changed for emergency purposes.
4.1.2 Administrative Commands
Administrative commands may be grouped according to the following categories:
- Sample Request Control
- Special Studies
- Call Processing Parameter Control
- Network Management
- Common Administrative Data
- Noncustomer Data Audit
- Status Data
The commands in each of the above categories are described next. The throttling level associated with each command is specified by the requester at the time the command is issued.
4.1.2.2 Special Studies
Special studies are requested by service maintenance and network management personnel. The command sent by SMS/800 is an Enter Special Study List (ENT-SSL), which identifies the special study type (e.g., destination number study), number of attempts for which call data will be collected, maximum number of minutes study will be in effect, and other data. The Delete Special Study List (DLT-SSL) command removes a special study from the list.
The RSP-SSL response acknowledges the result of the ENT-SSL and DLT-SSL commands. The ENT-SSL command may have failed, for example, because there is no room on the special study list.
A special study report is sent by CMSDB, as described in section "Special Study Reports".
4.1.2.4 Network Management
Network management commands are used in managing traffic overloads appearing at the CMSDB.
Commands from SMS/800 are used to:
- set CMSDB overload gap and duration levels
- set destination number surveillance and control levels
- set call-completion computation option
- set nonpurchased area of service and vacant code control levels
- activate manual controls
Commands in these categories are described next:
A. Destination Number Surveillance/Control Levels
To control mass calling to destination numbers, SMS/800 must be able to change the assignment of a surveillance threshold (attempts/destination/2.5 minutes) for detecting focused overloads, and a control threshold for initiating controls to each of 15 threshold level classes in the CMSDB. The command to update the threshold assignment to the 15 level classes is Update Destination Threshold Table (UPD- DTT). The complete table is sent to CMSDB with this command. The response is RSP-DTT.
For individual destination number control, SMS/800 must also be able to change the initial mass calling control level, which is the same for all destination numbers. The command for changing the initial control level of a destination number initially placed under control is Update Destination Threshold Table (UPD-DTT). The response to this command is RSP-DTT.
B. Call-Completion Computation
For destination numbers under control or surveillance, CMSDB calculates a destination percent failure rate based on answer/no answer statistics collected by the SSP. Although valuable to network managers for deciding when to override automatic controls or adjust threshold level class assignments, the option is available to turn off the capability by having SMS/800 issue an Update NM Call Completion Option (UPD-CCO) command. The option eliminates the need for CMSDB to collect call-completion data on calls under control or surveillance. The response returned to SMS/800 is RSP-CCO.
C. Non-purchased area of service and Vacant Code Control Levels
SMS/800 must be able to change the 6 digit nonpurchased area of service attempt threshold, for detecting excessive calling to a dialed "800 Service" NPA-XXX, and the 10 digit nonpurchased area of service attempt threshold, for detecting excessive calling to a dialed NPA-XXX-XXXX within a NPA-XXX. In addition, a decontrol threshold, for removing nonpurchased code controls, must be provided by SMS. The command for updating the two control thresholds and the decontrol threshold is Update Network Management Parameters (UPD-NMP). The response to this command is RSP-NMP.
SMS/800 must also be able to change the 6 digit vacant code attempt threshold, for detecting excessive calling to vacant dialed NPA-XXX codes, and the 10 digit vacant code attempt threshold, for detecting vacant dialed NPA-XXX-XXXX lines in a nonvacant NPA-XXX code. In addition, a decontrol threshold, for removing controls on vacant codes, must be provided by SMS. The command for updating the two control thresholds and the decontrol threshold is Update NM Parameter (UPD- NMP). The response to this command is RSP-NMP.
D. Manual Controls
The CMSDB may add/remove dialed "800 Service" NPA-XXX-XXXX codes or destination numbers from its manual control list upon request from SMS. For each call to a code on the manual control list, CMSDB sends an ACG command to the SSP that contains the gap interval, control duration, and treatment specified by SMS.
The command that SMS/800 issues to activate the CMSDB manual control is Enter Manual Control List (ENT-MCL). This command specifies the codes to be controlled, the type of codes (destination or dialed number), the gap interval levels, the control durations, and the treatment of blocked calls. To deactivate a manual control, SMS/800 sends a Delete Manual Control List (DLT-MCL) command.
The response to ENT-MCL and DLT-MCL is RSP-MCL. RSP-MCL may indicate a failure if, for example, a number is already under control, the control list is full, or a data syntax error exists.
4.1.2.5 Common Administrative Data
The CMSDB requires Master Number Lists of dialable "800 Service" NPA-XXXs for call processing. SMS/800 updates this data with an Update Master Number list (UPD-MNL) command and receives a RSP-MNL response. The list of assigned dialed NPA-NXX is communicated from SMS/800 to the SCP via the Master Number List (MNL). For example, an SCP may choose to not handle 866-555. In that case, it should reject any update to 866-555-xxxx.
The exception report threshold controlling the generation of CPR execution error reports is updated with the Update Exception Threshold Table (UPD-ETT) command; the response is RSP-ETT.
The CMSDB also requires exception report thresholds to control the generation of misrouted error and overflow of sample data exception reports. These thresholds are updated with the Update Application Level Parameter (UPD-ALP) command; the response is RSP-ALP.
NOTE The Master Number List (MNL) is the list of all toll-free NPA-NXXs that SMS/800 will provide updates to a specific SCP. SMS/800 sends 1 UPD-MNL message per Toll-Free NPA. In another words, the UPD-MNL message cannot contain more than 1 NPA.
4.1.2.6 Noncustomer Data Audit
SMS/800 can retrieve certain noncustomer data. The command Retrieve Noncustomer Data (RTRV-NCD) directs the CMSDB to return the following data:
- Application sample rate
- Transaction age timer
- Overload level gap and duration assignments
- Destination number surveillance/control levels
- Initial mass calling control level
- Non-purchased area of service and vacant code control levels
- Override indication for initiation of automatic controls on a per IC basis
- Call completion option setting (for scheduled destination-number reports)
- Special study list
- Manual control list
- Exception-report thresholds
The response to RTRV-NCD is RSP-NCD (response to retrieve noncustomer data). SMS/800 compares the retrieved data to values stored in its own data base.
In addition to the above data, the command Retrieve Master Number List (RTRV-MNL) directs the CMSDB to return the Master Number List. The list is returned in the response RSP-RML. SMS/800 compares the retrieved Master Number List with the values stored in its own data base.
4.1.2.7 Status Data
The term ‘status data’ is used to describe those messages that SMS/800 and the SCPs use to keep each system apprised of the other’s status.
The status items of concern are the states (e.g., active, inactive, disabled) of the SCP node and each SCP application, as well as the SCP overload condition. In addition, SMS/800 assists in updating applications as it is initialized at an SCP or reinitialized after a failure occurs.
Status messages are automatically sent by the SCP node when an application changes status, or when the communication link is (re)initialized. In addition, SMS/800 may request a status update on the SCP node, applications, or overload condition. The throttling parameter of all status data transactions is critical. Status messages from the SCP should not be queued.
A status message is used by the node to report application status. A status message indicates both overload condition (level 0-6) and application condition (disabled, inactive, active, active and assuming mate’s traffic). There are two conditions under which a status message is sent. The procedures for each are as follows:
First, a REPT-ISA message is sent by the SCP to SMS/800 each time the SCP application status changes. REPT-ISA is an unsolicited message, meaning it is sent by the SCP without being requested by SMS/800. If the change is in application condition (e.g., disabled to inactive), the node should send a REPT-ISA message for that application. If only the overload condition changes, the node should send a single REPT-ISA message with application parameter node. The SCP will then send a copy of this message for each application.
Second, if SMS/800 chooses to check the status of an application, SMS/800 sends a ‘Retrieve Indicated Status Application’ (RTRV-ISA) message to the SCP node. A parameter in the RTRV-ISA message indicates which application the message is associated with. The SCP responds with a Response Indicated Status of Application (RSP-ISA) message. If SMS/800 chooses to check the overload condition of the SCP, SMS/800 should send a RTRV-ISA message with application parameter as ‘node’.
In addition to the active, inactive, and disabled status, another application status is possible. Applications with a mate elsewhere in the network should assume the traffic of the mate in case of failure. The assumption and release of mate traffic are considered status changes, and the SCP node should inform SMS/800 of the changes via the REPT-ISA message.
After handshaking between an SCP and SMS/800: SMS/800 will send the RTRV-ISA message, and subsequently the SCP should respond with the RSP-ISA message, and then SMS/800 will process the RSP-ISA as REPT-ISA.
4.1.3 Reports
The CMSDB report messages sent to SMS/800 may be divided into three categories:
- exception reports
- scheduled reports
- special study reports
Reports in each category are described next.
4.1.3.1 Exception Reports
The CMSDB generates the reports below if the exception event occurs and the exception threshold indicates a report should be sent. An exception threshold either indicates reports are always generated or contains a threshold value, N. In the latter case, the CMSDB reports only the first N exception events in a five-minute period.
When a code is added/removed from surveillance or control, or when a code cannot be added to a CMSDB control list (overflow), the CMSDB generates a Network List Change (REPT-NLC) exception report. When an SSP cannot activate a manual control (SMS- initiated) because the SSPs control list is full, the CMSDB sends a Network SSP Overflow (REPT-NSO) report to SMS. Note that an REPT-NSO report is not generated when an automatic control cannot be activated at the SSP. The thresholds for these exceptions are updated with UPD-NMP (see "Network Management").
An exception report is issued by CMSDB whenever a CPR execution error occurs. The report is called the Execution Error Report (REPT-EER). The threshold controlling the generation of this exception report is updated with the UPD-ETT command (see "Common Administrative Data").
Finally, a misrouted query to CMSDB (i.e., dialed NPA-XXX belongs to another SCP) will cause CMSDB to issue an exception report. This report identifies the dialed number and is called the Misrouted Error report (REPT-MER). The associated threshold is updated with UPD-ALP (see "Common Administrative Data").
4.1.3.2 Scheduled Reports
Every 2.5 minutes the SCP CMSDB may schedule a Scheduled Destination Report (REPT-SDR) containing each dialed number or destination number (POTS or returned dialed number) that is under control (automatic or manual) or surveillance. When no numbers are under control or surveillance, then a last report is sent indicating this is the case.
Every 5 minutes the SCP CMSDB may schedule a Scheduled Non-purchased Area of Service Report (REPT-SNR) and a Scheduled Vacant Code Report (REPT-SVR) whenever a 10-digit or 6-digit dialed number is under automatic control. When no calls are under automatic control, the last REPT-SNR and REPT-SVR reports indicate none on the control list.
4.1.3.3 Special Study Reports
Special studies are requested by service maintenance and network management personnel. A special study is limited by both time and number-of-calls. The CMSDB is scheduled to generate a Special Study Report (REPT-SSR) every 30 minutes, or whenever the SMS/800 specified number of attempts have been reached, or whenever the predefined time period is reached. These reports are generated for each special study in progress.
4.1.4 De-Queued Messages
When the SCP and the SMS/800 cannot communicate because of a link failure or SCP failure or SMS/800 failure or long response times (e.g., SCP overload), the messages are queued according to their queuing criteria.
- When communication is restored, the SCP issues a status change message (REPT- ISA) and sends any queued messages to SMS/800. Based on the status in the REPT- ISA message, SMS/800 may send queued messages to the SCP. If so, then after all the queued messages are sent, SMS/800 will send a Tell CMSDB Update Complete command (TELL-CUC) to the SCP. Otherwise, messages remain queued until an REPT-ISA message is received which reports a recovered, non- overload condition.
Note: A Good Day message must be sent before an ISA message can be sent.
When SMS/800 sends a RTRV-ISA message yet the SCP NODE either replies with an incorrectly formatted message or does not reply, then SMS/800 queues the NODE messages. Subsequently when the SCP sends a Good Day message to SMS/800, then SMS/800 dequeues the NODE messages (sends them to the SCP). When SMS/800 dequeues all its NODE messages, then SMS/800 sends a Tell NODE Update Complete command (TELL-NUC) message to the SCP.
4.2 Performance
4.2.1 Response Times
The CMSDB is required to send SMS/800 a message in response to one of two types of events: the receipt of an SMS/800 command message, or some event requiring SMS/800 notification via an autonomous report (exception or scheduled).
Requirements:
- The CMSDB should be able to process 1200 (or more) SMS/800 commands (e.g., delete, replace, sampling, UPD-UCR messages) a minute, and should be able to sustain this rate for at least 10 hours.
- The SCP CMSDB and SMS/800 platform shall be capable of processing at least 20 UPD- UCR messages per second for at least 10 consecutive hours.
Note: The actual message frequency depends on a number of factors, including the growth of 800 Service, the number of times customer records have a change of a SCP affecting service parameter, the number of NPA Splits, etc.
Additional growth in 800 Service and/or future upgrades in line speeds may require that more than 1200 SMS/800 commands be processed in a minute.
4.2.2 Data Rates
The SMS/800-SCP interface and each SCP and SMS/800 are required to support the following data rates as the minimum supported non-peak rates.
|
Data Type |
Data Rate |
|
Customer Sample |
10.89 megabytes/day/SCP |
|
Application Sample |
6.42 megabytes/day/SCP |
|
CPR Update-audits |
634 megabytes/day/SCP |
|
NM 2.5 Minute Reports |
102 kilobytes/hour/SCP |
|
Customer Record |
9.6 KB/CR * 20 CRs/second or 192 kilobytes/second/SCP or 1.536 megabits/second/SCP |
|
Other |
88 kilobytes/hour/SCP |
4.3 Operations and Maintenance
4.3.1 CMSDB Initialization
CMSDB initialization includes activities needed between the time the CMSDB software is loaded on the SCP until the CMSDB application is ready to process SS7 queries. The following steps are necessary:
- The SMS/800 and SCP hardware, software, and communications environment must be installed, generated, and field tested.
- Specific SMS/800 and SCP Administration tables must be generated by Software Support prior to the CMSDB load as described in the SMS/800 User Guide: SCP Turnup (BR 780-004-212).
- When SMS/800-SCP communications are established, the SMS/800 sends the tables needed for initial load over the SMS/800-SCP links. The SMS/800 then sends a "RTRV-NCD" (retrieve non-customer data) and a "RTRV-MNL" (retrieve master number list) request to the SCP. When the tables are successfully loaded, the SCP responds with a "REPT-NCD" message (report non-customer data) and a "REPT- MNL" message (report master number list).
- Upon receipt of these messages from the SCP, SMS/800 Operations will generate the SCP Incremental Load File, which will be delivered to the SCP via express mail services.
- Upon receipt of the load file, the SCP will process the file to load the SCP CMSDB. If the SCP completes the load with an acceptable rate of error, SCP Operations personnel will:
a. Generate the Load Response File and send it to SMS/800 Operations via electronic method or via express mail service if sending a USB flash drive. Please contact Data Center before creating or sending a file to confirm the media format that the Data Center supports.
b. Phone the SMS/800 Operations and request submission of the Batch Retransmit job, which will resend all Customer Record Updates for that SCP that have occurred since the time the SCP Incremental Load File creation process began at SMS/800 Operations.
c. SMS/800 Operations will process the response file upon receipt. Any problems (missing records, extraneous records, errors, et) will trigger an exception report which will be sent to the Number Administration Service Center (NASC).
- When the Batch Retransmit job has run, and all queued Customer Records have been transmitted, SMS/800 then transmits a TELL-CUC message to the SCP signifying end of Customer Record transmission.
- SMS/800 Administration personnel will select a minimum of 12 Customer Records which have the SCP being turned up in their area of service. Next, the SMS/800 Administration personnel will perform a manual audit, which issues an "AUD-CPR" message (audit call processing record) to the SCP to request verification that the selected records have been transmitted to the SCP.
- When transmission of the Customer Records has been verified at the SCP, the SCP responds by sending a "RSP-AUD" (response audit) message to the SMS.
- If verification fails, a new SCP Incremental Load File must be created, and the CMSDB load must be redone.
4.3.2 Recovery
Three possible scenarios require data recovery procedures: the SMS/800 cannot communicate with an application, all SCP disks become corrupted, and an external catastrophe (e.g., flooding).
Different events could prevent the SMS/800 from updating the CMSDB, including link failures, CMSDB failures, and SCP failures. Section 3.1 discusses the communication procedures followed during such failures. In brief, the SMS/800 queues any updates that occur during a failure and transmits them once SMS/CMSDB communication is restored.
It is assumed that the SCP maintains several copies on disk of the on-line data. Therefore, the probability that all disks become corrupted without some external catastrophe is small. To recover the data, the standard initialization procedures could be followed. Alternatively, the data could be recovered from the most recent backup disk copy. Data changes that occurred since the backup copy had been made would then be loaded. Note that the SCP operator must identify procedures for loading the data changes not found on the backup copy.
Catastrophes are assumed to affect the SCP hardware itself. Therefore, procedures discussed in this section and the previous section would be necessary.