gsmd/libgsm architecture

[Wally Ritchie]

On 7/20/07, Alan Jones <junk at alan2.com> wrote:

>
> I think you identify a good deficiency in the current plan, in that there does not seem to be any plans to support 07.07 commands
> which terminate to the application processor instead of the GSM chipset. However, my mind takes me to a slightly different solution.
> In my vision, it is highly desirable to keep all knowledge of the archaic 07.07 AT commands entirely contained in gsmd. I would
> propose an architecture not so dissimilar to what you are suggesting: gsmd would have three primary interfaces: the 07.07/07.10 link
> to the GSM chipset (somewhat of a "client" model), the transport independent 07.07 (and possibly 07.10) links coming in from
> BT/USB/whatever (somewhat of a "server" model), and finally a DBUS link from resident applications (or possibly external apps over
> IP).
>
> In this world, there would essentially be a subsystem within gsmd which all external TE 07.07 streams terminate to. That subsystem
> would essentially act as a smart proxy, acting as a TA to the external entity and somewhat of a TE from the chipset's perspective,
> processing each command received. Some of them may go straight to the chipset, while others may be implemented in a more combined
> mechanism as you described, for things like phonebooks and SMS. This brings me to the first reason why I think that using dbus
> directly from gsmd is desirable instead of the existing proprietary or proposed 07.07 based protocols. In order for gsmd to service
> these phonebook or SMS requests, it is going to need to interact with whatever entity controls that data. Presumably this is the
> embedded evolution data server, who's primary (only?) interface is dbus.
>
I'm thinking of 7.07 more as a layer with a dbus layer above it. 7.07
already handles voice
call control, fax, async data, sync data, gprs packet data, sim, sms,
phonebook,
etc. etc. The dbus layer can just sit above. The main reason for the
layering is to permit
separate independent evolution of each layer. gsmd provides
synchronization and serialization for both 7.07 streams and native
dbus. New apps will almost always use
dbus. Legacy and apps on external TE use the 7.07. gsmd synchronizes
both. A local
app like fax (or secure phone over CSD) can use 7.07.

AT commands may be archaic but they are current development in gsm/umts. Latest
spec is June 2007 - two months ago. Yes its archaic. I once owned the hayes 300
S100 board modem which was its predecessor. 7.07 is not going away.
It's actively
maintained. It evolves with the rest of the gsm/utms specs and over
the years it pretty
much reflects the full capabilities of everything below.
> As a final note on this interface, I think that implementing 07.10 for external TE is of limited utility, but should not be
> precluded. I know there is at least one user-land implementation (albeit TE-side focused) out there.
>
> In my opinion, except for debugging, there is little value in giving applications (even if there is a library to abstract it) access
> to 07.07 level activities. Applications are going to be interested in much higher level events like "Make Call", "SMS Received",
> etc... I would love to see a situation where the dbus API exported is high enough level that libgsm would entirely disappear.
> Applications would simply receive alerts and make method calls on the gsmd dbus presence directly (maybe a little dbus framework
> will be needed, but most apps should already have this).
I agree that dbus can be the primary IPC for local apps. I agree with
Koen that it is
probably better than the uberleet sockets. But I'm still trying to
think through all of the
synchronization issues, epecially on future umts capable hardware.

Present chipset is Class B gprs and does not support simultaneous
voice call and
data streams. Future chipset will support DTM  (I sure hope) and will
be Class A and
eventually umts. Synchronization/Serialization in gpsd has to account for this.

>
> > Some would, I suppose, argue that AT commands are too complicated as
> > an API. This is where a libgsm fits in. Any libxxx layer would
> > talk to the core MT through a 7.07 stream. Different libraries could
> > abstract the 7.07 session in different ways depending on the preferences
> > of the particular application programmer. These libraries could have
> > various bindings to whatever. gsmd, however,  would remain the stable
> > base for all of them. Multiple libgsm equivalents could coexist and
> > I expect that one of them would eventual dominate.
>
> As is likely apparent above, my vision leads me to keep the application layer access library as minimal as possible, really just
> providing IPC with little to no logic. In my opinion, having multiple applications possibly querying and processing
> similar/identical 07.07 streams (and potentially parsing SMS TPDUs, etc...) is undesirable.
>
> One example of a situation where this scheme would be very slick is for SMS reception. gsmd would receive  the asynchronous 07.07
> event, query out the message, and post a "New SMS" alert to its dbus subscribers containing maybe a message reference (which can be
> used to retrieve the entire message from gsmd), as well as maybe some useful information like origination address and a short text
> summary (or maybe just the whole message). The two key applications which I could see being interested in this would be the SMS
> reader and some sort of notification applet to pop a notification to the user. Both could receive the alert and take appropriate
> actions without redundantly accessing the chipset. (of course, there are other solutions to this specific issue, it is just used as
> an example)
>
> The final thing I feel that this brings to the system is a better sharing of state information about the GSM chipset. Instead of
> everything in the system thinking it has an exclusive connection to the GSM chipset, there is an intermediary keeping track of
> things. It changes the mindset a little, and might help provide more useful failure information to the user if conflicting requests
> are made. You especially wouldn't want two applications simultaneously trying to establish GPRS connectivity using virtual
> "independent" links to the chipset, something needs to be in charge of that.
>
That something is gsmd or equivalent. There should be only one dbus/gsmd layer
and libgsm should probably be deprecated in favor of using dbus or
direct 7.07 access
necessary for external TE and legacy apps like fax. This means that we
should probably
get down to specifying (not coding) the dbus layer and
serialization/synchronization
layers.
> On that topic (but a bit off the main topic), does anybody know if the GSM chipset supports multiple simultaneous PDP contexts? If
> not, then the external TE support proxy will need to be cognizant of the state of the "internal" GPRS connection status. In this
> case, maybe the ability to be a NAT gateway over WiFi or Ethernet might be useful. Alternately, it would be theoretically possible
> to allow the external TE to terminate its PPP link directly to the Neo, which NATs the traffic out over GPRS.
>
gsmd layer should be gateway to single or multiple gprs sessions - depending on
capabilities of chipset. Should also be able to tunnel session through
WiFi/usb We
probably need some concept of "connection cost". (Wouldn't want to watch youtube
at $0.01 per k byte)
>
> > I am toying with the idea of undertaking the writing of an alternative
> > gpsd that would implement the above approach. I do not want to re-invent
> > the wheel but neither do I want to use a pentagon where a wheel is
> > needed.
>
> If it helps, I too am pondering this idea. At a minimum, I have a mind to build an additional, higher-level "gsmd+" which sits at
> the dbus level and implements the above described architecture on top of libgsm's passthrough mode. This interim solution might not
> be so bad in the long haul either. To go back to your point about building a solid gsmd focused on providing a solid 07.07
> foundation, maybe this extra separation will turn into a reasonable long term architecture. Providing essentially a higher level
> dbus-based "gsmd+" for applications and external TEs to access, which interfaces with gsmd via 07.07. Possibly reducing the
> "clients" that gsmd services to only the "gsmd+" process.
>
> Thoughts?
I think we have the start of an approach here. Why not call this
"umtsd" to distinguish
it from the present gsmd/libgsm approach. I'm reluctant to interfere
with the current process, at least until my neos come in and I have
some hardware in my hands.
Although I don't think the present approach is going to work for
very long, it might get the platform to making some phone calls which good.

Let's try to define a reasonably complete set of dbus connection
names, interfaces,
and methods, as a starting point. I'll try to put together a reference
model that covers
what we have talked about above and identifies the layers and
applications in gsm speak.

Cheers

Wally

>
> -Alan
>
>
>