| Harald Welte | a5ad7a4 | 2019-03-21 22:52:44 +0100 | [diff] [blame^] | 1 | [[chapter_overview]] |
| 2 | == Overview |
| 3 | |
| 4 | === About OsmoGbPROXY |
| 5 | |
| 6 | OsmoGbPROXY is the Osmocom proxy for the 3GPP Gb interface. The Gb |
| 7 | interface is defined by 3GPP as the protocol between the BSS and the |
| 8 | SGSN inside the 2G/2.5G/2.75G packet switched network domain. |
| 9 | |
| 10 | As Osmocom implements a BTS-colocated PCU, there are potentially many |
| 11 | Gb interface connections between all those many PCUs in the network |
| 12 | and the SGSN. This can be cumbersome to configure/maintain at the |
| 13 | SGSN sine. |
| 14 | |
| 15 | OsmoGbPROXY aggregates many PCU-facing Gb connections into one Gb |
| 16 | connection to the SGSN. This is achieved by |
| 17 | |
| 18 | * maintaining sepaate NS-VCs on the PCU side and on the SGSN side |
| 19 | * more or less transparently routing BSSGP peer-to-peer Virtual Circuits |
| 20 | (BVCs) through the proxy |
| 21 | * having some special handling for the signaling BVC (BVCI=0) which is |
| 22 | shared among all the PCUs connected to the proxy |
| 23 | |
| 24 | === Data Model |
| 25 | |
| 26 | ==== gbproxy_config |
| 27 | |
| 28 | This contains the parsed configuration of the OsmoGbPROXY. |
| 29 | |
| 30 | ==== gproxy_peer |
| 31 | |
| 32 | A "peer" is any remote NS-entity that the proxy interacts with. A peer |
| 33 | includes information about: |
| 34 | |
| 35 | * the [unique] NSEI of the peer |
| 36 | * the [unique] BVCI of the peer |
| 37 | * the Routeing Area (RA) of the peer |
| 38 | |
| 39 | ==== gbproxy_tlli_state |
| 40 | |
| 41 | One of the (unique) TLLI of any of the subscribers/UEs attached to any of |
| 42 | the BTSs/PCUs served by the proxy. |
| 43 | |
| 44 | ==== gbproxy_link_info |
| 45 | |
| 46 | One of the [unique] subscribers/connections that are served through this |
| 47 | proxy. The information includes |
| 48 | |
| 49 | * the TLLI on BSS side |
| 50 | * the TLLI on SGSN side (may be different due to P-TMSI rewriting) |
| 51 | * the NSEI of the SGSN for this link |
| 52 | * a timestamp when we last conversed with this subscriber |
| 53 | * state related to IMSI acquisition |
| 54 | ** a temporary queue of stored messages (until IMSI acquisition succeeds) |
| 55 | ** N(U) rewriting state (inserting IDENTTIY REQ changes LLC sequence numbers) |
| 56 | |
| 57 | ==== gbproxy_match |
| 58 | |
| 59 | A single matching rule against which IMSIs are matched. The matching rule |
| 60 | is expressed as regular expression. There can be one such matching rule for |
| 61 | each |
| 62 | |
| 63 | * routing between two different SGSNs, see below |
| 64 | * patching of messages (e.g. APN, PLMN) |
| 65 | |
| 66 | |
| 67 | === Advanced Features |
| 68 | |
| 69 | ==== PLMN patching |
| 70 | |
| 71 | This feature permits to modify the PLMN inside any BSSGP messages |
| 72 | containing the Routing Area ID (RAID). |
| 73 | |
| 74 | The configured core-mcc and core-mnc will be used towards the SGSN, |
| 75 | irrespective of which MCC/MNC the PCU is using/reporting on Gb. |
| 76 | |
| 77 | ==== APN patching |
| 78 | |
| 79 | This will transparently re-write the APN name inside SM ACTIVATE PDP |
| 80 | REQUEST messages on the way from the MS to the SGSN. The patching is |
| 81 | performed based on matching on the IMSI of the subscriber. |
| 82 | |
| 83 | The configured core-apn will be used towards the SGSN, irrespective |
| 84 | of which APN the MS is requesting in its Layer3 signaling. |
| 85 | |
| 86 | APN patching can only be performed if no GPRS encryption is enabled in |
| 87 | the network! |
| 88 | |
| 89 | APN patching is useful in case a valid APN cannot reliably be |
| 90 | provisioned via other means, such as via the SIM Card, OTA-DM or via |
| 91 | CAMEL rewriting in the SGSN. |
| 92 | |
| 93 | ==== P-TMSI patching |
| 94 | |
| 95 | This feature transparently rewrite the P-TMSI between MS and SGSN. This |
| 96 | is required when using the Secondary SGSN support, as both SGSNs could |
| 97 | allocate overlapping TMSIs and we must make sure they're unique across |
| 98 | both SGSNs. |
| 99 | |
| 100 | P-TMSI patching is required by (and hence automatically enablede if |
| 101 | secondary SGSN support is enabled. |
| 102 | |
| 103 | P-TMSI patching can only be performed if no GPRS encryption is enabled in |
| 104 | the network! |
| 105 | |
| 106 | ==== IMSI Acquisition |
| 107 | |
| 108 | This is a special feature where the proxy will by itself inject GMM IDENTITY |
| 109 | REQUEST messages for the IMSI into the downlink BSSGP traffic in order |
| 110 | to establish the IMSI of subscribers for which it is not otherwise known |
| 111 | |
| 112 | IMSI acquisition is automatically enabled if secondary SGSN support is |
| 113 | enabled. |
| 114 | |
| 115 | ==== Secondary SGSN Support |
| 116 | |
| 117 | This allows the proxy to connect not only to one SGSN, but to two |
| 118 | different SGSNs. IMSI matching rules are applied to determine which of |
| 119 | the SGSNs is to be used for traffic of this subscriber. |
| 120 | |
| 121 | One possible use case of this feature is to have a "local break-out" for |
| 122 | subscribers who are native to this network (and hence save |
| 123 | latencies/overhead of back-hauling all related traffic via the |
| 124 | SGSN+GGSN) while at the same time maintaining the classic behavior for |
| 125 | inbound roaming subscribers, where the roaming agreements mandate that |
| 126 | data traffic is brought back to the GGSN in the HPLMN via the SGSN of |
| 127 | the VPLMN. |