== Configuring OsmoSGSN Contrary to other network elements (like OsmoBSC, OsmoNITB), the OsmoSGSN has a relatively simple configuration. On the one hand, this is primary because the PCU configuration happens from the BSC side. On the other hand, it is because the Gb interface does not need an explicit configuration of all each PCU connecting to the SGSN. The administrator only has to ensure that the NS and BSSGP layer identities (NSEI, NSVCI, BVCI) are unique for each PCU connecting to the SGSN. === Configuring the Gp interface The Gp interface is the GTP-C and GTP-U based interface between the SGSN and the GGSNs. It is implemented via UDP on well-known source and destination ports. When a MS requests establishment of a PDP context, it specifies the APN (Access Point Name) to which the context shall be established. This APN determines which GGSN shall be used, and that in turn determines which external IP network the MS will be connected to. There are two modes in which GGSNs can be configured: . static GGSN/APN configuration . dynamic GGSN/APN configuration ==== Static GGSN/APN configuration In this mode, there is a static list of GGSNs and APNs configured in OsmoSGSN via the VTY / config file. This is a non-standard method outside of the 3GPP specifications for the SGSN, and is typically only used in private/small GPRS networks without any access to a GRX. .Example: Static GGSN/APN configuration (single catch-all GGSN) ---- OsmoSGSN(config-sgsn)# gtp local-ip 172.0.0.1 <1> OsmoSGSN(config-sgsn)# ggsn 0 remote-ip 127.0.0.2 <2> OsmoSGSN(config-sgsn)# ggsn 0 gtp-version 1 <3> OsmoSGSN(config-sgsn)# apn * ggsn 0 <4> ---- <1> Configure the local IP address at the SGSN used for Gp/GTP <2> Specify the remote IP address of the GGSN (for GGSN 0) <3> Specify the GTP protocol version used for GGSN 0 <4> Route all APN names to GGSN 0 ==== Dynamic GGSN/APN configuration In this mode, the SGSN will use a DNS-based method to perform the lookup from the APN (as specified by the MS) towards the GGSN IP address. This is the official method as per the 3GPP specifications for the SGSN, and what is used on GRX. .Example: Dynamic GGSN/APN configuration ---- OsmoSGSN(config-sgsn)# gtp local-ip 192.168.0.11 <1> OsmoSGSN(config-sgsn)# ggsn dynamic <2> OsmoSGSN(config-sgsn)# grx-dns-add 1.2.3.4 <3> ---- <1> Configure the local IP address at the SGSN used for Gp/GTP <2> Enable the dynamic GGSN resolving mode <3> Specify the IP address of a DNS server for APN resolution [[auth-pol]] === Authorization Policy The authorization policy controls by which rules a subscriber is accepted or rejected. The possible options range from accepting just all subscribers without further checking, to a fine grained access-control, handled by an external HLR. accept-all:: All subscribers that attempt to attach to the GPRS network are accepted without further checking. This option is intended to be used for testing in a controlled environment only. A wide-open network may attract subscribers from foreign networks and disrupt their service. It is highly recommended to pick one of the options below. remote:: This option allows to connect OsmoSGSN to an external HLR via the GSUP protocol. This will be the preferred option in larger networks. acl-only:: If no external HLR is available, the network operator has the option to control the access using an access control list. The access control list contains the IMSI numbers of the allowed subscribers. This method offers fine grained access control and is ideal for small networks and lab test environments. closed:: This policy mode softens the strict *acl-only* only mode by also implicitly accepting home network subscribers. The decision is made by the MCC and MNC part of the IMSI number. The combination of MCC and MNC fully identifies a subscribers home network, also known as a Home Network Identity (HNI, i.e. MCC and MNC found at the start of the IMSI, e.g. MCC 901 and MNC 700 with IMSI 901700000003080). NOTE: The policy mode *closed* must not be confused with the equally named policy that is defined for osmo-nitb! .Example: Assign or change authorization policy: ---- OsmoSGSN> enable OsmoSGSN# configure terminal OsmoSGSN(config)# sgsn OsmoSGSN(config-sgsn)# auth-policy acl-only <1> OsmoSGSN(config-sgsn)# write <2> Configuration saved to sgsn.cfg OsmoSGSN(config-sgsn)# end OsmoSGSN# disable OsmoSGSN> ---- <1> 'acl-only' is selected as authorization policy <2> Saves current changes to cofiguration to make this policy persistent .Example: Access control list: ---- sgsn auth-policy acl-only <1> imsi-acl add 001010000000003 imsi-acl add 001010000000002 imsi-acl add 001010000000001 imsi-acl add 901700000000068 <2> ---- <1> Set the authorization policy <2> Add as many subscribers as required === Subscriber Configuration As opposed to OsmoNITB, OsmoSGSN does not feature a built-in HLR. It can thus operate only in the following two modes: . Accessing an external HLR (or HLR gateway) via the GSUP protocol . Accepting subscribers based on internal ACL (access control list), see also <> ==== Accessing an external HLR via GSUP The non-standard GSUP protocol was created to provide OsmoSGSN with access to an external HLR while avoiding the complexities of the TCAP/MAP protocol stack commonly used by HLRs. A custom HLR could either directly implement GSUP, or an external gateway can be used to convert GSUP to the respective MAP operations. The primitives/operations of GSUP are modelled to have a 1:1 correspondence to their MAP counterparts. However, the encoding is much simplified by use of a binary TLV encoding similar to Layer 3 of GSM/GPRS. GSUP performs a challenge-response authentication protocol called OAP, which uses the standard MILEAGE algorithm for mutual authentication between OsmoSGSN and the HLR/HLR-GW. [[sgsn-ex-gsup]] .Example: Using an external HLR via GSUP ---- OsmoSGSN(config-sgsn)# gsup remote-ip 2.3.4.5 <1> OsmoSGSN(config-sgsn)# gsup remote-port 10000 <2> OsmoSGSN(config-sgsn)# gsup oap-k 000102030405060708090a0b0c0d0e0f <3> OsmoSGSN(config-sgsn)# gsup oap-opc 101112131415161718191a1b1c1d1e1f <4> ---- <1> Configure the IP address of the (remote) HLR or HLR-GW <2> Configure the TCP port of the (remote) HLR or HLR-GW <3> Specify the OAP shared key <4> Specify the OAP shared OPC === CDR configuration OsmoSGSN can write a text log file containing CDR (call data records), which are commonly used for accounting/billing purpose. .Example: CDR log file configuration ---- OsmoSGSN(config-sgsn)# cdr filename /var/log/osmosgsn.cdr OsmoSGSN(config-sgsn)# cdr interval 600 <1> ---- <1> Periodically log existing PDP contexts every 600 seconds (10 min) The CDR file is a simple CSV file including a header line naming the individual fields of each CSV line. ==== CDR CTRL interface Independently of whether logging CDR to a file is enabled or not, OsmoSGSN can also provide delivery of CDR through the CTRL interface. CDR are sent by means of TRAP messages with variable name _cdr-v1_, and its value is filled using the same CSV line format as in the log file, but without CSV header line. .Example: CDR delivery through CTRL TRAP messages ---- OsmoSGSN(config-sgsn)# cdr trap ---- ==== CDR Format [[sgsn-cdr]] .Description of CSV fields in OsmoSGSN CDR file [options="header",cols="15%,85%"] |=== |Field Name|Description |timestamp|Timestamp in YYYYMMDDhhmmssXXX where XXX are milli-seconds |imsi|IMSI causing this CDR |imei|IMEI causing this CDR |msisdn|MSISDN causing this CDR (if known) |cell_id|Cell ID in which the MS was registered last |lac|Location Area Code in which the MS was registered last |hlr|HLR of the subscriber |event|Possible events are explained below in <> |=== If the _event_ field describes a pdp context related action (starts with _pdp-_), then the following extra CSV fields are appended to the line: [[sgsn-cdr-pdp]] .Description of extra CSV fields for pdp context related events [options="header",cols="15%,85%"] |=== |Field Name|Description |pdp_duration|duration of the PDP context so far |ggsn_addr|GGSN related to the PDP context |sgsn_addr|SGSN related to the PDP context |apni|APN identifier of the PDP context |eua_addr|IP address allocated to the PDP context |vol_in|Number of bytes in MO direction |vol_out|Number of bytes in MT direction |charging_id|Related charging ID |=== [[sgsn-cdr-event]] .Description of OsmoSGSN CDR Events [options="header",cols="15%,85%"] |=== |Event|Description |attach|GMM ATTACH COMPLETE about to be sent to MS |update|GMM ROUTING AREA UPDATE COMPLETE about to be sent to MS |detach|GMM DETACH REQUEST received from MS |free|Release of the MM context memory |pdp-act|GTP CREATE PDP CONTEXT CONFIRM received from GGSN |pdp-deact|GTP DELETE PDP CONTEXT CONFIRM received from GGSN |pdp-terminate|Forced PDP context termination during MM context release |pdp-free|Release of the PDP context memory |pdp-periodic|Triggered by periodic timer, see VTY cmd _cdr interval_ |=== === User traffic compression In order to save optimize GPRS bandwith, OsmoSGSN implements header and data compression schemes. The compression will reduce the packet length in order to save radio bandwith. ==== Header compression On TCP/IP connections, each packet is prepended with a fairly long TCP/IP header. The header contains a lot of static information that never changes throughout the connection. (source and destination address, port numbers etc.) OsmoSGSN implements a TCP/IP header compression scheme called RFC1144, also known as SLHC. This type of header compression removes the TCP/IP header entirely and replaces it with a shorter version, that only contains the information that is absolutely necessary to identify and check the packet. The receiving part then restores the original header and forwards it to higher layers. *compression rfc1144 passive*:: TCP/IP header compression has to be actively requested by the modem. The network will not promote compression by itself. This is the recommended mode of operation. *compression rfc1144 active slots <1-256>*:: TCP/IP header compression is actively promoted by the network. Modems may still actively request different compression parameters or reject the offered compression parameters entirely. The number of slots is the maximum number of packet headers per subscriber that can be stored in the codebook. .Example: Accept compression if requested: ---- sgsn compression rfc1144 passive ---- .Example: Actively promote compression: ---- sgsn compression rfc1144 active slots 8 ---- NOTE: The usage of TCP/IP options may disturb the RFC1144 header compression scheme. TCP/IP options may render RFC1144 ineffective if variable data is encoded into the option section of the TCP/IP packet. (e.g. TCP option 8, Timestamp) ==== Data compression Data compression works on the raw packet data, including the header part of the packet. If enabled, header compression is applied before first data compression is applied. OsmoSGSN implements the V.42bis data compression scheme. *compression rfc1144 passive*:: V42bis data compression has to be actively requested by the modem. The network will not promote compression by itself. This is the recommended mode of operation. *compression v42bis active direction (ms|sgsn|both) codewords <512-65535> strlen <6-250>*:: V42bis data compression is actively promoted by the network. Modems may still actively request different compression parameters or reject the offered compression parameters entirely. The direction configures which sides are allowed to send compressed packets. For most cases, compressing 'both' directions will be the preferred option. The following to parameters configure the codebook size by the maxium number ('codewords') and size ('strlen') of entries. .Example: Accept compression if requested: ---- sgsn compression v42bis passive ---- .Example: Actively promote compression: ---- sgsn compression v42bis active direction both codewords 512 strlen 20 ----