Project

General

Profile

Osmocom Network In The Box » History » Version 80

neels, 11/22/2017 09:20 PM

1 23 neels
{{>toc}}
2
3 29 neels
h1. WIP
4
5 31 neels
*This wiki page is still new and in an alpha state. We're still checking whether it is consistent and contains all the important information.*
6 77 neels
(status: 2G voice and data is verified to work; 3G pending)
7 29 neels
8 1 neels
h1. Osmocom Network In The Box
9
10 22 neels
This is a brief guide to the most basic and minimal setup of an Osmocom 2G and/or 3G network for voice and data services. It is a good starting point for newcomers to familiarize with the software, and to expand upon by the [[Osmocom Manuals]] and other wiki pages.
11 21 neels
12 68 neels
h1. OsmoNITB R.I.P., long live the Network In The Box
13 1 neels
14 2 neels
Historically, Osmocom offered the [[OsmoNITB:]] "Network-In-The-Box" as an actual single program. It was a useful simplification at the time, but in 2017, Osmocom have decided to split OsmoNITB into programs more closely resembling traditional network architecture. It is recommended to use the new separate components instead of the OsmoNITB, since active development focus has moved there.
15 1 neels
16 4 neels
It is still very much possible to run a complete Osmocom core network in one "box". For example, a sysmoBTS can run the entire core network on the same hardware that drives the TRX, making it a complete network in actually one single box. At the same time, having separate components also allows scaling to large deployments, with properly distributed load and a central subscriber database.
17 1 neels
18 2 neels
To migrate from OsmoNITB to the new separate programs, see the [[OsmoNITB Migration Guide]].
19
20 68 neels
h1. Part of this Complete Network
21 2 neels
22 32 neels
Assuming that you have your radio hardware ready (a BTS, a femto cell or an SDR driven by osmo-trx), the core network consists of separate programs providing voice/SMS/USSD ("circuit-switched" or CS) and data ("packet-switched" or PS) services.
23 2 neels
24 32 neels
Here is a table of the components you need:
25 1 neels
26 32 neels
|\4. *Required for*  |/3. *Program* |/3. *Description* |
27
|\2. *2G*  |\2. *3G* |
28
| *CS* | *PS* | *CS* | *PS* |
29
| ✔ | ✔ | ✔ | ✔ | [[OsmoHLR:]] | Home Location Register, stores subscriber IMSI, phone number and auth tokens. |
30
| ✔ | (1) | ✔ | (1) | [[OsmoMSC:]] | Mobile Switching Center, handles signalling, i.e. attach/detach of subscribers, call establishment, messaging (SMS and USSD). |
31
| ✔ |   | ✔ |   | [[OsmoMGW:]] | Media Gateway, is instructed by the MSC and/or the BSC to direct RTP streams for active voice calls. |
32
| ✔ | ✔ | ✔ | ✔ | [[OsmoSTP:]] | Signal Transfer Point, routes SCCP messages between MSC, BSC, HNBGW and for 3G also the SGSN. |
33
| ✔ | (1) |   |   | [[OsmoBSC:]] | 2G Base Station Controller, manages logical channels and other lower level aspects for one or more 2G BTS; it is technically part of the BSS and not the "core network". |
34
|   |   | ✔ | ✔ | [[OsmoHNBGW:]] | 3G HomeNodeB Gateway, receives the Iuh protocol from a 3G femto cell and forwards to MSC and SGSN by SCCP/M3UA via OsmoSTP. |
35
|   | ✔ (2) |   | ✔ (2) | [[OpenGGSN:|OsmoGGSN]] | Gateway GPRS Support Node, "opens" GTP tunnels received from SGSNs to internet uplink. |
36
|   | ✔ |   | ✔ | [[OsmoSGSN:]] | Serving GPRS Support Node, handles signalling, i.e. attach/detach of subscribers and PDP contexts. |
37
| ✔ | (1) |   |   | [[OsmoBTS:]] | for 2G networks, drives the TRX and ties to the BSC via Abis-interface. |
38
|   | ✔ |   |   | [[OsmoPCU:]] | for 2G networks, a component closely tied to the BTS, drives the TRX for PS timeslots and ties to the SGSN via Gb-interface. |
39 37 neels
|   |   | ✔ | ✔ | hNodeb | 3rd party 3G femto cell hardware to connect to OsmoHNBGW via Iuh |
40 5 neels
41 32 neels
1: PS is always an _addition_ to CS: even though these components do not handle PS requests, you need to have these to be able to setup and register with a network, which is a prerequisite for data services.
42 28 neels
43 74 neels
2: For the GGSN to successfully route packets to an internet uplink, it needs a tun device set up and usually IP masquerading/forwarding enabled. Please refer to the OsmoGGSN manual for more details.
44 18 neels
45 68 neels
h2. Topology
46 55 neels
47
{{graphviz_link()
48
digraph G {
49
  rankdir = LR;
50 56 neels
  
51
  MS [label="MS\n(2G phone)"]
52
  UE [label="UE\n(3G phone)"]
53 1 neels
54 56 neels
  subgraph cluster_bts {
55
    BTS [rank="min"]
56
    PCU [rank="min"]
57
  }
58
59
  subgraph cluster_msc_mgw {
60 59 neels
    label=MGCP;style=dotted
61 56 neels
    MSC
62 57 neels
    MGW1 [label="MGW"]
63 56 neels
  }
64
65
  subgraph cluster_bsc_mgw {
66 59 neels
    label=MGCP;style=dotted
67 56 neels
    BSC
68 57 neels
    MGW2 [label="MGW"]
69 1 neels
  }
70
71 59 neels
  hNodeB [shape="box",label="hNodeB\n(3G femto cell)"]
72
73 61 neels
  MS -> BTS [label="Um"]
74 65 neels
  MS -> PCU [style="dashed"]
75 60 neels
 
76 56 neels
  BTS -> BSC [label="Abis/IP"]
77
  STP [label="STP\n(SCCP/M3UA)"]
78
  BSC -> STP -> MSC [label="A"]
79 70 neels
  MSC -> HLR [label="GSUP"]
80
  SGSN -> HLR [label="GSUP",style="dashed"]
81 62 neels
  UE -> hNodeB [label="Uu"]
82 65 neels
  UE -> hNodeB [style="dashed"]
83 56 neels
  hNodeB -> HNBGW [label="Iuh"]
84
  HNBGW -> STP -> MSC [label="IuCS"]
85 58 neels
  HNBGW -> STP -> SGSN [label="IuPS",style="dashed"]
86 61 neels
  PCU -> SGSN [label="Gb",style="dashed"]
87 58 neels
  SGSN -> GGSN [label="GTP-C",style="dashed"]
88
  SGSN -> GGSN [label="GTP-U(2G)",style="dashed"]
89
  hNodeB -> GGSN [label="GTP-U(3G)",style="dashed"]
90
  GGSN -> internet [label="tun",style="dashed"]
91 56 neels
92 73 neels
  BTS -> MGW2 -> MGW1 [label="RTP"]
93 59 neels
  MGW1 -> MGW1 [label="RTP"]
94 1 neels
  hNodeB -> MGW1 [label="IuUP/RTP"]
95 59 neels
96
  A, B, C, D [style="invisible"]
97 63 neels
  A -> B [label="data (PS)",style="dashed"]
98
  C -> D [label="voice (CS)"]
99 56 neels
100 55 neels
}
101
}}
102
103 5 neels
h1. Have to Know
104 10 neels
105
Each program features a detailed [[Osmocom Manuals|user manual]], your primary source of information to expand on the setup described here.
106 24 laforge
107 5 neels
Osmocom offers [[Binary_Packages|compiled packages for various distributions]]. If you're up to it, you may also [[Build from Source]].
108
109
Each Osmocom program typically has
110
111 1 neels
* a distinct configuration file;
112 25 neels
* a VTY telnet console for live interaction;
113 1 neels
* a CTRL interface for live interaction from 3rd party programs.
114 18 neels
115
See [[Port Numbers]] to find out which program runs VTY on which port.
116
117
h1. Configuration Examples
118 5 neels
119 6 neels
h2. OsmoHLR
120
121 67 neels
Home Location Register, stores subscriber IMSI, phone number and auth tokens. This is where you configure who is allowed on your network and who has which phone number.
122
123 72 neels
osmo-hlr will automatically bootstrap an empty subscriber database. See the [[Osmocom Manuals|manual]] on how to add one or more subscribers -- if you don't know your IMSI, it can be useful to attempt a connection and watch the OsmoHLR log for a rejected IMSI. To migrate subscribers from an older OsmoNITB database, see the [[OsmoNITB migration guide]].
124 6 neels
125 50 neels
While you do need one, your configuration file may actually remain empty. This will serve GSUP on localhost (127.0.0.1), sufficient for a Network In The Box with MSC and SGSN on the same machine as the HLR.
126 6 neels
127 48 neels
*osmo-hlr.cfg*
128
<pre>
129 71 neels
# empty, the defaults are sufficient
130 48 neels
</pre>
131
132 6 neels
h2. OsmoMSC
133 1 neels
134 67 neels
Mobile Switching Center, handles signalling, i.e. attach/detach of subscribers, call establishment, messaging (SMS and USSD). The OsmoMSC is your central "manager" of the network.
135 66 neels
136 6 neels
The VLR component of OsmoMSC needs to connect to the OsmoHLR's GSUP server to know which subscribers are authorized. By default, it will connect to OsmoHLR on localhost, no explicit config needed.
137 26 neels
138 6 neels
To be reachable by OsmoBSC and OsmoHNBGW, OsmoMSC needs an SCCP point code, and it needs to connect to OsmoSTP to make itself known to SCCP routing.
139 7 neels
140 6 neels
* There is a default point code, currently 0.23.1 (in 8.8.3 point code format).
141
* OsmoMSC will by default look for OsmoSTP on localhost's M3UA port, 2905.
142 7 neels
143 51 neels
To direct RTP streams, OsmoMSC needs an OsmoMGW instance (see OsmoMGW below).
144 38 neels
145 51 neels
You only need to set up your MCC, MNC, and how to reach/use the MGW.
146 43 neels
147 49 neels
*osmo-msc.cfg*
148 38 neels
<pre>
149
network
150 53 neels
 network country code 901
151
 mobile network code 70
152 43 neels
msc
153 48 neels
 mgw remote-ip 192.168.0.5
154 45 neels
 mgw endpoint-range 1 32
155 38 neels
</pre>
156 47 neels
157 1 neels
h2. OsmoMGW
158
159 67 neels
Media Gateway, is instructed by the MSC and/or the BSC to direct RTP streams for active voice calls. The Media Gateway receives instructions in the form of MGCP messages from OsmoMSC/OsmoBSC. It forwards RTP streams directly between BTS, femto cells and remote endpoints, e.g. other MGW instances, and its job is to transcode between codecs (future).
160 52 neels
161 47 neels
You need an OsmoMGW to serve OsmoMSC's MGCP requests, and an OsmoMGW to serve OsmoBSC's MGCP requests. In fact, these two can be served by one single OsmoMGW instance. If you would like to keep two separate OsmoMGW instances, you need to take care that they don't attempt to bind to identical ports on the same IP address (for MGCP, but also for VTY and CTRL interfaces).
162
163
Consider that you have a 2G network with an external BTS (say a sysmoBTS), which means that you need your OsmoBSC's MGW instance to be reachable on a public interface. So far the MSC's MGW can be on a local loopback interface, it only needs to be reachable by the BSC's MGW and by the MSC.
164
165
If you also have a 3G femto cell, then the MSC's MGW instance also needs to be on a public interface. At this point you either need two public interface addresses, or you need to put one of the MGWs on a different MGCP port.
166
167
If you use one OsmoMGW for both BSC and MSC, there are no port conflicts, but you need to take care that MSC and BSC use differing endpoint identifiers, or they will interfere with each others' RTP stream configurations.
168
169
To increase the likelihood that your first setup will work out, below examples pick distinct endpoint ranges so that MSC and BSC could use the same MGW instance, while at the same time provide config files that allow running two MGWs on the same public IP address.
170
171
h3. OsmoMGW for OsmoMSC
172 1 neels
173 9 neels
*NOTE: Currently, OsmoMSC still requires the legacy osmo-bsc_mgcp program, which will move to the new osmo-mgw soon. osmo-bsc_mgcp is still available from osmo-mgw.git. For osmo-bsc_mgcp, you can use the identical config as shown for the MSC's MGW here.*
174 47 neels
175 9 neels
* In a setup that truly runs in one box (e.g. sysmoBTS or osmo-trx with co-located core network), this may be localhost (127.0.0.1), which is the default, and your config file may omit the 'bind ip'.
176
* With a separate BTS and/or RNC (e.g. 3G femto cell or nanoBTS), make sure to configure an IP address that is reachable by the hNodeB and BTS:
177 1 neels
178 48 neels
*osmo-mgw-for-msc.cfg*
179 1 neels
<pre>
180 40 neels
mgcp
181 47 neels
 bind ip 192.168.0.5
182
 number endpoints 64
183 1 neels
</pre>
184
185 47 neels
h3. OsmoMGW for OsmoBSC
186 1 neels
187 47 neels
OsmoBSC also requires an OsmoMGW instance to run alongside it. In a setup where OsmoBSC and OsmoMGW run on the same box, they may in fact share the same OsmoMGW instance, as long as BSC and MSC use different endpoint identifiers.
188 1 neels
189 47 neels
It is semantically more clear to run a separate OsmoMGW instance for the OsmoBSC, which then needs to not interfere with the other MGW's ports, for example:
190 1 neels
191
*osmo-mgw-for-bsc.cfg*
192 41 neels
<pre>
193 40 neels
mgcp
194 47 neels
 bind ip 192.168.0.5
195
 # default port, used for MSC's MGW, is 2427
196
 bind port 12427
197
 number endpoints 64
198 41 neels
line vty
199 47 neels
 # default VTY interface, used for MSC's MGW, is 127.0.0.1
200 41 neels
 bind 127.0.0.2
201 40 neels
</pre>
202
203 9 neels
Note that osmo-bsc.cfg below sets the 'mgw remote-port' to the 'bind port' configured here (the method to run two MGW on the same public IP address), and picks a different 'mgw endpoint' range than the OsmoMSC (the method to use the same MGW for both BSC and MSC) -- these are two separate, redundant measures, and you usually would pick only one of them.
204 1 neels
205 9 neels
h2. OsmoSTP
206
207 67 neels
Signal Transfer Point, acts as a server for routing SCCP messages. OsmoMSC, OsmoBSC, OsmoHNBGW and OsmoSGSN contact OsmoSTP and announce their own point code, after which they may instruct OsmoSTP to route SCCP messages to each other by these point codes.
208 9 neels
209
The basic configuration that permits dynamic routing is:
210
211
*osmo-stp.cfg*
212
<pre>
213
cs7 instance 0
214
 xua rkm routing-key-allocation dynamic-permitted
215
 listen m3ua 2905
216 11 neels
  accept-asp-connections dynamic-permitted
217
</pre>
218 1 neels
219
h2. OsmoBSC
220 11 neels
221 67 neels
2G Base Station Controller, manages logical channels and other lower level aspects for one or more 2G BTS. The BSC tells the MSC what the phones would like to do, and in turn the MSC tells the BSC to establish channels, page phones, and take care of the lower level BTS maintenance.
222
223 1 neels
OsmoBSC needs to register with OsmoSTP, and contact the MSC by its point code.
224 11 neels
225 48 neels
OsmoBSC needs to contact an OsmoMGW to direct RTP streams between BTS and the MSC's MGW, as discussed above under "OsmoMGW".
226 42 neels
227 11 neels
OsmoBSC also needs complete configuration of all connected BTS. This example shows configuration for a sysmoBTS.
228 15 neels
229
Furthermore, some network properties need to be set.
230
231 11 neels
The 'gprs mode' determines whether packet switched access will be enabled. 'gprs mode none' switches off data services, as osmo-bts will not contact osmo-pcu to establish data service. This is a configuration without packet switched service:
232 1 neels
233
*osmo-bsc.cfg* for voice only
234
<pre>
235
network
236 48 neels
 network country code 901
237
 mobile network code 70
238 43 neels
 mm info 1
239 11 neels
 short name OsmoBSC
240
 long name OsmoBSC
241
 bts 0
242
  type sysmobts
243
  band GSM-1800
244 1 neels
  location_area_code 23
245 11 neels
  ip.access unit_id 1800 0
246
  trx 0
247
   rf_locked 0
248
   arfcn 868
249
   nominal power 23
250 48 neels
   max_power_red 20
251 11 neels
   timeslot 0
252
    phys_chan_config CCCH+SDCCH4
253
   timeslot 1
254
    phys_chan_config SDCCH8
255
   timeslot 2
256
    phys_chan_config TCH/H
257
   timeslot 3
258
    phys_chan_config TCH/H
259
   timeslot 4
260
    phys_chan_config TCH/H
261 1 neels
   timeslot 5
262
    phys_chan_config TCH/H
263
   timeslot 6
264
    phys_chan_config TCH/H
265
   timeslot 7
266
    phys_chan_config TCH/H
267 48 neels
e1_input
268
 e1_line 0 driver ipa
269 15 neels
msc 0
270 48 neels
 mgw remote-ip 192.168.0.5
271
 mgw remote-port 12427
272
 mgw endpoint-range 33 64
273
 allow-emergency deny
274
 codec-list hr3
275 15 neels
</pre>
276
277
To allow data service, set a 'gprs mode gprs' or 'gprs mode egprs', and configure PDCH timeslots. Traditionally, a fixed amount of TCH timeslots for voice and PDCH timeslots for data service are configured. OsmoBTS also supports two types of dynamic timeslots, as described in the "Abis manual":http://ftp.osmocom.org/docs/latest/osmobts-abis.pdf, chapter "Dynamic Channel Combinations". The following is a configuration with data service based on Osmocom style dynamic timeslots:
278
279
280 43 neels
*osmo-bsc.cfg* for voice and data service
281 48 neels
<pre>
282 75 neels
network
283
 network country code 901
284
 mobile network code 70
285
 mm info 1
286
 short name OsmoBSC
287
 long name OsmoBSC
288
 bts 0
289
  type sysmobts
290
  band GSM-1800
291
  location_area_code 23
292
  ip.access unit_id 1800 0
293
  gprs mode gprs
294
  gprs nsvc 0 remote ip 192.168.0.5
295
  gprs nsvc 0 remote udp port 23000
296
  gprs nsvc 0 local udp port 23000
297
  gprs nsvc 0 nsvci 1800
298
  gprs nsei 1800
299
  gprs cell bvci 1800
300
  no force-combined-si
301
  trx 0
302
   rf_locked 0
303
   arfcn 868
304
   nominal power 23
305
   timeslot 0
306
    phys_chan_config CCCH+SDCCH4
307
   timeslot 1
308
    phys_chan_config SDCCH8
309
   timeslot 2
310
    phys_chan_config TCH/F_TCH/H_PDCH
311
   timeslot 3
312
    phys_chan_config TCH/F_TCH/H_PDCH
313
   timeslot 4
314
    phys_chan_config TCH/F_TCH/H_PDCH
315
   timeslot 5
316
    phys_chan_config TCH/F_TCH/H_PDCH
317
   timeslot 6
318
    phys_chan_config TCH/F_TCH/H_PDCH
319
   timeslot 7
320
    phys_chan_config PDCH
321
e1_input
322
 e1_line 0 driver ipa
323
msc 0
324
 mgw remote-ip 192.168.0.5
325
 mgw remote-port 12427
326
 mgw endpoint-range 33 64
327
 allow-emergency deny
328
 codec-list hr3
329 1 neels
</pre>
330 12 neels
331 1 neels
h2. OsmoHNBGW
332
333 67 neels
3G HomeNodeB Gateway, receives the Iuh protocol from a 3G femto cell, separates it into IuCS and IuPS and forwards to the MSC and SGSN.
334 16 neels
335
OsmoHNBGW needs to connect to OsmoSTP for routing, and needs to know the MSC and SGSN point codes.
336 12 neels
337
It must also be reachable by the hNodeB, hence its Iuh must typically run on a public IP, not a loopback address like 127.0.0.1.
338
339
*osmo-hnbgw.cfg*
340
<pre>
341
cs7 instance 0
342
 ! OsmoHNBGW's own local point code
343
 point-code 0.3.0
344
 ! Address book entries, used below
345
 sccp-address msc
346
  point-code 0.23.1
347
 sccp-address sgsn
348
  point-code 0.23.2
349
hnbgw
350
 iuh
351 48 neels
  local-ip 192.168.0.5
352 12 neels
 iucs
353
  remote-addr msc
354 13 neels
 iups
355 1 neels
  remote-addr sgsn
356 13 neels
</pre>
357 1 neels
358
h2. OsmoGGSN
359 13 neels
360 67 neels
Gateway GPRS Support Node, "opens" GTP tunnels received from SGSNs to internet uplink. To provide packet switched service, OsmoGGSN must offer GTP service to the OsmoSGSN.
361 13 neels
362 67 neels
Notably, both OsmoGGSN and OsmoSGSN must use identical port numbers, which an intrinsic requirement of the GTP protocol. Hence they must not run on the same IP address. It is sufficient to, for example, run OsmoGGSN on 127.0.0.2, and OsmoSGSN's GTP on 127.0.0.1.
363
364 13 neels
OsmoGGSN maintains a gsn_restart counter, to be able to reliably communicate to the SGSN that it has restarted. This is kept in the 'state-dir', by default in /tmp.
365
366
It also needs access to a tun device. This may be configured ahead of time, so that OsmoGGSN does not need root privileges. If run with 'sudo', OsmoGGSN may also create its own tun device. In below example, the 'tun4' device has been created ahead of time. IPv4 operation is enabled by default, but for future compatibility, it is good to indicate that explicitly.
367 1 neels
368 14 neels
OsmoGGSN furthermore indicates DNS servers, as well as an IPv4 address range to assign to subscribers' PDP contexts.
369 13 neels
370 77 neels
Note that the APN named in this config file (here "internet") needs to be configured on your phone, see [[Osmocom Network In The Box#APN-for-Data-Service|APN for Data Service]] below.
371 76 neels
372 13 neels
*osmo-ggsn.cfg*
373 78 neels
NOTE: this configuration requires running osmo-ggsn with root privileges, as well as IP-forwarding and masquerading to be enabled
374 13 neels
<pre>
375
ggsn ggsn0
376
 gtp bind-ip 127.0.0.2
377
 apn internet
378
  tun-device tun4
379 1 neels
  type-support v4
380 76 neels
  ip dns 0 192.168.0.1
381 1 neels
  ip dns 1 8.8.8.8
382 76 neels
  ip ifconfig 192.168.42.0/24
383
  ip prefix dynamic 192.168.42.0/24
384
 no shutdown ggsn
385 14 neels
</pre>
386
387 67 neels
h2. OsmoSGSN
388
389 14 neels
Serving GPRS Support Node, handles signalling, i.e. attach/detach of subscribers and PDP contexts for data services.
390
391
OsmoSGSN needs to reach the GGSN to establish GTP tunnels for subscribers. It must have a separate GTP IP address from OsmoGGSN, as mentioned before.
392
393
For 2G, OsmoSGSN needs to be reachable by the PCU, and needs a public IP for the Gb interface if it is not running directly on the BTS hardware (e.g. on sysmoBTS or when using osmo-trx). For 2G operation, SGSN and GGSN may both use a local IP address for GTP, as long as they differ (e.g. 127.0.0.1 and 127.0.0.2).
394
395
For 3G, OsmoSGSN needs to be reachable by both the HNBGW for IuPS as well as by the hNodeB for GTP, i.e. it definitely needs to have a public IP address for the GTP port. IuPS may remain local if both HNBGW and SGSN are on the same box.
396
397
Finally, OsmoSGSN needs access to OsmoHLR to access subscriber data. Set 'auth-policy remote' to use the HLR for subscriber authorization. The default 
398 1 neels
399
*osmo-sgsn.cfg*
400
<pre>
401 14 neels
sgsn
402 77 neels
 gtp local-ip 192.168.0.5
403
 ggsn 0 remote-ip 127.0.0.2
404
 ggsn 0 gtp-version 1
405 79 neels
 auth-policy remote
406 14 neels
 gsup remote-ip 127.0.0.1
407 77 neels
ns
408
 encapsulation udp local-ip 192.168.0.5
409
 encapsulation udp local-port 23000
410 1 neels
 encapsulation framerelay-gre enabled 0
411
</pre>
412 80 neels
413
The @auth-policy remote@ requires that you have the SIM cards' authentication tokens in your OsmoHLR database. Instead, you can use @auth-policy accept-all@, but be aware that this will only work for 2G -- 3G networks *require* successful authentication, and @auth-policy remote@ is your *only* option for a 3G SGSN.
414 18 neels
415 17 neels
h1. Running Examples
416
417
Each Osmocom program comes with a systemd service file. It is recommended to place config files in /etc/osmocom/ and launch the individual components using systemd.
418
419
When installed from debian or opkg feeds, you will find the systemd service files in /lib/systemd/system/.
420
421
Re/starting and stopping then works like this:
422
423
<pre>
424
systemctl restart osmo-hlr
425 1 neels
systemctl stop osmo-hlr
426
</pre>
427
428 36 neels
It can be useful to have an @osmo-all@ script to re/start or stop all components at once, edit to pick yours:
429
430
*osmo-all* script
431
<pre>
432
#!/bin/sh
433
cmd="${1:-start}"
434
set -ex
435
systemctl $cmd osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw osmo-bts-sysmo osmo-pcu 
436
</pre>
437
438
which allows
439
440
<pre>
441
./osmo-all restart
442
./osmo-all status
443
./osmo-all stop
444
</pre>
445 1 neels
446
For illustration, the manual command invocations for the components would look like this:
447
448
<pre>
449
osmo-hlr -l hlr.db -c osmo-hlr.cfg
450 48 neels
osmo-msc -c osmo-msc.cfg
451
osmo-mgw -c osmo-mgw-for-msc.cfg
452 36 neels
osmo-mgw -c osmo-mgw-for-bsc.cfg
453 1 neels
osmo-ggsn -c osmo-ggsn.cfg
454
osmo-sgsn -c osmo-sgsn.cfg
455
osmo-stp -c osmo-stp.cfg
456 36 neels
osmo-bsc -c osmo-bsc.cfg
457
osmo-hnbgw -c osmo-hnbgw.cfg
458
# on a 2G sysmoBTS:
459 18 neels
osmo-bts-sysmo -c osmo-bts.cfg -s -M
460
osmo-pcu -c osmo-pcu.cfg
461
</pre>
462
463
h1. Logging Examples
464
465
Osmocom programs have a common logging mechanism, configurable by the config files as well as the telnet VTY.
466
467
Depending on the system's logging configuration, logs may by default be visible in /var/log/daemon.log, or by using journalctl:
468
469
<pre>
470
journalctl -f -u osmo-hlr
471 35 neels
</pre>
472 19 neels
473
When journalctl is used, it may be necessary to enable it first, e.g. by setting "Storage=volatile" in /etc/systemd/journald.conf followed by a 'systemctl restart systemd-journald'; you may also need to 'systemctl unmask systemd-journald.service systemd-jounald.socket'. Logging will only start appearing for components that were restarted after these changes.
474
475
A sure way to see the logs is to connect to the program's telnet VTY and enable logging on the VTY session -- this way you do not modify the application's default logging, but create a separate logging target for your telnet VTY session:
476
477
<pre>
478
$ telnet localhost 4254
479
OsmoMSC> logging enable 
480
OsmoMSC> logging level ?
481
  all      Global setting for all subsystems
482
  rll      A-bis Radio Link Layer (RLL)
483 35 neels
  cc       Layer3 Call Control (CC)
484
  mm       Layer3 Mobility Management (MM)
485 19 neels
  [...]
486 35 neels
OsmoMSC> logging level all ?
487 19 neels
everything debug      info       notice     error      fatal      
488 20 neels
OsmoMSC> logging level all debug 
489
OsmoMSC> logging filter all 1
490 1 neels
</pre>
491
492
You will see logging output on your telnet console immediately. Note that the VTY prompt is still listening, so you may at any time issue 'logging filter all 0' to switch off logging, and be able to type commands without being cluttered by ongoing log output.
493 76 neels
494
h1. Troubleshooting
495
496
h2. APN for Data Service
497
498
For the data service to work, phones generally need an APN added to their
499
configuration, or they will not even attempt to establish a data connection.
500
The APN should match the name configured in osmo-ggsn.conf.
501
502
The APN configuration steps are usually similar to:
503
504
* Navigate to APN settings:
505
** 'Settings'
506
** 'Wireless & Networks'
507
** 'Mobile networks'
508
** 'Access Point Names'
509
* You should see the list of APNs (possibly empty)
510
* Press the Menu button
511
* Choose 'New APN'
512
* Enter values for 'Name' as well as 'APN'
513
* Again press the Menu button
514
* Choose 'Save'
515
* The APN should now appear in the list of APNs.
516
* Possibly tap the bullet icon to select the APN as default.
Add picture from clipboard (Maximum size: 48.8 MB)