
Now we will consider the aspects of implementing the IN-protocol of the CAMEL mobile network and how the fixed-mobile FMC convergence service operates on its basis. It is useful for those who are pragmatically interested in telephony in the office or more theoretically - the work of some aspects of mobile communication in principle.
What does it mean?
- Simple numbers: you no longer need to memorize or write down long DEF numbers. Any employee can call, knowing his very short office number.
- With FMC, you can simply dial the number and immediately connects to the desired fixed phone, without dialing any additional on the PBX. Connection time is reduced by about a minute.
- You can create individual rules for incoming and outgoing communication: for example, no more “extra” calls during off-hours.
Let's start with aspects of the implementation of the IN-protocol of the mobile network CAMEL.
')
How it works?
If we recall the basics of building a GSM network, then in principle its structure can be represented as follows.

- BTS (Base Transceiver Station) - base station. Its functions include the formation of a radio signal, encryption, installation and maintenance of the signal at the physical level.
- BSC (Base Station Controller) - base station controller. This node is responsible for managing a group of base stations, adjusting the signal level and conducting a handover (transferring a call from one base station to another in talk mode).
- MSC (Mobile Switching Center) is a mobile switching center. Its function includes directly connecting a call between two (or more) subscribers. In practice, this site is often combined with VLR (Visitor Location Register) - a guest location register, a database responsible for storing all user information about subscribers registered in the coverage area of ​​the switch.
- HLR (Home Location Register) - home (reference) location register. A distributed database that stores all information about subscribers of the cellular operator: their services, settings and current status.
- AuC - (Authentication Center) - the authentication center responsible for authenticating the subscriber when he is registered with the network.
If we consider their interaction in terms of signaling, then the interaction of the elements was initially built on the basis of the SS7 signaling protocol (General Channel Signaling No. 7).

Then, in the light of the development of IP networks, this protocol was modified and turned into SigTRAN (Signaling Transport, a transport signaling protocol based on TCP \ IP networks)
In more detail, the structure of the GSM network and the signaling of the OKS7 can be found here in
this and
this post (special thanks for a couple of pictures taken from the authors).
We now turn directly to the specifics of the implementation of INAP / CAMEL intellectual services protocols.
INAP (Intellectual Network Application Part, Intellectual Network Application Protocol) - the protocol of the company Ericsson, which came to the mobile networks of fixed,
CAMEL (Customized Applications for Mobile Enhanced Logic) - a protocol developed exclusively for mobile networks, expanding their functionality. The specifications (first of all, 3GPP TS 23.078), at the moment, describes 4 versions of this protocol.
If we touch on the technical side of the implementation, in simplified form, it looks like this:

When connecting to a subscriber in the billing of any CAMEL services,
O-CSI (Originating CAMEL Subscription Information, information on CAMEL subscriptions for outgoing calls) and / or
T-CSI (Terminating CAMEL Subscription Information, information on CAMEL subscriptions for incoming calls) subscriptions that are responsible for the logic of processing outgoing and incoming calls, respectively. The subscription parameters specify the address of the gsmSCF platform containing the logic for further call processing, the service key is a unique identifier for each of the existing CAMEL services, and Default call handling (the default call processing script) is the action to be performed with the call in case bypass alarms. The value can be adjusted depending on the functionality and logic of the service. For example, if it is necessary that in case of a CAMEL platform hangup or overload, the call still passes, then the value of this parameter should be set to “Continue”. And if you need to stop the processing of this call - "Release".
A classic example is disabling charging for prepaid subscribers in cases of overload. In this case, the Default call handling is set to “Continue”, i.e. connection is established without CDR formation (Call Data Records) in billing.
This feature was successfully enjoyed by students of a Rostov university who came from a banana republic of Central Africa. At the moment when the bypass was triggered (they were determined by constant balance requests - when the pre-billing falls, requests * 102 # begin to return an error), students started calling home, relatives and acquaintances. And since the phenomenon of falling billing is a rare event (the new year, March 8, and a couple of similar holidays), they tried to talk with the stock.
CSE - CAMEL service environment (CAMEL Service Platform). IN-platform, which keeps all the logic of services.
SSF - Service Switching Function (Service function on the switching component). This functionality is activated on the switches and its main task is to “trigger” calls in all cases of mobile subscriber activity. Simply put, if the switch "sees" that the caller has an O-CSI subscription, it initiates a call to the IN platform.
SCF - Service Control Function. Functionality on the side of the IN platform, which deals with processing the request, responding to it, and correctly completing the conversations between nodes.
When an incoming call arrives at the CAMEL subscriber, the network initiates a sequence of actions called
Two step HLR interrogation (two-step implementation on the HLR). Schematically, it is shown in the picture below.

The MSC receives an incoming call.
First of all, the MSC sends a MAP (Mobile Application Part) -query
Send Routing Info request (routing information request) to the HLR side. The response message should provide information about the current status of the subscriber (on, off, in talk mode, etc.), which the HLR, in turn, requests from the MSC / VLR with a
Provide Subscriber Info message (provision of user information), and also information on available T-CSI subscriptions.
After that, at the CAP protocol level (CAMEL Application Part, the application part of the CAMEL protocol), the session is initiated in the direction of the IN platform. Below is one of the possible scenarios of such a dialogue between the MSC and the IN platform.

The message
UDT BEGIN initialDP (DP - Detection Points, Initiation of Definition Points) describes the process of the initial request in the direction of the IN-platform. The input parameters are used called (called) (2) and calling (calling) (3) numbers, as well as information from the T-CSI subscription: global title (address) of the platform and service key (1). In addition, the type of dialogue is indicated - incoming connection (4).
--- INITIAL DP ---
--- SERV KEY ---
SERV KEY : 51 (1)
--- CALLED NO ---
--- CALLED NO ---
NOA : .0000011 = National (significant) number (national use)
INN IND : 1....... = Routing to internal network number not allowed
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
ADDRESS : 903041 (2)
--- CALLING NO ---
--- CALLING NO ---
NOA : .0000011 = National (significant) number (national use)
NI : 0....... = Complete
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
PRESENT IN : ....00.. = Presentation allowed
SCREENING : ......11 = Network provided
ADDRESS : 906361 (3)
--- CLG PTY C ---
--- CLG PTY C ---
CATEGORY : 10 = Ordinary Calling Subscriber
--- LOC NO ---
--- LOC NO ---
NOA : 04h = International number
INN IND : 0....... = Routing to internal network number allowed
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
PRESENT IN : ....00.. = Presentation allowed
SCREENING : ......11 = Network provided
ADDRESS : 7962ZZZZZZZ
--- BEARER CAP ---
--- BEARER CAP ---
--- BEARER CAP ---
CODING STD : .00..... = CCITT standardized coding
INFO TC : ...00000 = Speech
TRANS MODE : .00..... = Circuit mode
INFO TR : ...10000 = 64 kbit/s
LAYER ID : .01.....
USRINFO L1 : ...00011 = Recommendation G.711 A-law
--- E TYP BCSM ---
E TYP BCSM : 12 = termAttemptAuthorized (4)
The message
UDT CONTINUE requestReportBCSMEvent connect (BCSM - Basic Call State Model, basic call setup model) describes all possible events that can occur when trying to establish a voice connection: the subscriber is busy, unavailable, not responding. These are the “Detection points” that were initiated by the previous message. At the very end, the Connect message indicates the number to which the call should be placed. This can be either the DEF number of the subscriber directly or various technological numbers used to implement additional functionality. At the same stage, if the subscriber has restrictions on incoming communication, call processing will be interrupted with cause = ReleaseCall.
--- OPERATION ---
OPERATION : 23 = requestReportBCSMEvent
--- RQ RP BCSM ---
--- BCSM EVTS ---
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 17 = tDisconnect
--- MONIT MODE ---
MONIT MODE : 0 = interrupted
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 15 = tAnswer
--- MONIT MODE ---
MONIT MODE : 1 = notifyAndContinue
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 13 = tBusy
--- MONIT MODE ---
MONIT MODE : 0 = interrupted
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 14 = tNoAnswer
--- MONIT MODE ---
MONIT MODE : 0 = interrupted
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- DP SP CRIT ---
--- APP TIMER ---
APP TIMER : 60
--- INVOKE ---
--- INVOKE ID ---
INVOKE ID : 1
=== CAP ===
--- INVOKE ---
--- OPERATION ---
OPERATION : 20 = connect
--- CONNECT ---
--- DST RT ADR ---
--- CALLED NO ---
--- CALLED NO ---
NOA : .0000010 = Unknown (national use)
INN IND : 0....... = Routing to internal network number allowed
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
ADDRESS : 9031234567
The following message
UDT CONTINUE eventReportBCSM indicates which of the events described, in the end, came
=== CAP ===
--- INVOKE ---
--- OPERATION ---
OPERATION : 24 = eventReportBCSM
--- EV RP BCSM ---
--- E TYP BCSM ---
E TYP BCSM : 13 = tBusy
--- ESI BCSM ---
--- T BSY ---
--- BUSY CAUSE ---
--- CAUSE ---
CODING STD : .00..... = CCITT standardized coding
LOCATION : ....0000 = User
CAUSE VAL : .0010001 = User busy
--- REC SIDEID ---
--- REC SIDEID ---
LEG TYPE : 02h = leg2
--- MISC C INF ---
--- MSG TYPE ---
MSG TYPE : 0 = request
After the
requestReportBCSMEvent connect received the number to which the call must be connected in the
UDT CONTINUE message , the Second Interrogation is initiated (the second call to the HLR), and then the call is sent to the MSC / VLR to allocate an MSRN (Mobile Station Roaming Number, temporary number used exclusively for connecting the call to the incoming switch). Then the number in the reply message is returned to the MSC and a call is initiated at the ISUP protocol level.
Call scenarios
If we consider the functionality of CAMEL directly in terms of FMC services, the call scenarios can be divided into 3 main categories:
1. Calls from mobile phone to mobile phone.

This scenario cannot be fully attributed to a convergent service, but, nevertheless, I propose to consider it. The caller dials a pre-known short number corresponding to the B-subscriber. During the processing on the CAMEL platform, it is converted to a full DEF number, to which the call is connected.
2. Calls from a mobile phone to a fixed phone.

In this scenario, the mobile subscriber also dials a short number, and, during the analysis, it becomes clear that this is a number from a fixed network. In this case, a unique prefix is ​​inserted at the beginning of the number, according to which routing to the MSC-PBX interface is registered. On the final MSC, the prefix is ​​cut off and the number that was dialed initially comes to the PBX directly. And then, already inside the fixed network, the call is routed to the desired office phone.
A feature of these scenarios is that mobile numbers can be assigned short numbers that will be similar in structure to office numbers.
Life example: an employee has an office phone with the number 5577 and a mobile phone with the number 15577. You can call him either by the first number (the office telephone will ring) and by the second number (the mobile will ring).
It is also worth adding that a fixed connection can be organized both as a classic TDM connection and through SIP / RTP.
3. Calls from a fixed phone to a mobile phone.

In this scenario, the call comes from the PBX in the direction of the mobile switch, which initiates the session to the CAMEL platform and in the response message returns the DEF number of the called mobile subscriber.
Benefits of charging
- Short calls between mobiles are made at the price of a call within a closed group.
- Calls from mobile to fixed are made at the price of a call within a closed group.
- Calls from intranet roaming are made at the price of a call within a closed group.
Additional savings can be received by the client, who have their own distributed telephone network and are ready to organize several joints with switches on the Beeline network.
