PPL Guidelines

This section gives general guidelines to follow when developing protocols. For more detailed information on using PPL for specific protocols, consult the API Reference and developer’s guides.

Idle State

The Idle state must be consistent with the default protocol for a component. A protocol must transition to the primary protocol without having any knowledge of the primary protocol's state/event and primitive table data.

T1 and E1

Since the E1 OOS protocol has no knowledge of the primary T1 and E1 protocol, the transmit IDLE line signaling ABCD bit values must be configured by sending a PPL Transmit Signal Configure message. This should be done prior to bringing the channel In Service. The Out of Service line signaling value is transmitted when a channel is being controlled by the OOS protocol (channel ID out of service).

Internal States

A given Internal State (test state) must accept all possible Internal PPL Events (test results) from a test AF that is invoked. The description of all test Atomic Functions indicate the possible Internal PPL Events that may be returned.

Multi-Purpose PPL Timers

Each component has 3 multi-purpose timers available for use within a protocol. These timers can be activated through an "Enable Timer" AF passing the timer number (1-3) in Arg1 and the preconfigured PPL timer setting ID (1-100) in Arg2. See the Overview section for more details on PPL Timers.

The preconfigured timer settings can be changed by the host using the PPL Timer Configure message. As timer adjustments are independent from the protocol tables you can modify a timer value without having to create new protocol tables.

When a timer expires, an event is generated into the PPL state machine for the associated channel. The timer events are numbers 191, 192, and 193.

Multiple Resident Protocols

The CSP allows for up to 10 custom protocols per component to be resident in the system at one time. Custom protocols can be given Protocol IDs from 1 to 10. Cantata default protocols begin at Protocol ID 11.

Call Processing

The CSP software architecture shown in the figure below is similar to the OSI Layered Model. Inter-Layer communications between Layer 3 and Layer 4 must take place for call management. Specific events and AFs are provided for each PPL component to manage call processing. This section describes the required Layer 3 to Layer 4 messaging for incoming and outgoing calls.

Figure 1-5 CSP 2000 Software Architecture

Incoming Call

Outgoing Call

Network-initiated Call Release

Host/Associated Party-initiated Call Release