[ Home | Glossary | Acronyms | Links | Contact us ]

Cellular Networking Perspectives

David Crowe’s Wireless Review Magazine Articles

Protocols Section: March 2001 Issue

Thirsty for new features? Get a CAMEL?

CAMEL is the GSM equivalent of WIN, the Wireless Intelligent Network. Although details of the protocol are radically different, the basic concepts are very similar, as are its strengths and weaknesses. For GSM and GPRS carriers who find themselves stuck in a featureless desert, CAMEL can transport them to an oasis where new features grow like dates on palm trees.

CAMEL, like WIN, is based on intelligent network (IN). This is intended to allow switches (MSCs) to be dumber, with their lost intelligence moved to external devices. The first phases of CAMEL only supported remote call processing control through a GSM SCF (Service Control Function), which is basically an SCP. When a GSM phone registers, it will use MAP (Mobile Application Part) to register and obtain the subscriber’s profile, including the CAMEL subscription information (CSI). The most important part of this is the Trigger Detection Profile (TDP), which describes the situations that will cause CAMEL to be invoked.

Triggers define the conditions under which external call processing logic (‘service logic’) must be invoked. These are usually based on the pattern of the digits (e.g. beginning with ‘*’) or the length of the digits. For example, PBX-like dialing could be simulated by triggering on 3, 4 or 5 digit numbers. If a trigger is detected, call processing stops in the MSC, an “Initial DP” message is sent to the GSM SCF using the CAMEL Application Protocol (CAP), and when a “Connect” response is received, call processing resumes. A simple example is a PBX service could simply look up a prefix for the dialed number and replace the dialed extension by a full dialed number, allowing PBX dialing to occur anywhere.

The GSM SCF has other options besides re-routing calls. It could determine that the trigger was not really required and use the CAP “Continue” message to tell the MSC to continue processing as if the trigger had never happened. This might seem redundant, but triggers are somewhat of a blunt tool, and sometimes a more general trigger is set than is absolutely necessary. The only way to implement a CAMEL feature is to apply a general trigger and then program the SCF to pass when the information in the trigger does not indicate that the feature is to be triggered.

In other circumstances, some modifications to the call may be necessary, but not re-routing. The CAP “Continue with Argument” message can be used to apply call processing changes such as a replacement of the charge number, or to apply some announcements.

Billing Capabilities

Phase 3 of CAMEL has billing capabilities approximately equivalent to WIN Phase II. It can, for example, be used to implement a prepaid capability without the need for loop around trunks or external switching platforms. Its implementation is quite distinct from WIN Phase II, using a single message from the SCF to tell the MSC how long the call should be allowed to proceed before being disconnected. This single message (“Apply Charging”) performs the functions of multiple messages in WIN, however the capabilities are somewhat less flexible.

The SRF – Service Resource Function

The early phases of CAMEL only supported a signaling connection between an MSC and the CAMEL equipment (SCF). The dream of intelligent network fanatics is to have the ability to have voice connections to a Service Control Function (SCF, also known as an Intelligent Peripheral) containing banks of announcements, tones, interactive voice response units and voice recognition devices. WIN had this before CAMEL, but is this capability really nothing but a mirage?

A simple way to implement services requiring a voice path is to route the call to equipment under the control of the home carrier. Unfortunately for roamers, this results in long distance calls being made every time a CAMEL (or WIN) feature is implemented. CAMEL allows connections to be made to any SRF, but this creates some new problems. If the CAMEL feature involves a complex dialog with a significant amount of error handling, the local SRF serving the roamer has to have the complete list of announcements programmed ahead of time.

This requirement will result in highly simplistic, awkward to minimize the number of announcements that have to be programmed. Dialogs will also probably be very slow because of the need to coordinate the MSC, SCF and SRF through CAP and MAP messages. Dialogs will not be branded because other carriers will not want to support announcements branded by their competitors.

If remote dialogs are not really practical except within a single carrier network, then the dream of the SRF will simply not be implemented. Carriers will be forced to backhaul dialogs to their own network to provide a tolerable user experience. To be fair, this is exactly the same problem that faces WIN Phase I capabilities that rely on an IP.

The role of the HLR

The HLR plays an important role in Wireless IN services, because it has to provide the list of triggers to the Serving MSC upon registration. CAMEL also allows the HLR to be updated with information gathered from one of its services. For example, in theory, CAMEL could be used to control services that are today handled by the MSC/HLR alone. More likely, CAMEL will provide an enhanced version of some of these services.

Conclusions

CAMEL brings some important new capabilities to GSM systems. Due to the need to process triggers, it is not clear that they will actually bring the benefit of significantly offloading the MSC. However, for features that rely on access to an external database that can be housed in an SCF, they can provide important advantages. The use of the SRF is less likely to find widespread use in wide-area roaming, although it is a reasonably practical solution within a single carrier’s network where a consistent set of announcements and matching service logic can be installed in all CAMEL network elements.

CAMEL will allow for moderate customization of existing capabilities, but it is unlikely to stimulate the implementation of radically new features, because they will likely require new triggers, or new information elements in the trigger messages.

Figure 1: CAMEL Message Processing

Table 1: CAMEL Interfaces