1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
[[smpp]]
== Short Message Peer to Peer (SMPP)
The _Short Message Peer to Peer (SMPP) Protocol_ <<smpp-34>> has been
used for the communication with SMSCs. OsmoNITB implements version 3.4
of the protocol. Using this interface one can send MT-SMS to an attached
subscriber or receive unrouted MO-SMS.
SMPP describes a situation where multiple ESMEs (External SMS Entities)
interact with a SMSC (SMS Service Center) via the SMPP protocol. Each
entity is identified by its System Id. The System ID is a character
string which is configured by the system administrator.
OsmoNITB implements the SMSC side of SMPP and subsequently acts as a TCP
server accepting incoming connections from ESME client programs.
Each ESME identifies itself to the SMSC with its system-id and an
optional shared password.
=== Global SMPP configuration
There is a `smpp` vty node at the top level of the OsmoNITB
configuration. Under this node, the global SMPP configuration is
performed.
Use the `local-tcp-ip` command to define the TCP IP and port at which the
OsmoNITB internal SMSC should listen for incoming SMPP connections. The
default behaviour is to listen on all IPs (0.0.0.0), and the default port
assigned to SMPP is 2775.
Use the `system-id` command to define the System ID of the SMSC.
Use the `policy` parameter to define whether only explicitly configured
ESMEs are permitted to access the SMSC (`closed`), or whether any
ESME should be accepted (`accept-all`).
Use the `smpp-first` command to define if SMPP routes have higher
precedence than MSISDNs contained in the HLR (`smpp-first`), or if
only MSISDNs found not in the HLR should be considered for routing to
SMPP (`no smpp-first`).
=== ESME configuration
Under the `smpp` vty node, you can add any number of `esme` nodes, one
for each ESME that you wish to configure.
Use the `esme NAME` command (where NAME corresponds to the system-id of
the ESME to be configured) under the SMPP vty node to enter the
configuration node for this given ESME.
Use the `password` command to specify the password (if any) for the
ESME.
Use the `default-route` command to indicate that any MO-SMS without a
more specific route should be routed to this ESME.
Use the `deliver-src-imsi` command to indicate that the SMPP DELIVER
messages for MO SMS and the SMPP ALERT should state the IMSI (rather
than the MSISDN) as source address.
Use the `osmocom-extensions` command to request that Osmocom specific
extension TLVs shall be included in the SMPP PDUs. Those extensions
include the ARFCN of the cell, the L1 transmit power of the MS, the
timing advance, the uplink and dwnlink RxLev and RxQual, as well as the
IMEI of the terminal at the time of generating the SMPP DELIVER PDU.
Use the `dcs-transparent` command to transparently pass the DCS value
from the SMS Layer3 protocols to SMPP, instead of converting them to the
SMPP-specific values.
Use the `route prefix` command to specify a route towards this ESME.
Using routes, you specify which destination MSISDNs should be routed
towards your ESME.
=== Example configuration snippet
The following example configuration snippet shows a single ESME
'galactica' with a prefix-route of all national numbers stating with
2342:
----
smpp
local-tcp-port 2775
policy closed
no smpp-first
esme galactica
password SoSayWeAll
deliver-src-imsi
osmocom-extensions
route prefix national isdn 2342
----
=== Osmocom SMPP protocol extensions
Osmocom has implemented some extensions to the SMPP v3.4 protocol.
These extensions can be enabled using the `osmocom-extensions` VTY
command at `esme` level.
The TLV definitions can be found in the
`<osmocom/gsm/protocol/smpp34_osmocom.h>` header file provided by
libosmocore.
==== RF channel measuremets
When the Osmocom SMPP extensions are enabled, we add the following
TLVs to each SMPP DELIVER PDU:
[options="header", cols="3,1,1,5"]
|===
| TLV | IEI | Length (Octets) | Purpose
| TLVID_osmo_arfcn | 0x2300 | 2 | GSM ARFCN of the radio interface
| TLVID_osmo_ta | 0x2301 | 1 | Timing Advance on the radio interface
| TLVID_osmo_ms_l1_txpwr | 0x2307 | 1 | Transmit Power of the MS in uplink direction
| TLVID_osmo_rxlev_ul | 0x2302 | 2 | Uplink receive level as measured by BTS in dBm (int16_t)
| TLVID_osmo_rxqual_ul | 0x2303 | 1 | Uplink RxQual value as measured by BTS
| TLVID_osmo_rxlev_dl | 0x2304 | 2 | Downlink receive level as measured by MS in dBm (int16_t)
| TLVID_osmo_rxqual_dl | 0x2305 | 1 | Downlink RxQual value as measured by MS
|===
All of the above values reflect the *last measurement report* as
recieved vi A-bis RSL from the BTS. It is thus a snapshot value (of
the average within one 480ms SACCH period), and not an average over
all the SACCH periods during which the channel was open or the SMS was
received. Not all measurement reports contain all the values. So you
might not get an TLVID_osmo_rxlev_dl IE, as that particular uplink
frame might habe benn lost for the given snapshot we report.
==== Equipment IMEI
If we know the IMEI of the subscribers phone, we add the following TLV
to each SMPP DELIVER PDU:
[options="header", cols="3,1,1,5"]
|===
| TLV | IEI | Length | Purpose
| TLVID_osmo_imei | 0x2306 | variable | IMEI of the subscibers phone (ME)
|===
|
