gsmd/libgsm architecture

[Wally Ritchie]

I am concerned that the present architecture of gsmd/libgsm is not able
to meet likely needs and will need to be re-factored sooner or later.
If this is the case, it would be preferable to do this now (in P1 stage)
before we start to accumulate legacies at the application level.

I base this belief on what appears to be the inability of the present
architecture to cleanly meet some very basic use cases.

I am starting from the assumption that an openmoko device is a HANDSET.
This creates the user-expectation that it does what handsets presently
do, and hopefully a whole lot more. Openmoko should allow us to implement
whatever MT/ME functionality we wish but especially that which is
defined in the gsm/umts specs. Functions present in handsets today should
not be arbitrarily rendered unimplementable by design choices in
the architecture.

For more than a decade users connect their laptops to a network through
their gsm phone. RS232 or Infrared at first using PSTN inter-networking
all the way to today with gprs through DUN and FAX bluetooth profiles.
The answer to why I can't do this on a neo, or EMS or MMS, etc, shouldn't
be "that's not on our roadmap". The foundation should support roads to
anywhere - but especially roads to destinations where we have already
been and where we are today in the gsm world. I want my openmoko phone
to be able to do at least what a 5 year old handset can do (at least
outside the US).

For better or worse, the connection modalities in both gsm and Bluetooth
are not symmetric. Many connections are of the form MT <> TA <> TE
and the TE and MT side of the connection are not the same. With
BT, many profiles also involve asymetrical GW (Gateway) and DT
(Data Terminal) roles.

Linux, as a desktop or mobile PDA platform, has traditional been mostly
on the TE side of these connections. However, when the core MT
functionality of a handset is implemented within the box, we now
find ourselves on the MT/TA or GW side of these interfaces. A TE
side may still exist for applications runnable on the platform
which might have been originally designed for a PC but can now take
advantage of built-in capabilities. Such applications should be
able to use either built-in TA/ME or an external TA/ME connectable
through BT - even another neo.

A second problem arises from the differences between the 7.07/7.10
interface to a chipset and the 7.07/7.10 interface between handset
as MT/TA and a TE (e.g. a PC). The TA interface exported by the
MT Core functionality includes some portions that pass down to the
chipset stack and some portions that are implemented "above" the
chipset. For example, most MT's have phonebooks stored on the SIM
card and phonebooks stored in the MT. Both should be accessible
by a TE. Some functions of the terminal (e.g volume control)
are not handled by the chipset but by other portions of the core MT.

Because 7.07/7.05 includes nearly all necessary functions, it seems
to me that openmoko should implement an architectural layer that is
a full standard's compliant TA interface with every function that
makes sense in the context of the core MT's capabilities. By core MT
I mean not only the gsm chipset but additional functions that reside
in the core MT but are implemented through hardware or software
outside of the gsm chipset per se. Audio path control, MT phonebooks,
SMS storage, EMS, all come immediately to mind.

If there is some core MT functionality not covered by 7.07/7.05 that
is needed, we could invent additional commands. I can't think of any
off hand for the MT<>TA<>TE paths. (I can think of several for the
7.07 interface to the chipset, but this is outside of our domain.)

gsmd needs to be the Core MT's traffic cop and control both the GSM
chipset and other core MT hardware devices. It also needs to handle
priority and synchronization chores. But I believe that most interactions
with the Core MT can be handled by a multiple session 7.07 layer.
gsmd should support TE applications running on the phone as well as
TE applications within external devices. Other than priority issues,
the operations should be the same, all implemented as transport
independent 7.07 streams.

If an openmoko handset supports a BT fax gateway profile, then gsmd
need only be informed of the connection and open the appropriate
virtual port to the external TE. A 7.07 stream then flows over the
connection. For internal TE apps, like a dialer or phone book editor,
linux or TCP/IP sockets would be used as transport. Again, what flows
through these connections is a 7.07 stream. Alternatively, some multiple
port serial driver closely associated with gsmd could provide virtual
ports opened by applications that connect directly to gsmd and once
again what flows through the session connection is a 7.07 stream.

gsmd then becomes a general 7.07 session handler. It accepts 7.07 streams
over a multiplicity of sessions and responds based on the state of the
core MT generally and the state of the particular session. It would
also need to interface to whatever database stores the MT data not
stored on the SIM.

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.

Since I don't have a Neo yet, (2 on order), I'll have to wait till it
comes in to validate the above approach in the context of the calypso
based neo1973. After all, the entire documentation we have on the
calypso is the output of AT+CLAC and a (possible) block diagram. (Does
anybody known what actual chip number the baseband is?). Actually,
the AT+CLAC is a lot but I wish I had the AT+xxxx=? for each of
these as well. In any case, hopefully these are now just days away.

Perhaps I have missed something here. May be the code I'm looking
at is from the wrong trees. Please show me that the present path is
going to work for those who want this platform to be able to hold a full
function high-end gsm handset.

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.

Any comments? thoughts? flames?