open-cgf release 0.1

Well open-cgf doesn't get much attention, which is not that surprising given it's limited market appeal - you really have to own an SGSN or GGSN.

For those that are interested I have created a release tarball v0.1, which you can download from here.

Comments welcome. I need users who can run it against their hardware and report faults (and/or success!).

Latest Project: open-cgf - a Charging Gateway Function

This post is heavily 3GPP GPRS core network focussed. You may want to stop reading now.

I was annoyed that it is impossible to even test the CDR logging of GGSN/SGSNs without having a very expensive Charging Gateway Function server in your network. They are all expensive and yet all I wanted was something to terminate the stream of CDRs and write them to disk.

The protocol they use is GTP' (gtp prime), a bastardised version of the GPRS Tunnelling Protocol (GTP) in use between the RNCs, SGSNs and GGSNs. I use the bastardised in italics with good cause; it has all the hallmarks of a "I'll have a hack at it" protocol design, with multiple fixups and legacy mistakes. More later on that, perhaps, if I feel the need to vent.

Anyway, if you need a CGF to log your CDRs to disk, check out open-cgf. It is feature complete and implements all the functionality (up to Release 8) of a CGF. There are a few minor bugs and feature enhancements outstanding that I'm getting to slowly.

It needs some integration testing, and I need to exercise it with a better test framework, but it has served it's purpose as a small project that I can get to completion stage. I'm on call for support, just raise an issue on the site.

It is currently being tested by a 3rd party against a Cisco ITP. Who knew they could log CDRs. Not me, but when in SMSC-bypass mode they can, and must, log them. Via GTP'.

Next stop is the return to the parsing of ASN.1 CDRs, and opencdf, a similar type of server for IMS networks -- this time carried over Diameter.

3GPP CDR processing in Erlang

So I have made progress since my last post about this. I have a working 3GPP CDR decoder for Circuit Switched, Packet Switched and other miscellaneous CDRs.

In the process I broke my machine in the USA. Oops.

I left it compiling the ASN.1 one day and for some reason my definitions caused the Erlang ASN.1 compiler to loop. I left it like that for several days, and then my windows stopped responding.
It wouldn't remote reboot, respond to ping, or even prayers to . This is the point where I realised I'd not backed up anything on it for several weeks, including the CDR code. I really must subscribe to rsync.net

The story, dear reader, has a happy ending. One support ticket and a day or so later it was back as good as new and no more was said on the matter. I shall not complain that 100% CPU utilisation killed my box, and they did not complain about me breaking my budget server. Still, I should be upset, but for US$29 a month I can't really complain.

Back to 3GPP CDRs. I also have a version of the TAP (Transferred Accounts Procedure) specification. TAP is the CDR format used for international roaming CDR exchange, and is also in ASN.1 from version 3 onwards. There are amusing comments through the documentation about limiting sizes of files to avoid systems blowing up. Natch.

To their credit the GSMA have a specification that compiles cleanly first time, 3GPP could learn from that. The dependency hierarchy of the 3GPP CDR spec is horrifying and extends all the way back (and loops around) the earliest, ugliest, definitions from the ITU-T.

Anyway, I only need to decide what to do now, I'm thinking that this could expand to be a free 3GPP -> TAP service, possibly even including the RAP (Returned Accounts Procedure). At least it would provide an alternative to all the people charging for even a CDR editing tool. Sheesh.

First things first, I'm off to whip up the first page which should allow the upload of a CDR file and the specification of it's type (Circuit/Packet/etc) so it can be decoded. Not exciting but a prerequisite for the next AJAXy page that allows scrolling and drilldown into individual lineitems.

Wish me luck.

In my day...

...we used to decode our ASN.1 PER by hand. In the rain. With no pencils.

I doubt many will get the joke. I had a conversation today about 3GPP CDRs and how icky they are. I said that they are TLV based and I really don't have a problem with them, they're infinitely preferable to XML, but I think my colleague has been sucked in by the "human-readable means it is simple" XML/SIP propaganda. Apparently his hand-crafted ASN.1 BER decoder crashes if it encounters unknown tags, or somesuch, which is precisely what ASN.1 BER was designed to avoid -- it is easily extensible without breaking backward compatibility.

For the record I've decoded a reasonable amount of unaligned ASN.1 PER by hand as H.323 uses it, and I actually appreciate the feelings of the people that said that SIP was easier because it was text. XML and ASN.1 PER are at the opposite ends of the spectrum of verboseness, and they both go too far. The reality is though that the encoding of the messages wasn't what was fundamentally hard about H.323, it was how all the protocol levels fitted together and the inherent complexity of what it was solving. SIP is basically as complicated as H.323 now, and just as fractured.

I actually like ASN.1 BER though, it is mature and extensible and both cheap to parse and reasonably compact. So I think I will build a little decoder for my poor colleagues and demonstrate the power of Erlang, ASN.1, and a bit of gumption. It'll make a good webpage that I'm sure will be of interest to others in the industry, and it'll fit nicely alongside the MEID one. The only problem will be cleaning up all the 3GPP specifications, the typo's are atrocious.