This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Freyther zecke at selfish.orgOn Thursday 15 April 2010 15:24:47 Harald Welte wrote: Mahlzeit LaF0rge, > > Let me answer to your question from the bottom. If our only goal is to > > send malformed packets to the MS I think this interface is way too low > > level and for now all requirements can be handled by basic GSM08.08 > > messages. > > what do you mean by 'low level'? Their intent really is to send > arbitrary L3 messages in L2, even on strange SAPIs or on an unexpected > logical channel (SACCH vs. SDCCH). When looking at your proposed RSL like messages I was able (at least I thought/think so) to map it 1:1 to GSM0808 primitives and then had the feeling to implement most of GSM0808 at a lower level. > However, the MSC talks GSM 08.08 to the BSC. So are you proposing of > having a 08.08 interface between APP and MSC, or to have a BSC with > multiple 08.08 interfaces? After all, in almost all the use cases we > still want the regular MSC around for things like location updating, > authentication, etc. I had a bypass on the MSC in mind. E.g. one would send a PAGING REQUEST messages to the MSC, it would be forwarded to the BSC, then we would get a Complete Layer3 Information with the CM Service Request and then we could decide that for the type of XYZ, we want to hand out this communication to another app (okay, I made the CM Service Request up and didn't have that in mind today morning). > > The other question then is: Why 08.08? Wouldn't the logical consequence > be to implement actual MAP (like the E interface between MSC and MSC in > a real gsm network)? Good point, I have no idea about the protocol and the way it is working. My reason to propose GSM0808 as interface was twofold. We do have code to create and parse messages right now, and I think we can handle the use cases you have described with it (including using a custom link id and requesting weird channels) which would lead to a fast result for one of the primary use cases of OpenBSC (enable research). regards holger