RE: USSD interface for ModemManager

["Herriot, Nicholas, VF-Group" <Nicholas Herriot vodafone com>]

It's network and service dependant.
So for UK, Holland, Greece, Egypt there are retry schedules for
services. (Other Networks may have different Nodes from different
vendors so I'm not 100% sure.) We defined a table on the HLR and MLR to
control those schedules. The schedules are non linear and asymmetric.
E.g. 0min, 30min, 1hr, 4hr and another may be 5min, 35min, 65min,
4hr+5min etc......

This means that if a VLR were to fall over then suddenly comes back up
you don't start firing off millions of MWD to all subs on that node.

I take your point and nice idea. My thoughts are what USSD will and are
being used for. Very much a way of building services that pass through
or over the core network. Meaning that the logic is really part of the
service. We are building our PAYT features into the betavine client now
for 4 of our networks. We have no plans to persist state or start
receiving lost messages to infer state. All too complex!!! :-) .... So
if the modem manager core was to spit out lost messages our client would
just bin them and start from a known state.

I know of no USSD service that is network initiated, but I don't know
them all! India is the country that use this service most for obvious
reasons. I'll make some enquires next week on some example services used
in India utilising USSD and post a link here for anyone interested to
read on the betavine web site.

Hope this helps, kind regards Nicholas.

 

-----Original Message-----
From: Dan Williams [mailto:dcbw redhat com] 
Sent: 11 March 2010 23:25
To: Herriot, Nicholas, VF-Group
Cc: networkmanager-list gnome org
Subject: Re: USSD interface for ModemManager

On Wed, 2010-03-10 at 13:23 +0100, Herriot, Nicholas, VF-Group wrote:
> Hi all,
> 
> 
> <stick_head_above_parapit>
> 
> Just thought I'd put Vodafone's views forward. 
> Pablo the API is fine, and I'm happy we mirror the ConnMan guys. I've 
> been reading through their doc's and Ofono Stack.
> 
> There is no need to over-work the USSD API. If the network sends a 
> USSD message which requires action and get's no response it will
either:
> 1) stick it on a retry queue.

Any idea how often the network will retry?

> 2) don't action the request until it got a response.

Ok; though depending on how long before the network retries, the client
app may not get the request for at least the retry interval.  I'd still
rather have the client app be able to get that request immediately
though, that just seems nicer.

> Furthermore, if a client starts up and see's a buffered/cached USSD 
> message saying that you have to respond to subscribed to that new data

> service how would the client know what it's for? For that use case to

These properties are for /network/-initiated requests, thus I assume
that the request from the network includes all necessary details?
Client-initiated requests would still use Initiate() of course.  Or does
the network initiate requests related to the client-initiated request?
That model would have problems...

> work the client would have to persist the state - but in our example 
> the app crashed so did not get to persist anything!
> 
> -Message to Marcel-
> You are a very cheeky man! But very true! :-)
> 
> -Message to Dan-
> Chill out you are still the incumbent! ;-)

Competition is not a problem; it makes everyone better.

The problem is lack of focus on the technical issues under discussion,
instead sending mails the lists saying "hey, use my project! it's
awesome!".  This list is about development of NetworkManager and
ModemManager.  It's fine to reference some other project, even
"competing" ones, with respect to specific technical issues.

It is not OK to evangelize other projects. (e.g. "any reason why you are
not using oFono.")

Besides, I doubt Pablo is much interested in using oFono, since he works
on a different modem manager and thus oFono is "competing" with Wader in
the same way it "competes" with ModemManager.  Which shows some
misunderstanding on Marcel's part as to what the original USSD
discussion was actually about.

Good: "oFono developed an API for USSD already, perhaps you should take
a look at it to learn from the mistakes we made and the problems we
encountered"

Bad: "any reason why you are not using oFono. It is a full telephony
stack and does a lot more things in the background that are mandatory.
And you would not have to implement the whole USSD support all by
yourself.  Especially when we merge the integrated PPP support into
oFono, then it might be a nice alternative for you actually."

I think you can see the difference.

Dan

> -Message to all-
> Vodafone are using wader-core to deliver a packaged modem manager, 
> which is why Pablo has been asking about USSD.
> The reason why Vodafone have pursued it's coarse of action in regards 
> to building their own modem manager and not use NM or CM directly are:
> 1)- The open source community do not have the time and resources to 
> deliver the functionality with the huge range of manufacturers
dongles.
> We are extended a hand to ensure that our datacards will work on
Linux.
> We think that it's best served by putting our time into the device - 
> plugin and operator feature set into the betavine connection manger. 
> We have no wish to control or dominate anybody's Network Manger, but 
> do wish to ensure our datacards and services work.
> 
> To answer Marcel's question. We believe ConnMan is behind in areas of 
> dongle support otherwise we would be using the USSD stack if possible 
> (Why re-invent the wheel right!). We also are not sure how to 
> incorporate our plugin modem architecture and many other features YET!

> - it would maybe take longer to do this than to add in USSD to
wader-core.
> Our thoughts were to push forward with supporting Network Manager 
> deliver a good modem manager experience till April time.
> 
> If anyone wants to take any of this off line and ask me more of 
> Vodafone's plans please ping me. This flame war stuff between NM and 
> CM has to stop! Not good for Linux. Not good for OS. Not good for the 
> community! Not professional!
> 
> 
> Regards, Nicholas.
> 
> </stick_head_above_parapit>
> 
> 
> 
> 
> 
> On Tue, 2010-03-09 at 13:45 +0100, Pablo Mart? Gamboa wrote:
> > Hi Dan, Marcel and others,
> > 
> > 
> > we would like to extend the ModemManager API so that it can handle 
> > USSD commands. The USSD API of oFono [0] looks quite nice IMHO and 
> > I'd
> 
> > like to propose a similar API:
> 
> I'd actually change two things; this API (and by extension the ofono
> one) doesn't allow clients to respond to a USSD request that is 
> pending when they start up.  Say your app sends the request, then 
> crashes or something.  When it's crashed, the network sends the 
> response.  Now your app can't get the response when it starts back up 
> and handle it, it would have to cancel the USSD session and send the
request again.
> 
> A more robust API would change the NotificationReceived and 
> RequestReceived signals into properties instead, which can be queried 
> when your app starts up.  See below...
> 
> I did add a org.freedesktop.DBus.Properties.MmPropertiesChanged signal

> to ModemManager a bit ago, mainly to support the 
> org.freedesktop.ModemManager.Modem.Enabled property.  So we can 
> certainly use that.
> 
> > 
> > USSD Interface
> > ===============
> > 
> > 
> > Service org.freedesktop.ModemManager
> > Interface         org.freedesktop.ModemManager.Modem.Gsm.Ussd
> > 
> > 
> > Methods string Initiate(string command)
> > 
> > 
> > Sends a USSD command string to the network initiating a session.  
> > When
> 
> > the request is handled by the appropriate node of the network, the 
> > method returns the response or an appropriate error.  The network 
> > may be awaiting further response from the ME after returning from 
> > this method and no new command can be initiated until this one is 
> > cancelled
> 
> > or ended.
> > 
> > 
> > void Respond(string reply)
> > 
> > 
> > Send a response to the network either when it is awaiting further 
> > input after Initiate() was called or after a network-initiated 
> > request.
> > 
> > 
> > void Cancel()
> > 
> > 
> > Cancel an ongoing USSD session, mobile- or network-initiated.
> > 
> > 
> > Signals 
> >                 NotificationReceived(string message)
> 
> I would change this to a read-only "NetworkNotification" property, and

> then we can use the normal D-Bus properties API to get it, and the 
> MmPropertiesChanged signal to notify when it changes.
> 
> > 
> > Signal is emitted on a network-initiated USSD request for which no 
> > response is needed.
> > 
> > 
> > RequestReceived(string message)
> 
> Same here, I'd suggest a read-only "NetworkRequest" property.
> 
> Obviously when there is no request from the network, these two 
> properties would be empty strings.
> 
> Any thoughts on this?
> 
> Dan
> 
> 
> 
> > 
> > Signal is emitted on a network-initiated USSD request for which a 
> > response must be sent using the Respond method unless it is 
> > cancelled or the request is not supported.
> > 
> > 
> > Properties string State [readonly]
> > 
> > 
> > Reflects the state of current USSD session.  The values have the 
> > following meanings:
> > 
> > 
> > "idle" No active USSD session.
> > "active" A session is active between the network and the ME, the ME 
> > is
> 
> > waiting for a reply from the network.
> > "user-response" The network is waiting for the user's response, 
> > client
> 
> > must call Respond().
> > 
> > 
> > 
> > 
> > It is basically a copy of their API (they nailed it down) except for

> > GetProperties and PropertiesChanged signal which are
ConnMan-specific.
> > I haven't had a use-case yet for the "Respond" command (my USSD 
> > petitions are simple), but it needs to be there indeed for future 
> > uses. Thoughts?
> > 
> > 
> > [0]
> > http://git.kernel.org/?p=network/ofono/ofono.git;a=blob_plain;f=doc/
> > su
> > pplementaryservices-api.txt;hb=HEAD
> > 
> > --
> > Pablo Mart?
> > http://www.linkedin.com/in/pmarti || http://www.warp.es python -c 
> > "print '706d6172746940776172702e6573'.decode('hex')"
> > 
> > 
> 
> 
> 
> 
> ------------------------------
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list