Ybts module


The module implements a BTS.


The examples below will use the following UE data:
IMSI: 001900000000001
TMSI: 00000001
IMEI: 123456789012345

Location Updating / IMSI Detach

UE Location Updating is done using the user.register message.
UE IMSI Detach (unregister) is done using the user.unregister message.
Both messagess will have the following parameters:

A module handling the user.register message may return UE MSISDN in the msisdn parameter.

Voice calls

The module can handle MT/MO voice calls.
Only one call is allowed for an UE. E.g. once a call is started (MO or MT) any subsequent call setup will be denied.

Routing MT Calls

MT calls can be routed to ybts module using its prefix (ybts/) followed by MSISDN, IMSI, TMSI or IMEI.
If MSISDN is used it must be prefixed by a ‘+’ character.

Javascript example:

var m = new Message(“call.execute”);
m.callto = “ybts/+100”;
m.callto = “ybts/IMSI001900000000001”;
m.callto = “ybts/TMSI00000001”;
m.callto = “ybts/IMEI123456789012345”;

Regexroute example:


Routing MO Calls

When handling a call setup request from UE the module will fill the following parameters in call.preroute message:



The module handles MT SMS delivered in msg.execute message.
The target can be specified in callto parameter in the same way as for MT voice calls.
The message may contain a maxpdd parameter with allowed interval (in milliseconds) for the SMS to start. E.g. this is the interval to wait for UE to respond to paging request if paging needs to be done.

There are 2 ways to specify SMS content:
1. The message may contain an rpdu parameter which is a hexified buffer with the SMS packet content.
2. The message may contain a text parameter with SMS plain text data. This will be used to build a GSM 7 bit encoded SMS deliver to be sent to UE.

The message handler will wait in a loop for the SMS to be delivered.
It will return true on success, false on failure. Failure means the module failed to deliver the SMS (e.g. timeout) or the UE returned error.


The module will route MO SMS. The call.route message have the following parameters:

If route succeeds the module will dispatch a msg.execute message.


NOTE: The module don’t implement any USSD encoding. It needs another module to implement handlers for map.encode and map.decode messages.


MT USSD is started when handling ussd.execute messages.
Here are expected message parameters:

For operation_type=ussr the module will dispatch a map.encode message with the following xml:

  <component localCID=”0″ type=”Invoke” operationCode=”unstructuredSS-Request”>
    <ussd-Text encoding=”gsm7bit” lang=”unspecified”>Some text</ussd-Text>

A module handling the message must return encoded data in data parameter.
YBTS will start an USSD session with the UE if encode succeeds.
The module will set a peerid (with YBTS session id) parameter in the ussd.execute message on return.


The module will start a MO USSD when receiving a SS register from UE containing an USSD request.
After succesfully decoding received data (using a map.decode with data parameter) message the module will dispatch a call.route message with the following parameters:

Here is an example of expected result from map.decode:

   <component remoteCID=”1″ type=”Invoke” operationCode=”processUnstructuredSS-Request” operationClass=”reportAll”>
     <ussd-Text encoding=”GSM7Bit” lang=”unspecified”>*8773#</ussd-Text>

If call.route succeeds the module will dispatch an ussd.execute using returned target.
The USSD session will be started if ussd.execute succeeds.
The module will remember peer’s id from ussd.execute message.

Subsequent messages

There are 2 messages used for session management:

Both messages must have the following parameters:

USSD content parameters (operation_type and text) MUST be present when updating a session and MAY be present when terminating one.

Related topics