Project

General

Profile

Osmocom Network In The Box » History » Version 129

neels, 12/14/2018 12:11 PM

1 1 neels
h1. Osmocom Network In The Box
2 126 fixeria
3
{{>toc}}
4 1 neels
5 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.
6 21 neels
7 68 neels
h1. OsmoNITB R.I.P., long live the Network In The Box
8 1 neels
9 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.
10 1 neels
11 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.
12 1 neels
13 2 neels
To migrate from OsmoNITB to the new separate programs, see the [[OsmoNITB Migration Guide]].
14
15 68 neels
h1. Part of this Complete Network
16 2 neels
17 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.
18 2 neels
19 32 neels
Here is a table of the components you need:
20 1 neels
21 32 neels
|\4. *Required for*  |/3. *Program* |/3. *Description* |
22
|\2. *2G*  |\2. *3G* |
23
| *CS* | *PS* | *CS* | *PS* |
24 92 neels
| ✔ | ✔ | ✔ | ✔ | [[Osmocom Network In The Box#OsmoHLR|OsmoHLR]] | Home Location Register, stores subscriber IMSI, phone number and auth tokens. |
25 99 neels
| ✔ | (1) | ✔ (3) | (1) | [[Osmocom Network In The Box#OsmoMSC|OsmoMSC]] | Mobile Switching Center, handles signalling, i.e. attach/detach of subscribers, call establishment, messaging (SMS and USSD). |
26 92 neels
| ✔ |   | ✔ |   | [[Osmocom Network In The Box#OsmoMGW|OsmoMGW]] | Media Gateway, is instructed by the MSC and/or the BSC to direct RTP streams for active voice calls. |
27
| ✔ | ✔ | ✔ | ✔ | [[Osmocom Network In The Box#OsmoSTP|OsmoSTP]] | Signal Transfer Point, routes SCCP messages between MSC, BSC, HNBGW and for 3G also the SGSN. |
28
| ✔ | (1) |   |   | [[Osmocom Network In The Box#OsmoBSC|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". |
29
|   |   | ✔ | ✔ | [[Osmocom Network In The Box#OsmoHNBGW|OsmoHNBGW]] | 3G HomeNodeB Gateway, receives the Iuh protocol from a 3G femto cell and forwards to MSC and SGSN by SCCP/M3UA via OsmoSTP. |
30
|   | ✔ (2) |   | ✔ (2) | [[Osmocom Network In The Box#OsmoGGSN|OsmoGGSN]] | Gateway GPRS Support Node, "opens" GTP tunnels received from SGSNs to internet uplink. |
31 99 neels
|   | ✔ |   | ✔ (3) | [[Osmocom Network In The Box#OsmoSGSN|OsmoSGSN]] | Serving GPRS Support Node, handles signalling, i.e. attach/detach of subscribers and PDP contexts. |
32 92 neels
| ✔ | (1) |   |   | [[Osmocom Network In The Box#OsmoBTS|OsmoBTS]] | for 2G networks, drives the TRX and ties to the BSC via Abis-interface. |
33
|   | ✔ |   |   | [[Osmocom Network In The Box#OsmoPCU|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. |
34 37 neels
|   |   | ✔ | ✔ | hNodeb | 3rd party 3G femto cell hardware to connect to OsmoHNBGW via Iuh |
35 5 neels
36 99 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. That is mostly due to policy by the mobile phones, theoretically they could accept a network without voice service.
37 1 neels
38 32 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.
39 99 neels
40
3: If building from source, remember to build with --enable-iu. (Our binary packages are built with --enable-iu.)
41 18 neels
42 68 neels
h2. Topology
43 55 neels
44
{{graphviz_link()
45
digraph G {
46
  rankdir = LR;
47 56 neels
  
48
  MS [label="MS\n(2G phone)"]
49
  UE [label="UE\n(3G phone)"]
50 1 neels
51 56 neels
  subgraph cluster_bts {
52
    BTS [rank="min"]
53
    PCU [rank="min"]
54
  }
55
56
  subgraph cluster_msc_mgw {
57 59 neels
    label=MGCP;style=dotted
58 56 neels
    MSC
59 57 neels
    MGW1 [label="MGW"]
60 56 neels
  }
61
62
  subgraph cluster_bsc_mgw {
63 59 neels
    label=MGCP;style=dotted
64 56 neels
    BSC
65 57 neels
    MGW2 [label="MGW"]
66 1 neels
  }
67
68 59 neels
  hNodeB [shape="box",label="hNodeB\n(3G femto cell)"]
69
70 61 neels
  MS -> BTS [label="Um"]
71 65 neels
  MS -> PCU [style="dashed"]
72 60 neels
 
73 56 neels
  BTS -> BSC [label="Abis/IP"]
74
  STP [label="STP\n(SCCP/M3UA)"]
75
  BSC -> STP -> MSC [label="A"]
76 70 neels
  MSC -> HLR [label="GSUP"]
77
  SGSN -> HLR [label="GSUP",style="dashed"]
78 62 neels
  UE -> hNodeB [label="Uu"]
79 65 neels
  UE -> hNodeB [style="dashed"]
80 56 neels
  hNodeB -> HNBGW [label="Iuh"]
81 1 neels
  HNBGW -> STP -> SGSN [label="IuPS",style="dashed"]
82 104 neels
  HNBGW -> STP -> MSC [label="IuCS"]
83 61 neels
  PCU -> SGSN [label="Gb",style="dashed"]
84 58 neels
  SGSN -> GGSN [label="GTP-C",style="dashed"]
85
  SGSN -> GGSN [label="GTP-U(2G)",style="dashed"]
86
  hNodeB -> GGSN [label="GTP-U(3G)",style="dashed"]
87
  GGSN -> internet [label="tun",style="dashed"]
88 56 neels
89 73 neels
  BTS -> MGW2 -> MGW1 [label="RTP"]
90 59 neels
  MGW1 -> MGW1 [label="RTP"]
91 1 neels
  hNodeB -> MGW1 [label="IuUP/RTP"]
92 59 neels
93
  A, B, C, D [style="invisible"]
94 63 neels
  A -> B [label="data (PS)",style="dashed"]
95 103 neels
  C -> D [label="voice/SMS/USSD (CS)"]
96 56 neels
97 55 neels
}
98
}}
99
100 5 neels
h1. Have to Know
101 10 neels
102
Each program features a detailed [[Osmocom Manuals|user manual]], your primary source of information to expand on the setup described here.
103 24 laforge
104 5 neels
Osmocom offers [[Binary_Packages|compiled packages for various distributions]]. If you're up to it, you may also [[Build from Source]].
105
106
Each Osmocom program typically has
107
108 1 neels
* a distinct configuration file;
109 25 neels
* a VTY telnet console for live interaction;
110 1 neels
* a CTRL interface for live interaction from 3rd party programs.
111 18 neels
112 102 neels
See [[Port Numbers]] to find out which program runs what services on which port.
113 18 neels
114
h1. Configuration Examples
115 5 neels
116 83 neels
Here is a tarball of the config files discussed below: attachment:nitb.tar
117
118 6 neels
h2. OsmoHLR
119
120 127 neels
[[OsmoHLR:]] is the Home Location Register: it 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. It also handles USSD services (like "*100#").
121 67 neels
122 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]].
123 6 neels
124 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.
125 1 neels
126 127 neels
This example optionally configures two USSD services and logging.
127
128 1 neels
*osmo-hlr.cfg* (download: attachment:nitb.tar)
129
<pre>
130 127 neels
hlr
131
 ussd route prefix *#100# internal own-msisdn
132
 ussd route prefix *#101# internal own-imsi
133
134
log stderr
135
 logging filter all 1
136
 logging print extended-timestamp 1
137
 logging print category 1
138
 logging print category-hex 0
139
 logging print level 1
140
 logging print file basename last
141 128 neels
 logging level set-all debug
142 48 neels
</pre>
143
144 97 neels
Once your HLR is running, you will want to add subscribers with authentication keys to the HLR database. Please refer to the OsmoHLR [[Osmocom Manuals]], section "Managing Subscribers".
145
146 6 neels
h2. OsmoMSC
147 1 neels
148 93 neels
[[OsmoMSC:]] is the Mobile Switching Center: it handles signalling, i.e. attach/detach of subscribers, call establishment, messaging (SMS and USSD). The OsmoMSC is your central "manager" of the network.
149 66 neels
150 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.
151 26 neels
152 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.
153 7 neels
154 86 neels
* There is a default point code, currently 0.23.1 (in 8.8.3 point code format, see [[Point Codes]]).
155 6 neels
* OsmoMSC will by default look for OsmoSTP on localhost's M3UA port, 2905.
156 7 neels
157 51 neels
To direct RTP streams, OsmoMSC needs an OsmoMGW instance (see OsmoMGW below).
158 38 neels
159 51 neels
You only need to set up your MCC, MNC, and how to reach/use the MGW.
160 43 neels
161 108 neels
*osmo-msc.cfg* (download: attachment:nitb.tar)
162 1 neels
<pre>
163 38 neels
network
164
 network country code 901
165 53 neels
 mobile network code 70
166
msc
167 1 neels
 mgw remote-ip 192.168.0.9
168 128 neels
 
169
log stderr
170
 logging filter all 1
171
 logging print extended-timestamp 1
172
 logging print category 1
173
 logging print category-hex 0
174
 logging print level 1 
175
 logging print file basename last
176
 logging level set-all info
177 38 neels
</pre>
178 47 neels
179 1 neels
h2. OsmoMGW
180
181 93 neels
[[OsmoMGW:]] is the Media Gateway: it 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).
182 52 neels
183 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).
184
185
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.
186
187
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.
188
189 105 neels
You may decide to use one OsmoMGW for both BSC and MSC, if your network topology allows.
190
(There used to be the need to separate the endpoint config for BSC and MSC, but now the MGW takes care of that automatically.)
191 47 neels
192 105 neels
To increase the likelihood that your first setup will work out, below examples pick distinct MGCP ports and VTY interfaces, which allows running two MGWs on the same public IP address.
193 47 neels
194
h3. OsmoMGW for OsmoMSC
195 1 neels
196 101 neels
OsmoMGW listens for MGCP connections, by default on port 2427.
197
198 1 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'.
199 9 neels
* 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:
200 1 neels
201 108 neels
*osmo-mgw-for-msc.cfg* (download: attachment:nitb.tar)
202 48 neels
<pre>
203 82 neels
mgcp
204 40 neels
 bind ip 192.168.0.9
205 82 neels
line vty
206 1 neels
 bind 127.0.0.1
207 129 neels
 
208
log stderr
209
 logging filter all 1
210
 logging print extended-timestamp 1
211
 logging print category 1
212
 logging print category-hex 0
213
 logging print level 1
214
 logging print file basename last
215
 logging level set-all info
216 1 neels
</pre>
217
218 47 neels
h3. OsmoMGW for OsmoBSC
219 1 neels
220 124 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 (endpoints are be allocated dynamically).
221 1 neels
222 124 neels
It is semantically more clear to run a separate OsmoMGW instance for the OsmoBSC. When running on the same machine, though, then each MGW obviously needs to use different UDP ports, for example:
223 1 neels
224 108 neels
*osmo-mgw-for-bsc.cfg* (download: attachment:nitb.tar)
225 1 neels
<pre>
226 40 neels
mgcp
227 82 neels
 bind ip 192.168.0.9
228 47 neels
 # default port is 2427 (is used for MSC's MGW)
229
 bind port 12427
230 41 neels
line vty
231 1 neels
 # default VTY interface is on 127.0.0.1 (used for MSC's MGW)
232 41 neels
 bind 127.0.0.2
233 40 neels
</pre>
234
235 105 neels
Note that osmo-bsc.cfg below sets the 'mgw remote-port' to the 'bind port' configured here; if they run on distinct interfaces, the default ports will do in both cases.
236 1 neels
237 9 neels
h2. OsmoSTP
238
239 93 neels
[[OsmoSTP:]] is the Signal Transfer Point: it 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.
240 9 neels
241
The basic configuration that permits dynamic routing is:
242
243 108 neels
*osmo-stp.cfg* (download: attachment:nitb.tar)
244 9 neels
<pre>
245
cs7 instance 0
246
 xua rkm routing-key-allocation dynamic-permitted
247
 listen m3ua 2905
248 11 neels
  accept-asp-connections dynamic-permitted
249
</pre>
250 1 neels
251
h2. OsmoBSC
252 11 neels
253 93 neels
[[OsmoBSC:]] is the 2G Base Station Controller: it 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.
254 67 neels
255 87 neels
OsmoBSC needs to register with OsmoSTP, and contact the MSC by its point code. If not configured otherwise, it will use OsmoMSC's default point code to contact it, see [[Point Codes]].
256 11 neels
257 48 neels
OsmoBSC needs to contact an OsmoMGW to direct RTP streams between BTS and the MSC's MGW, as discussed above under "OsmoMGW".
258 42 neels
259 11 neels
OsmoBSC also needs complete configuration of all connected BTS. This example shows configuration for a sysmoBTS.
260 15 neels
261
Furthermore, some network properties need to be set.
262 1 neels
263 83 neels
The 'gprs mode' determines whether packet switched access will be enabled. 'gprs mode none' switches off data services, it tells osmo-bts not to contact osmo-pcu to establish data service.
264 15 neels
265 83 neels
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 voice-and-data service based on Osmocom style dynamic timeslots:
266 15 neels
267 108 neels
*osmo-bsc.cfg* for voice and data service (download: attachment:nitb.tar)
268 48 neels
<pre>
269 75 neels
network
270
 network country code 901
271 1 neels
 mobile network code 70
272 75 neels
 bts 0
273
  type sysmobts
274
  band GSM-1800
275
  location_area_code 23
276
  ip.access unit_id 1800 0
277
  gprs mode gprs
278 82 neels
  gprs nsvc 0 remote ip 192.168.0.9
279 75 neels
  gprs nsvc 0 remote udp port 23000
280
  gprs nsvc 0 local udp port 23000
281
  gprs nsvc 0 nsvci 1800
282
  gprs nsei 1800
283
  gprs cell bvci 1800
284
  trx 0
285
   rf_locked 0
286
   arfcn 868
287
   nominal power 23
288
   timeslot 0
289
    phys_chan_config CCCH+SDCCH4
290
   timeslot 1
291
    phys_chan_config SDCCH8
292
   timeslot 2
293
    phys_chan_config TCH/F_TCH/H_PDCH
294
   timeslot 3
295 1 neels
    phys_chan_config TCH/F_TCH/H_PDCH
296 75 neels
   timeslot 4
297
    phys_chan_config TCH/F_TCH/H_PDCH
298
   timeslot 5
299
    phys_chan_config TCH/F_TCH/H_PDCH
300
   timeslot 6
301
    phys_chan_config TCH/F_TCH/H_PDCH
302
   timeslot 7
303
    phys_chan_config PDCH
304
e1_input
305 1 neels
 e1_line 0 driver ipa
306 75 neels
msc 0
307 82 neels
 mgw remote-ip 192.168.0.9
308 75 neels
 mgw remote-port 12427
309 1 neels
 allow-emergency deny
310
 codec-list hr3
311
</pre>
312
313
h2. OsmoHNBGW
314
315 93 neels
[[OsmoHNBGW:]] is the 3G HomeNodeB Gateway, found in the osmo-iuh.git repository: it receives the Iuh protocol from a 3G femto cell, separates it into IuCS and IuPS and forwards to the MSC and SGSN.
316 1 neels
317 89 neels
OsmoHNBGW needs to connect to OsmoSTP for routing, and needs to know the MSC and SGSN point codes. If omitted, it assumes OsmoSTP on 127.0.0.1 and uses the point codes that are default in OsmoMSC and OsmoSGSN, see [[Point Codes]].
318 1 neels
319
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.
320
321 108 neels
*osmo-hnbgw.cfg* (download: attachment:nitb.tar)
322 1 neels
<pre>
323 82 neels
hnbgw
324
 iuh
325
  local-ip 192.168.0.9
326 98 neels
  hnbap-allow-tmsi 1
327 82 neels
</pre>
328
329 96 neels
*NOTE:* To connect your femto cell to the HNBGW, see for example [[Configuring_the_ipaccess_nano3G]]
330
331 95 neels
*NOTE:* this minimal config is not yet possible in the "latest" packages, only in the nightly packages (20170-12-29, http://git.osmocom.org/osmo-iuh/commit/?id=2af648f443257284d994ea6d79d9554ed866dfa6 )
332 1 neels
333 98 neels
*NOTE:* The 'hnbap-allow-tmsi' option is just a workaround for the nano3G passing a TMSI as UE-Register identity, which would normally have to be an IMSI.
334 95 neels
335 1 neels
h2. OsmoGGSN
336
337 93 neels
[[OpenGGSN:|OsmoGGSN]] is the Gateway GPRS Support Node: it "opens" GTP tunnels received from SGSNs to internet uplink. To provide packet switched service, OsmoGGSN must offer GTP service to the OsmoSGSN.
338 1 neels
339 82 neels
Notably, both OsmoGGSN and OsmoSGSN must use identical port numbers, which is an intrinsic requirement of the GTP protocol. Hence they must not run on the same IP address. Furthermore, for 2G networks, the SGSN must be reachable by the PCU and thus needs to be on a public interface if the BTS is a separate box; for 3G networks, the GGSN must be reachable by the hNodeB and thus needs to be on a public interface. So, to cover both, you need to have *two* public interfaces; this example uses 192.168.0.42, made available by
340 12 neels
341 82 neels
<pre>
342
sudo ip addr add 192.168.0.42/32 dev eth0
343
</pre>
344
345
This is of course blatantly ignoring the local DHCP server's authority, just a quick hack.
346
347 1 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.
348 13 neels
349 82 neels
It also needs access to a tun device with an address range available to subscribers' PDP contexts. 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 'apn0' device has been created ahead of time, with:
350 13 neels
351 82 neels
<pre>
352
sudo ip tuntap add dev apn0 mode tun user $USER group $USER
353
sudo ip addr add 192.168.42.0/24 dev apn0
354
sudo ip link set apn0 up
355
</pre>
356
357
IPv4 operation is enabled by default, but for future compatibility, it is good to indicate that explicitly.
358
359 76 neels
OsmoGGSN furthermore indicates DNS servers, as well as an IPv4 address range to assign to subscribers' PDP contexts.
360 13 neels
361 85 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. With the @default-apn@ command, any unknown APN name will use that default APN instead, but still you usually have to define _some_ APN on your phone so that it even tries to connect to the data service.
362 13 neels
363 85 neels
A profound part of GGSN configuration is the network setup of your system: you need to allow the packets to be routed between the subscribers and your internet uplink. See the [[Osmocom Manuals|OsmoGGSN User Manual]], section _Running OsmoGGSN_ / _Routing_.
364 84 neels
365 108 neels
*osmo-ggsn.cfg* (download: attachment:nitb.tar)
366 125 neels
NOTE: this configuration requires the _apn0_ tun device to be configured and up, as well as IP-forwarding and masquerading to be enabled -- please see the manual as indicated above.
367 13 neels
<pre>
368
ggsn ggsn0
369 82 neels
 gtp bind-ip 192.168.0.42
370 76 neels
 apn internet
371 82 neels
  tun-device apn0
372 1 neels
  type-support v4
373
  ip dns 0 192.168.0.1
374 76 neels
  ip dns 1 8.8.8.8
375
  ip prefix dynamic 192.168.42.0/24
376 82 neels
  no shutdown
377
 default-apn internet
378 14 neels
 no shutdown ggsn
379
</pre>
380 67 neels
381
h2. OsmoSGSN
382 14 neels
383 93 neels
[[OsmoSGSN:]] is the Serving GPRS Support Node: it handles signalling, i.e. attach/detach of subscribers and PDP contexts for data services.
384 14 neels
385
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.
386
387
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).
388
389 88 neels
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.
390
391
For 3G IuPS, the SGSN must sign up at OsmoSTP with a point code that the HNBGW knows. If not configured explicitly, the respective defaults are used, see [[Point Codes]].
392 14 neels
393 1 neels
Finally, OsmoSGSN needs access to OsmoHLR to access subscriber data. Set 'auth-policy remote' to use the HLR for subscriber authorization. The default 
394
395 108 neels
*osmo-sgsn.cfg* (download: attachment:nitb.tar)
396 14 neels
<pre>
397 77 neels
sgsn
398 82 neels
 gtp local-ip 192.168.0.9
399
 ggsn 0 remote-ip 192.168.0.42
400 79 neels
 ggsn 0 gtp-version 1
401 14 neels
 auth-policy remote
402 1 neels
 gsup remote-ip 127.0.0.1
403
ns
404
 encapsulation udp local-ip 192.168.0.9
405
 encapsulation udp local-port 23000
406
 encapsulation framerelay-gre enabled 0
407
</pre>
408
409
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.
410 93 neels
411
h1. OsmoBTS
412
413
[[OsmoBTS:]] operates 2G radio hardware. OsmoBTS supports various hardware platforms including sysmoBTS and USRP. Instead, you may choose BTS vendors like ip.access or Siemens, which can also directly operate with OsmoBSC without OsmoBTS being involved.
414
415
The BTS needs to know where to reach OsmoBSC's Abis interface, and its unit id needs to match one of the BTS unit ids configured at OsmoBSC.
416
417
An example configuration for a sysmoBTS is:
418
419
<pre>
420
phy 0
421
 instance 0
422
bts 0
423
 band 1800
424
 ipa unit-id 1800 0
425
 oml remote-ip 192.168.0.9
426
 trx 0
427
  phy 0 instance 0
428
</pre>
429
430
h1. OsmoPCU
431
432
[[OsmoPCU:]] operates the packet-switched part of 2G radio hardware. Timeslots used for data transmission are controlled by the PCU instead of the BTS. OsmoPCU is typically configured from the @gprs@ config items in OsmoBSC, which is communicated to the PCU via OML and OsmoBTS (via the PCU socket). An example configuration for OsmoPCU would be:
433
434
<pre>
435
pcu
436
 flow-control-interval 10
437
 cs 2
438
 alloc-algorithm dynamic
439
 alpha 0
440
 gamma 0
441
 two-phase-access
442
</pre>
443 17 neels
444
h1. Running Examples
445
446 122 laforge
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@.
447 17 neels
448 122 laforge
When installed from debian or opkg feeds, you will find the systemd service files in @/lib/systemd/system/@.
449 17 neels
450
Re/starting and stopping then works like this:
451
452
<pre>
453 1 neels
systemctl restart osmo-hlr
454
systemctl stop osmo-hlr
455
</pre>
456 36 neels
457
It can be useful to have an @osmo-all@ script to re/start or stop all components at once, edit to pick yours:
458
459
*osmo-all* script
460
<pre>
461
#!/bin/sh
462
cmd="${1:-start}"
463
set -ex
464
systemctl $cmd osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw osmo-bts-sysmo osmo-pcu 
465
</pre>
466
467
which allows
468
469
<pre>
470 1 neels
./osmo-all restart
471
./osmo-all status
472 36 neels
./osmo-all stop
473
</pre>
474
475 1 neels
For illustration, the manual command invocations for the components would look like this:
476
477
<pre>
478
osmo-hlr -l hlr.db -c osmo-hlr.cfg
479
osmo-msc -c osmo-msc.cfg
480
osmo-mgw -c osmo-mgw-for-msc.cfg
481
osmo-mgw -c osmo-mgw-for-bsc.cfg
482 48 neels
osmo-ggsn -c osmo-ggsn.cfg
483
osmo-sgsn -c osmo-sgsn.cfg
484 36 neels
osmo-stp -c osmo-stp.cfg
485 1 neels
osmo-bsc -c osmo-bsc.cfg
486
osmo-hnbgw -c osmo-hnbgw.cfg
487
# on a 2G sysmoBTS:
488 36 neels
osmo-bts-sysmo -c osmo-bts.cfg -s -M
489
osmo-pcu -c osmo-pcu.cfg
490
</pre>
491 18 neels
492
h1. Logging Examples
493
494
Osmocom programs have a common logging mechanism, configurable by the config files as well as the telnet VTY.
495
496 82 neels
h2. System Logging
497
498 18 neels
Depending on the system's logging configuration, logs may by default be visible in /var/log/daemon.log, or by using journalctl:
499
500 1 neels
<pre>
501
journalctl -f -u osmo-hlr
502
</pre>
503
504
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.
505
506 82 neels
h2. telnet VTY logging
507
508 1 neels
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:
509
510
<pre>
511
$ telnet localhost 4254
512
OsmoMSC> logging enable 
513
OsmoMSC> logging level ?
514
  all      Global setting for all subsystems
515
  rll      A-bis Radio Link Layer (RLL)
516 18 neels
  cc       Layer3 Call Control (CC)
517
  mm       Layer3 Mobility Management (MM)
518
  [...]
519 35 neels
OsmoMSC> logging level all ?
520 19 neels
everything debug      info       notice     error      fatal      
521
OsmoMSC> logging level all debug 
522
OsmoMSC> logging filter all 1
523 1 neels
</pre>
524
525
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.
526
527
h2. stderr logging
528
529
A common configuration you can add to any of the above configuration files to show *all* logging on stderr is:
530
531
<pre>
532
log stderr
533
 logging filter all 1
534
 logging color 1
535
 logging print category 1
536
 logging timestamp 1
537
 logging print extended-timestamp 1
538
 logging level all debug
539
</pre>
540
541
The @filter all 1@ switches on logging, read "do not discard all logging". The amount of logging seen is determined by @logging level ...@ commands, here all categories are set to level @debug@, to show absolutely all logging. You will probably want to refine that.
542 90 neels
543
h1. Point Codes
544
545
If you'd like to configure non-default point-codes, see this example for OsmoHNBGW on the general approach:
546
547
<pre>
548
cs7 instance 0
549
 # HNBGW's local point code
550
 point-code 0.23.5
551
 # Address book entries, used below
552
 sccp-address my_msc
553
  point-code 0.23.1
554
 sccp-address my_sgsn
555
  point-code 0.23.4
556
hnbgw
557
 iucs
558
  remote-addr my_msc
559
 iups
560
  remote-addr my_sgsn
561
</pre>
562 76 neels
563
h1. Troubleshooting
564
565
h2. APN for Data Service
566
567
For the data service to work, phones generally need an APN added to their
568
configuration, or they will not even attempt to establish a data connection.
569
The APN should match the name configured in osmo-ggsn.conf.
570
571
The APN configuration steps are usually similar to:
572
573
* Navigate to APN settings:
574
** 'Settings'
575
** 'Wireless & Networks'
576
** 'Mobile networks'
577
** 'Access Point Names'
578
* You should see the list of APNs (possibly empty)
579
* Press the Menu button
580
* Choose 'New APN'
581
* Enter values for 'Name' as well as 'APN'
582
* Again press the Menu button
583
* Choose 'Save'
584
* The APN should now appear in the list of APNs.
585 1 neels
* Possibly tap the bullet icon to select the APN as default.
586 116 duo_kali
.
587 117 duo_kali
588 110 duo_kali
</pre>
Add picture from clipboard (Maximum size: 48.8 MB)