Call Control SCF

29.198-04-13GPPOpen Service Access (OSA) Application Programming Interface (API)Part 4: Call controlRelease 9Subpart 1: Call control common definitionsTS

Four flavours of Call Control (CC) APIs have been included in 3GPP Release 7. These are Generic Call Control (GCC), Multi-Party Call Control (MPCC), Multi-Media Call Control (MMCC) and Conference Call Control (CCC). The GCC is the same API as was already present in the Release 99 specification (TS 29.198 v3.3.0). Multi-Party Call Contorl was introduced in the Release 4 specifications, and Multi-Media Call Control is introduced in Release 5. Conference Call Control was introduced in Release 7.

The joint work between 3GPP CT5, ETSI TISPAN and the Parlay CC Working group with collaboration from JAIN has been focussed on the MPCC and MMCC APIs. A number of improvements on CC functionality have been made and are reflected in these APIs. For this it was necessary to break the inheritance that previously existed between GCC and MPCC.

The joint CC group has furthermore decided that the MPCC is to be considered as the future base CC family and the technical work will not be continued on GCC. Errors or technical flaws will of course be corrected.

Call Model Description

The call model used for the Call Control SCFs has the following objects.

* a call object. A call is a relation between a number of parties. The call object relates to the entire call view from the application. E.g., the entire call will be released when a release is called on the call. Note that different applications can have different views on the same physical call, e.g., one application for the originating side and another application for the terminating side. The applications will not be aware of each other, all ‘communication’ between the applications will be by means of network signalling. The API currently does not specify any feature interaction mechanisms.

* a call leg object. The leg object represents a logical association between a call and an address. The relationship includes at least the signalling relation with the party. The relation with the address is only made when the leg is routed. Before that the leg object is IDLE and not yet associated with the address.

* an address. The address logically represents a party in the call.

* a terminal. A terminal is the end-point of the signalling and/or media for a party. This object type is currently not addressed.

The call object is used to establish a relation between a number of parties by creating a leg for each party within the call.

Associated with the signalling relationship represented by the call leg, there may also be a bearer connection (e.g., in the traditional voice only networks) or a number (zero or more) of media channels (in multi-media networks).

A leg can be attached to the call or detached from the call. When the leg is attached, this means that media or bearer channels related to the legs are connected to the media or bearer channels of the other legs that are attached to the same call. I.e., only legs that are attached can ‘speak’ to each other. A leg can have a number of states, depending on the signalling received from or sent to the party associated with the leg. Usually there is a limit to the number of legs that are in being routed (i.e., the connection is being established) or connected to the call (i.e., the connection is established). Also, there usually is a limit to the number of legs that can be simultaneously attached to the same call.

Some networks distinguish between controlling and passive legs. By definition the call will be released when the controlling leg is released. All other legs are called passive legs. There can be at most one controlling leg per call. However, there is currently no way the application can influence whether a Leg is controlling or not.

There are two ways for an application to get the control of a call. The application can request to be notified of calls that meet certain criteria. When a call occurs in the network that meets these criteria, the application is notified and can control the call. Some legs will already be associated with the call in this case. Another way is to create a new call from the application.

Structure of Call Control SCF Documentation

Each of the Call Control SCFs is specified under the following headings:

  • The Sequence diagrams give the reader a practical idea of how each of the SCF is implemented.
  • The Class relationships clause shows how each of the interfaces applicable to the SCF, relate to one another.
  • The Interface specification clause describes in detail each of the interfaces shown within the Class diagram part.
  • The State Transition Diagrams (STD) show transition between states in the SCF. The states and transitions are well-defined; either methods specified in the Interface specification or events occurring in the underlying networks cause state transitions.
  • The Data definitions clause shows a detailed expansion of each of the data types associated with the methods within the classes. Note that some data types are used in other methods and classes and are therefore defined within the Common Data types part of this specification (TS 29.198-2).

General requirements on support of methods

An implementation of one of the call control APIs which supports or implements a method described in one of the sub-parts of TS 29.198-04, shall support or implement the functionality described for that method, for at least one valid set of values for the parameters of that method.

Where a method is not supported by an implementation of a Service interface, the exception P_METHOD_NOT_SUPPORTED shall be returned to any call of that method.

Where a method is not supported by an implementation of an Application interface, a call to that method shall be possible, and no exception shall be returned.

Application Control of a Call or Session

Introduction

Services should be provision-able by multiple independent parties and therefore multiple applications may apply control to the same instance of a call or a session. How this may be enabled is further described in the following.

However, first some reflections on what is meant with application control:

Single application control may be classified as to allow at the same point in time during call or session processing only one application to be capable to influence the call or session. This does not exclude more applications on the same call, but they cannot operate at the same time. This is referred to as “Single point of Control (SPC)” in IN terminology.

Multiple application control may be classified as to allow at the same point in time during call or session processing more than one application to be capable to influence the call or session. This is referred to as “Multiple Points of Control (MPC) in IN terminology.
MPC will demand some rules for event handling among multiple applications on a call like the cascaded chain principle as applied in IN CS3 [8], where MPC has been introduced.

Concept of Multiple Points of Control

The term "multiple points of control" refers to the situation when multiple concurrently executing applications apply control to one and the same instance of a call or session.

General Objective:

"If there is more than one controlling application acting on the same call or session, then the event notification detection point processing requested by any of the involved applications shall be performed in the same way as if notification reporting had occurred in different call or session control instances, which are separated by a Network Node interface".

NOTE: The objective description above is taken from [8], but slightly generalized to become non-IN specific.

The MPC general objective signifies the cascaded chain principle, which is further explained below through an informative cascaded chain model.

Cascaded Chain Model

When services running in different nodes apply control to a call or session, even if they are unaware of each other, they provide a cascading of applications. They provide a natural ordering of applications. This ordering can be said to be upstream or downstream. A downstream ordering is the ordering of applications as they are invoked downstream in the network from the calling party (e.g. origin client, UAC) toward the called party (e.g. destination server, UAS). An upstream ordering is the ordering of applications as they are invoked upstream in the network from the called party toward the calling party.

Figure 1 : Cascaded Chain Model

When applications that apply control to one instance of a call or session are invoked in some order, on the same node, the applications can be thought of as cascaded.

When a "request" is received then the earlier the application is invoked, based on this event, the more logically upstream it is considered to be in the chain of cascaded applications. When a response is received then the earlier the applications is invoked, based on this event, the more logically downstream it is considered to be in the chain of cascaded applications.

This means that the applications are treated as if they were triggered in different nodes (or hosts). This model is conceptually simple and may provide a natural algorithm for resolving conflicts between the instructions of multiple service applications at the same call or session event.

On reception of a call or session event in the network the actions are executed in order of priority in the following manner:

  1. Control is passed to the first application.
  2. Some response is received from the first application.
  3. Control is passed to the second application.
  4. Some response is received from the second application and so on.

In this way a decision about whether to invoke a subsequent application can depend on the output from the previous application.

If the first application terminates the request then the second application must not be invoked.

The most simple form of cascading is an order based in which the applications are triggered on a single event.

If for example three application "X1" "Y1" and "Z1" need to be triggered on event "e"; then specifying an order say X1-Y1-Z1 for event e means that first "X1" is contacted and its instructions taken, then the output of this is passed to "Y1" and finally the output of "Y1" is passed to "Z1". (The letter represents the application and the number an instance of the application running for a given user.)

How about future events that should invoke the same instances of "X" "Y" and "Z"? For these events there could be a totally different order, specified say YXZ. It would however be administratively very complex if one has to specify an order for all instances for all events. Thus a general basic principle may be useful like the cascaded chain for defining a default ordering in the cases where this is not possible. The actual order depends on whether the event is coming from the calling party (downstream) or the called party (upstream).

If however a new application A1 should be triggered on "er" then it would be necessary to place this somewhere in the order. However, a default general assumption can be that event reporting to already invoked applications should have precedence over the invocation of new applications [8].

Anyhow, as a network operator’s option any MPC generalized rules specified may be replaced or enhanced by network operator specific rules.

Service Interactions

A variety of different services, service enablers, and capabilities are being standardized. There are potential feature interactions among these various services, service enablers, and capabilities.

Conflicts, incompatibilities, or modifications of one feature’s characteristics due to interactions with another active feature need to be resolved in case of multiple services.

In case there are multiple initial notification requests (filter criteria) assigned for one subscriber, a priority describe the order in which the applications shall be contacted when the call or session encounters an event that matches the initial filter criteria. Handling of service/application interaction issues to prevent undesired interactions when multi services are to be supported is outside the scope of the present document. It is the basic assumption that the network operator is responsible for the provisioning of triggers in the network as in this domain full awareness exists of all other services and applications.

Multiple services – applicability of MPC for Parlay/OSA

As far as the OSA API is concerned a user can choose his clients as he wishes, i.e. the user may subscribe to more services over the network, each one being to a separate client application, not necessary placed in the same physical entity.

From an OSA gateway side it is a network implementation issue if multiple or single point of control mechanisms are supported. Multi service support extends the number of applications that can register for notifications. An example of multi service support network could be an OSA Gateway in a UMTS IMS network or IN network complying with the multiple points of control principle as defined for IN CS3.

Overlapping criteria have been defined for GCCS and MPCCS to prevent multiple points of control, leading to possible interaction problems. Where Multi service support is provided, the overlap criteria rules as defined to secure single point of control can be overruled.