In recent weeks, I have been able to pick up my work at GPRS support for
OpenBSC again. What has been done is:
- Add OML support to configure nanoBTS for EDGE
- Add RR (System Information) support to indicate EDGE support
- Make a OpenBSC + nanoBTS setup inter-operate with an existing SGSN
- Develop a proxy that can aggregate the Gb-interfaces of multiple BTS into
one Gb link to a real SGSN. This way the SGSN has only one Gb link
for all the cells under the control of a BSC, as opposed to one Gb link
for each and every BTS
What I'm working on now is the actual SGSN implementation. The SGSN is
mainly responsible for GPRS mobility management (GMM) and for terminating the
Layer2 (LLC)
protocol from the MS. This is very different from circuit-switched GSM, where
Layer2 (LAPDm) already terminates at the BTS.
The layering stack of GPRS is a real nightmare, I am sure I have indicated this
in this blog before. The Current OsmoSGSN code (available from the regular
openbsc.git repository) implements the NS, BSSGP and LLC layers, as well as the
basic GSM 04.08 GPRS Mobility Management messages like GPRS ATTACH/DETACH
and ROUTEING AREA UPDATE. The LLC code is still somewhat limited, but for the
time being it is sufficient.
What drove me crazy for a couple of days is the number of parameters that are
exchanged at PDP CONTEXT ATTACH time. There are no less than 26 different
quality of service (QoS) parameters negotiated (see struct
gsm48_qos at the bottom of this link), each of them from a wide range of
values. It's almost impossible to imagine more than 1% of all the possible
combinations have ever been used in production networks. The QoS parameter
negotiation works by the phone sending a list of requested parameters, to which
the SGSN responds with its selected parameters. My first thought was: Lets
be smart and simply echo back the QoS parameters - the phone must accept what
it has requested. That didn't work either: While the QoS structure is the same
in both ways, the actual values in uplink and downlink directions are encoded
differently. Who on earth defines such an encoding?
Next item was the XID exchange which is at the boundary between LLC and the
SNDCP (Sub-Network Dependent
Convergence Protocol). It works like this: The phone proposes an endless list
of parameters, which the SGSN can evaluate, and then depending on the parameter
type either negotiate up or down. According to the spec, sending an empty XID
response should mean "I agree with all your parameters". However, at least those
phones that I tested were not happy with that. So I decided to simply send back
the entire XID block to the phone. And believe it or not, as opposed to the QoS
parameters, this time it even worked
So now I'm facing the implementation of the actual SNDCP-to-GTP interworking,
which is nothing less but the guts of the SGSN. GTP is the
protocol used on the GGSN side. At least this time, GTP is sent directly over
TCP or UDP, i.e. the stacking inside the SGSN is only one layer deep, while on
the Gb-interface it is four (NS,BSSGP,LLC,SNDCP).
SNDCP interacts with the GPRS Mobility Management, GPRS Session Management
(both GSM 04.08 over LLC), the GTP interface to the GGSN, as well as other
parts. I expect many pitfalls on the way to getting it working, and given
the complexity involved I have already decided to stick much closer to the
specification than I usually did with the OpenBSC work. This means properly
implementing all the state machines with all their transitions, exceptions
and timers. I'm sure it's going to be "fun". The good part of it is:
Most of the SGSN will be re-used once we finally get around adding support for
3G/UMTS/WCDMA cells.