Thirst Quencher

CAMEL will take GSM and GPRS carriers to an oasis where they can slake their thirst for new services.

CAMEL is the GSM equivalent of WIN. 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 a place where new features grow like dates on palm trees.

CAMEL is based on IN. This is intended to allow 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 service-control function (SCF), which is basically an SCP. When a GSM phone registers, it will use 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 usually are 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 that a PBX service simply could 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 never had 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 Service Resource Function

The early CAMEL phases only supported a signaling connection between an MSC and the CAMEL equipment (SCF, also known as an intelligent peripheral). The dream of IN fanatics is to have the ability to have voice connections to an SCF 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 service resource function (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 features that are awkward for consumers to use because of the need to minimize the number of announcements that have to be programmed. Dialogs also probably will be very slow because of the need to coordinate the MSC, SCF and SRF through CAP and MAP messages. They will not be branded either, because other carriers will not want to support announcements branded by competitors.

If remote dialogs are not really practical except within a single carrier network, then the dream of the SRF simply will not be implemented. Carriers will be forced to backhaul dialogs to their own networks 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 HLR Role

The HLR plays an important role in WIN 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 today are handled by the MSC/HLR alone. More likely, CAMEL will provide an enhanced version of some of these services.

CAMEL brings some important new capabilities to GSM systems. Due to the need to process triggers, it is not clear that they actually will 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 likely will require new triggers or new information elements in the trigger messages.

---

Crowe (crowed@cnp-wireless.com) is a wireless-standards consultant and editor of Cellular Networking Perspectives, a wireless-standards and -technology bulletin.