On 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