Harald Welte | 9f1331b | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 1 | == Configuring OsmoSGSN |
| 2 | |
| 3 | Contrary to other network elements (like OsmoBSC, OsmoNITB), the |
| 4 | OsmoSGSN has a relatively simple configuration. |
| 5 | |
| 6 | On the one hand, this is primary because the PCU configuration happens |
| 7 | from the BSC side. |
| 8 | |
| 9 | On the other hand, it is because the Gb interface does not need an |
| 10 | explicit configuration of all each PCU connecting to the SGSN. The |
| 11 | administrator only has to ensure that the NS and BSSGP layer identities |
| 12 | (NSEI, NSVCI, BVCI) are unique for each PCU connecting to the SGSN. |
| 13 | |
| 14 | === Configuring the Gp interface |
| 15 | |
| 16 | The Gp interface is the GTP-C and GTP-U based interface between the SGSN |
| 17 | and the GGSNs. It is implemented via UDP on well-known source and |
| 18 | destination ports. |
| 19 | |
| 20 | When a MS requests establishment of a PDP context, it specifies the APN |
| 21 | (Access Point Name) to which the context shall be established. This APN |
| 22 | determines which GGSN shall be used, and that in turn determines which |
| 23 | external IP network the MS will be connected to. |
| 24 | |
| 25 | There are two modes in which GGSNs can be configured: |
| 26 | |
| 27 | . static GGSN/APN configuration |
| 28 | . dynamic GGSN/APN configuration |
| 29 | |
| 30 | ==== Static GGSN/APN configuration |
| 31 | |
| 32 | In this mode, there is a static list of GGSNs and APNs configured in |
| 33 | OsmoSGSN via the VTY / config file. |
| 34 | |
| 35 | This is a non-standard method outside of the 3GPP specifications for the |
| 36 | SGSN, and is typically only used in private/small GPRS networks without |
| 37 | any access to a GRX. |
| 38 | |
| 39 | .Example: Static GGSN/APN configuration (single catch-all GGSN) |
| 40 | ---- |
| 41 | OsmoSGSN(config-sgsn)# gtp local-ip 172.0.0.1 <1> |
| 42 | OsmoSGSN(config-sgsn)# ggsn 0 remote-ip 127.0.0.2 <2> |
| 43 | OsmoSGSN(config-sgsn)# ggsn 0 gtp-version 1 <3> |
| 44 | OsmoSGSN(config-sgsn)# apn * ggsn 0 <4> |
| 45 | ---- |
| 46 | <1> Configure the local IP address at the SGSN used for Gp/GTP |
| 47 | <2> Specify the remote IP address of the GGSN (for GGSN 0) |
| 48 | <3> Specify the GTP protocol version used for GGSN 0 |
| 49 | <4> Route all APN names to GGSN 0 |
| 50 | |
| 51 | |
| 52 | ==== Dynamic GGSN/APN configuration |
| 53 | |
| 54 | In this mode, the SGSN will use a DNS-based method to perform the lookup |
| 55 | from the APN (as specified by the MS) towards the GGSN IP address. |
| 56 | |
| 57 | This is the official method as per the 3GPP specifications for the SGSN, |
| 58 | and what is used on GRX. |
| 59 | |
| 60 | .Example: Dynamic GGSN/APN configuration |
| 61 | ---- |
| 62 | OsmoSGSN(config-sgsn)# gtp local-ip 192.168.0.11 <1> |
| 63 | OsmoSGSN(config-sgsn)# ggsn dynamic <2> |
| 64 | OsmoSGSN(config-sgsn)# grx-dns-add 1.2.3.4 <3> |
| 65 | ---- |
| 66 | <1> Configure the local IP address at the SGSN used for Gp/GTP |
| 67 | <2> Enable the dynamic GGSN resolving mode |
| 68 | <3> Specify the IP address of a DNS server for APN resolution |
| 69 | |
ikostov | aa6629f | 2017-01-06 14:34:45 +0100 | [diff] [blame] | 70 | [[auth-pol]] |
| 71 | === Authorization Policy |
| 72 | |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 73 | The authorization policy controls by which rules a subscriber is accepted or |
| 74 | rejected. The possible options range from accepting just all subscribers without |
| 75 | further checking, to a fine grained access-control, handled by an external HLR. |
ikostov | aa6629f | 2017-01-06 14:34:45 +0100 | [diff] [blame] | 76 | |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 77 | accept-all:: All subscribers that attempt to attach to the GPRS network are |
| 78 | accepted without further checking. This option is intended to be used for |
| 79 | testing in a controlled environment only. A wide-open network may attract |
| 80 | subscribers from foreign networks and disrupt their service. It is highly |
| 81 | recommended to pick one of the options below. |
ikostov | aa6629f | 2017-01-06 14:34:45 +0100 | [diff] [blame] | 82 | |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 83 | remote:: This option allows to connect OsmoSGSN to an external HLR via the |
| 84 | GSUP protocol. This will be the preferred option in larger networks. |
ikostov | aa6629f | 2017-01-06 14:34:45 +0100 | [diff] [blame] | 85 | |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 86 | acl-only:: If no external HLR is available, the network operator has the |
| 87 | option to control the access using an access control list. The access control |
| 88 | list contains the IMSI numbers of the allowed subscribers. This method offers |
| 89 | fine grained access control and is ideal for small networks and lab test |
| 90 | environments. |
ikostov | aa6629f | 2017-01-06 14:34:45 +0100 | [diff] [blame] | 91 | |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 92 | closed:: This policy mode softens the strict *acl-only* only mode by also |
| 93 | implicitly accepting home network subscribers. The decision is made by the MCC |
| 94 | and MNC part of the IMSI number. The combination of MCC and MNC fully identifies |
| 95 | a subscribers home network, also known as a Home Network Identity (HNI, i.e. |
| 96 | MCC and MNC found at the start of the IMSI, e.g. MCC 901 and MNC 700 with |
| 97 | IMSI 901700000003080). |
ikostov | aa6629f | 2017-01-06 14:34:45 +0100 | [diff] [blame] | 98 | |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 99 | NOTE: The policy mode *closed* must not be confused with the equally named |
| 100 | policy that is defined for osmo-nitb! |
| 101 | |
ikostov | aa6629f | 2017-01-06 14:34:45 +0100 | [diff] [blame] | 102 | |
| 103 | .Example: Assign or change authorization policy: |
| 104 | ---- |
| 105 | OsmoSGSN> enable |
| 106 | OsmoSGSN# configure terminal |
| 107 | OsmoSGSN(config)# sgsn |
| 108 | OsmoSGSN(config-sgsn)# auth-policy acl-only <1> |
| 109 | OsmoSGSN(config-sgsn)# write <2> |
| 110 | Configuration saved to sgsn.cfg |
| 111 | OsmoSGSN(config-sgsn)# end |
| 112 | OsmoSGSN# disable |
| 113 | OsmoSGSN> |
| 114 | ---- |
| 115 | <1> 'acl-only' is selected as authorization policy |
| 116 | <2> Saves current changes to cofiguration to make this policy |
| 117 | persistent |
Harald Welte | 9f1331b | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 118 | |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 119 | .Example: Access control list: |
| 120 | ---- |
| 121 | sgsn |
| 122 | auth-policy acl-only <1> |
| 123 | imsi-acl add 001010000000003 |
| 124 | imsi-acl add 001010000000002 |
| 125 | imsi-acl add 001010000000001 |
| 126 | imsi-acl add 901700000000068 <2> |
| 127 | ---- |
| 128 | <1> Set the authorization policy |
| 129 | <2> Add as many subscribers as required |
| 130 | |
Harald Welte | 9f1331b | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 131 | === Subscriber Configuration |
| 132 | |
| 133 | As opposed to OsmoNITB, OsmoSGSN does not feature a built-in HLR. |
| 134 | |
| 135 | It can thus operate only in the following two modes: |
| 136 | |
| 137 | . Accessing an external HLR (or HLR gateway) via the GSUP protocol |
Philipp Maier | ed17106 | 2017-03-08 17:50:33 +0100 | [diff] [blame] | 138 | . Accepting subscribers based on internal ACL (access control list), |
| 139 | see also <<auth-pol>> |
Harald Welte | 9f1331b | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 140 | |
| 141 | ==== Accessing an external HLR via GSUP |
| 142 | |
| 143 | The non-standard GSUP protocol was created to provide OsmoSGSN with |
| 144 | access to an external HLR while avoiding the complexities of the |
| 145 | TCAP/MAP protocol stack commonly used by HLRs. |
| 146 | |
| 147 | A custom HLR could either directly implement GSUP, or an external gateway |
| 148 | can be used to convert GSUP to the respective MAP operations. |
| 149 | |
| 150 | The primitives/operations of GSUP are modelled to have a 1:1 |
| 151 | correspondence to their MAP counterparts. However, the encoding is much |
| 152 | simplified by use of a binary TLV encoding similar to Layer 3 of |
| 153 | GSM/GPRS. |
| 154 | |
| 155 | GSUP performs a challenge-response authentication protocol called OAP, |
| 156 | which uses the standard MILEAGE algorithm for mutual authentication |
| 157 | between OsmoSGSN and the HLR/HLR-GW. |
| 158 | |
| 159 | [[sgsn-ex-gsup]] |
| 160 | .Example: Using an external HLR via GSUP |
| 161 | ---- |
| 162 | OsmoSGSN(config-sgsn)# gsup remote-ip 2.3.4.5 <1> |
| 163 | OsmoSGSN(config-sgsn)# gsup remote-port 10000 <2> |
| 164 | OsmoSGSN(config-sgsn)# gsup oap-k 000102030405060708090a0b0c0d0e0f <3> |
| 165 | OsmoSGSN(config-sgsn)# gsup oap-opc 101112131415161718191a1b1c1d1e1f <4> |
| 166 | ---- |
| 167 | <1> Configure the IP address of the (remote) HLR or HLR-GW |
| 168 | <2> Configure the TCP port of the (remote) HLR or HLR-GW |
| 169 | <3> Specify the OAP shared key |
| 170 | <4> Specify the OAP shared OPC |
| 171 | |
| 172 | |
| 173 | === CDR configuration |
| 174 | |
| 175 | OsmoSGSN can write a text log file containing CDR (call data records), |
| 176 | which are commonly used for accounting/billing purpose. |
| 177 | |
| 178 | .Example: CDR configuration |
| 179 | ---- |
| 180 | OsmoSGSN(config-sgsn)# cdr filename /var/log/osmosgsn.cdr |
| 181 | OsmoSGSN(config-sgsn)# cdr interval 600 <1> |
| 182 | ---- |
| 183 | <1> Periodically log existing PDP contexts every 600 seconds (10 min) |
| 184 | |
| 185 | The CDR file is a simple CSV file including a header line naming the |
| 186 | individual fields of each CSV line. |
| 187 | |
| 188 | [[sgsn-cdr]] |
Jonathan Brielmaier | 5530c91 | 2016-05-25 15:01:11 +0200 | [diff] [blame] | 189 | .Description of CSV fields in OsmoSGSN CDR file |
Harald Welte | 9f1331b | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 190 | [options="header",cols="15%,85%"] |
| 191 | |=== |
Harald Welte | 36dea39 | 2016-02-20 18:35:37 +0100 | [diff] [blame] | 192 | |Field Name|Description |
Harald Welte | 9f1331b | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 193 | |timestamp|Timestamp in YYYYMMDDhhmmssXXX where XXX are milli-seconds |
| 194 | |imsi|IMSI causing this CDR |
| 195 | |imei|IMEI causing this CDR |
| 196 | |msisdn|MSISDN causing this CDR (if known) |
| 197 | |cell_id|Cell ID in which the MS was registered last |
| 198 | |lac|Location Area Code in which the MS was registered last |
| 199 | |hlr|HLR of the subscriber |
Harald Welte | 36dea39 | 2016-02-20 18:35:37 +0100 | [diff] [blame] | 200 | |event|Possible events are explained below in <<sgsn-cdr-event>> |
Harald Welte | 9f1331b | 2016-02-20 10:56:10 +0100 | [diff] [blame] | 201 | |pdp| |
| 202 | |pdp_duration|duration of the PDP context so far |
| 203 | |ggsn_addr|GGSN related to the PDP context |
| 204 | |sgsn_addr|SGSN related to the PDP context |
| 205 | |apni|APN identifier of the PDP context |
| 206 | |eua_addr|IP address allocated to the PDP context |
| 207 | |vol_in|Number of bytes in MO direction |
| 208 | |vol_out|Number of bytes in MT direction |
| 209 | |charging_id|Related charging ID |
| 210 | |=== |
| 211 | |
| 212 | [[sgsn-cdr-event]] |
| 213 | .Description of OsmoSGSN CDR Events |
| 214 | [options="header",cols="15%,85%"] |
| 215 | |=== |
| 216 | |Event|Description |
| 217 | |attach|GMM ATTACH COMPLETE about to be sent to MS |
| 218 | |update|GMM ROUTING AREA UPDATE COMPLETE about to be sent to MS |
| 219 | |detach|GMM DETACH REQUEST received from MS |
| 220 | |free|Release of the MM context memory |
| 221 | |pdp-act|GTP CREATE PDP CONTEXT CONFIRM received from GGSN |
| 222 | |pdp-deact|GTP DELETE PDP CONTEXT CONFIRM received from GGSN |
| 223 | |pdp-terminate|Forced PDP context termination during MM context release |
| 224 | |pdp-free|Release of the PDP context memory |
| 225 | |=== |
Philipp Maier | e4e9011 | 2017-03-09 12:28:44 +0100 | [diff] [blame] | 226 | |
| 227 | |
| 228 | === User traffic compression |
| 229 | |
| 230 | In order to save optimize GPRS bandwith, OsmoSGSN implements header and data |
| 231 | compression schemes. The compression will reduce the packet length in order |
| 232 | to save radio bandwith. |
| 233 | |
| 234 | ==== Header compression |
| 235 | |
| 236 | On TCP/IP connections, each packet is prepended with a fairly long TCP/IP |
| 237 | header. The header contains a lot of static information that never changes |
| 238 | throughout the connection. (source and destination address, port numbers etc.) |
| 239 | OsmoSGSN implements a TCP/IP header compression scheme called RFC1144, also |
| 240 | known as SLHC. This type of header compression removes the TCP/IP header |
| 241 | entirely and replaces it with a shorter version, that only contains the |
| 242 | information that is absolutely necessary to identify and check the packet. |
| 243 | The receiving part then restores the original header and forwards it to higher |
| 244 | layers. |
| 245 | |
| 246 | *compression rfc1144 passive*:: |
| 247 | TCP/IP header compression has to be actively requested by the modem. The |
| 248 | network will not promote compression by itself. This is the recommended mode |
| 249 | of operation. |
| 250 | |
| 251 | *compression rfc1144 active slots <1-256>*:: |
| 252 | TCP/IP header compression is actively promoted by the network. Modems may still |
| 253 | actively request different compression parameters or reject the offered |
| 254 | compression parameters entirely. The number of slots is the maximum number |
| 255 | of packet headers per subscriber that can be stored in the codebook. |
| 256 | |
| 257 | .Example: Accept compression if requested: |
| 258 | ---- |
| 259 | sgsn |
| 260 | compression rfc1144 passive |
| 261 | ---- |
| 262 | |
| 263 | .Example: Actively promote compression: |
| 264 | ---- |
| 265 | sgsn |
| 266 | compression rfc1144 active slots 8 |
| 267 | ---- |
| 268 | |
| 269 | NOTE: The usage of TCP/IP options may disturb the RFC1144 header compression |
| 270 | scheme. TCP/IP options may render RFC1144 ineffective if variable data is |
| 271 | encoded into the option section of the TCP/IP packet. (e.g. TCP option 8, |
| 272 | Timestamp) |
| 273 | |
| 274 | |
| 275 | ==== Data compression |
| 276 | |
| 277 | Data compression works on the raw packet data, including the header part of the |
| 278 | packet. If enabled, header compression is applied before first data compression |
| 279 | is applied. OsmoSGSN implements the V.42bis data compression scheme. |
| 280 | |
| 281 | *compression rfc1144 passive*:: |
| 282 | V42bis data compression has to be actively requested by the modem. The network |
| 283 | will not promote compression by itself. This is the recommended mode of |
| 284 | operation. |
| 285 | |
| 286 | *compression v42bis active direction (ms|sgsn|both) codewords <512-65535> strlen <6-250>*:: |
| 287 | V42bis data compression is actively promoted by the network. Modems may still |
| 288 | actively request different compression parameters or reject the offered |
| 289 | compression parameters entirely. The direction configures which sides are |
| 290 | allowed to send compressed packets. For most cases, compressing 'both' |
| 291 | directions will be the preferred option. The following to parameters configure |
| 292 | the codebook size by the maxium number ('codewords') and size ('strlen') of |
| 293 | entries. |
| 294 | |
| 295 | .Example: Accept compression if requested: |
| 296 | ---- |
| 297 | sgsn |
| 298 | compression v42bis passive |
| 299 | ---- |
| 300 | |
| 301 | .Example: Actively promote compression: |
| 302 | ---- |
| 303 | sgsn |
| 304 | compression v42bis active direction both codewords 512 strlen 20 |
| 305 | ---- |