And rest octets are an abomination. I just have to get that on the record: an abomination.
01 December 2009
Rest Octets are an Abomination
In Harald Welte's recent blog, I see that he is adding rest octets to the system information messages in OpenBSC. We will eventually do the same for OpenBTS. I have implemented GSM rest octets in other systems in the past, but I am eager to look at Harald's code to see if his approach is cleaner than any of my old schemes.
Subscribe to:
Post Comments (Atom)
Hi David,
ReplyDeleteSorry to ask a stupid question. :-)
What are Rest Octets ?
Do you have a link or something that explain what are these ?
If yes, thank you very much.
If you do not have the time, I will try to find this by myself.
Or, may be, any other blog reader may help. :-)
Jean-Samuel.
:-)
So *you* are "anonymous"!
ReplyDeleteRest octets are extra data fields appended onto GSM messages in L3. For examples of rest octets, look at any of the "System Information" messages in GSM 04.08 or 3GPP 44.018
The original GSM L3 message formatting is TLV-style (type, length, value). Rest octets are extension fields added at the end of the TLV part of the message, filling in the "rest" of the L2 frame.
They are an abomination because they fall outside the normal L2 length of the message, leading to a kludge called the "L2 pseudolength". Quoting the spec: "The L2 Pseudo Length information element indicates the number of octets following it in the message which are to be interpreted in the scope of the phase 1 protocol, i.e. the total number of octets (excluding the Rest Octets) for which T, V, TV, LV, or TLV formatting is used (reference table 11.1/3GPP TS 24.007). "
They are also an abomination because they use CSN.1 format instead of the original TLV, so you need two different types of parsers. Worse yet, CSN.1 parsers are very tedious to code by hand and there are no good free tools for generating them automatically.
correction: no good free c-code generating tools :)
ReplyDeleteThank you for your kind reply. :-)
ReplyDeleteHi David,
ReplyDeleteFor somework. How different is your work from Harald's (implies why dont you two work together for a common goal since both the projects are very similar). Recently Harald implemented Silent Call in OpenBSC. Can this be done in OpenBTS?
Phil -
ReplyDeleteOur goals and approaches are different.
1. Harald is using off-the-shelf Um implementations (BS-11, IP Access) and working with the handset in L3 over Abis. We are implementing Um itself, all the way down to the radio waveforms.
2. Harald is interested in following the GSM core network specs, and simulating or building all of the major interfaces in the system. We eschew the standard core network in favor of a VoIP approach and use IETF-family interfaces where ever possible.
3. Harald is interested in education and security research. We are most interested in telephony, but realize that our work also has educational value and possible security applications.
That said, we communicate a lot and follow each other's work.
As for a silent call, any Um implementation open at L3 can be used to run a silent call. We have created silent calls by accident in the course of debugging normal call functions, but the silent call is not a normal telephony feature and therefore is of no practical value for OpenBTS. (And anyone who thinks the silent call technique is a trade secret is deeply mistaken. Like I said, you can easily create one by accident in the course of doing other things. The spec is terse, but that doesn't make it the Da Vinci code. Take the time to understand the spec and you will understand how it can happen.)
Thank you for your reply. I am hoping that your's and Harald work will bring about the next round of revolution in the Telecom field.
ReplyDeleteBest of Luck.
P.S: I am amazed to see how you efficiently manage so many different tasks (replying to queries, active on various blogs, working on BTS etc)