Re: About GSM/Wifi handover

> Do you think we have enough information about the GSM
modem embedded in this
phone to allow this service to be implemented?

While I cannot answer for certain, I would say that it is
incredibly unlikely that we will get anything other than an
analog voice signal from the phone, so we would have to
re-run it through a gsm vocoder to get the data you want,
which
isn't going to produce great quality voice. Some higher bit
rate VoIP codec might work better.

With that said, I think the much bigger issue here is
getting cooperation from the networks. You can't even think
about
orchestrating a handover without the provider explicitly
allowing you to talk to their network. Again, I cannot say
for
certain, but I would bet that it is not something they just
give anybody who asks access to. The T-Mobile setup that
was
recently released is controlled by T-Mobile on both ends,
and I would bet it is enabled on a per-subscriber basis,
after
you pay for it. I hope there is a trend in this direction to
open the cellular network (and so does the FCC), but I
wouldn't hold my breath right now.

-Alan

(apologies for the fake reply, this was sent before I
subscribed.)

On 7/25/07, S�bastien Lorquet <squalylgmail.com> wrote:
> Hello again,
>
> I'm continuing investigations about wifi handover.
> It's called UMA and is documented in 3GPP TS 44.318 and
3GPP TS 43.318
>
> To say it fast, the goal is to route mobile calls using
an IP/IPSec link to
> a gateway server.
>
> I currently have 2 blocking problems.
>
> The first is the ability to get authentication
credentials from the SIM. The
> EAP/SIM protocol documented in previous specs
explicitely asks access to the
> SIM card algorithms A3/A8, but the only available
interface to neo's modem
> is the AT line.
> I had a discussion minutes ago on IRC with XorA;
according to him, it's
> possible if we can run ISO7816 commands with the AT
interface to drive the
> card itself.
> Do you know any possibility to do this on neo's modem?
Are the specs
> available or not?
>
I will try to answer as best I know. I cannot guarantee the
following
as definitive.

There is a defined AT+CEAP command which supports this. It
is not supported on
the present chipset and it may require a 3G USIM.

Direct control of GSM class commands on SIM is not supported
by the
chipset (see earlier posts from Harold on this list). I seem
to remember this
being prohibited to external TE control. It would be nice to
have a tunnel to
the SIM card (two way) for other reasons e.g. support for
the Bluetooth SIM
profile. Perhaps this may appear in later versions of the
chipset.

> Secondly if we suppose that step is solved, it will be
necessary to shut
> down the modem without sending a DETACH message! Will
it be possible with AT
> or not?
I am not aware of any at present. It could fit into the
framework
pretty easily. There
may be a vendor specific proprietary command to do it. As
you probably know from
reading the specs there are a lot of issues in the handover
from OTA
to public IP.
>
> Please consider this as a feasability study only, I'm
currently
> investigating ways to get UMA on an open platform.
Don't speak too much
> about carriers implication in the subject now, this is
not yet an issue
> since I want to know if it's technically possible
before going further.
>
Tunneling to the MSC is coming. Its in everyone's interest.
> Sincerely yours, (and sorry for my bad english, not so
easy to describe
> technical things without translating french thoughts ;)
)
>
I know - you have too many words in French ;)
> S�bastien LORQUET.
>
Cheers

> IT'S CALLED UMA AND IS DOCUMENTED IN 3GPP TS 44.318 AND
3GPP TS 43.318

WELL, WITH A QUICK LOOK AT 44.318, WHICH IS TITLED
"GENERIC ACCESS (GA) TO THE A/GB INTERFACE", I'D
SAY THAT THIS IS NOT A SPEC WHICH IS GOING TO HELP US OUT.
43.318 IS THE TECHNICAL REALIZATION OF THE SAME TECHNOLOGY.


THIS DIAGRAM DISPLAYS THE LOCATION OF THE A/GB INTERFACES
PRETTY CLEARLY:
HTTPS://WWW.NETHAWK.FI/PRODUCTS/PLAYGROUND_1600X1200.JPG

ANYWAYS, THE ACCESS TO THE MSC WHICH THOSE SPECS DEFINE IS
WAY LOWER (STACK WISE) THAN WE HAVE ACCESS TO. IF YOU LOOK
AT FIGURE 2 AND 3 IN 43.318, THE STACK IS PRETTY CLEARLY
DEFINED. THE GA PROTOCOLS JUST PROVIDE AN ALTERNATE
TRANSPORT LAYER FOR THE GSM LAYER 3 MESSAGING, ON WHICH
MESSAGES FROM MM AND FRIENDS TRAVEL, INSTEAD OF GOING OUT
OVER RR/LAPDM/GSM. THIS TECHNOLOGY IS MORE AKIN TO A MOBILE
HANDOVER BETWEEN GSM AND UMTS (INTER-RAT HANDOVER), WHERE
ALL THE SIGNALING AND MOBILITY STUFF STAYS THE SAME, JUST
THE RAW DATA TRANSPORT (L1 AND L2) CHANGES.

I CAN SAY WITH ALMOST ABSOLUTE CERTAINTY THAT WE WILL NOT BE
ABLE TO GET THIS MESSAGING WITHOUT EXPLICIT SUPPORT FROM THE
GSM BASEBAND MODULE... AND IN THAT CASE, I WOULD FULLY
EXPECT THAT THE BASEBAND MODULE WOULD IMPLEMENT THE GA AND
IPSEC STUFF ITSELF (MAYBE IN A CASE WHERE IT OWNS THE WIFI
CONTROLLER) FOR SECURITY REASONS.

WALLY, YOU SEEM TO BE PRETTY FAMILIAR WITH 07.07, HAVE YOU
SEEN ANY EXTENSIONS TO SUPPORT THIS TECHNOLOGY FROM THE HIGH
LEVEL COMMANDS? 

I HONESTLY THINK THAT IT WILL TAKE A VOIP-BASED SOLUTION
(SUPPORTED BY THE SERVICE PROVIDERS), SINCE IT IS REALLY THE
ONLY TRUE OPEN TELEPHONY TECHNOLOGY, IN ORDER TO GET THE
SIGNALING AND DATA TRANSPORT TO A HIGH ENOUGH LEVEL THAT WE
COULD IMPLEMENT THIS SORT OF THING WITHOUT EXPLICIT SUPPORT
IN THE BASEBAND. WITH THAT SAID, FROM A NETWORK PERSPECTIVE,
SOME LEVEL OF SUPPORT IN THE BASEBAND WOULD MAKE THINGS
SIGNIFICANTLY SMOOTHER, SO I WOULD ANTICIPATE THAT ANY
PROVIDER DOING SUCH THING WOULD JUST EXPECT THE BASEBAND
CHIPSET TO IMPLEMENT AT LEAST SOME STUFF. KEEP IN MIND THAT
GENERALLY, HANDOVER IS FULLY CONTROLLED BY THE NETWORK, WITH
INPUT FROM THE MS.

-ALAN

On 7/26/07, Alan Jones <junkalan2.com> wrote:
> > It's called UMA and is documented in 3GPP TS
44.318 and 3GPP TS 43.318
>
> Well, with a quick look at 44.318, which is titled
"Generic Access (GA) to the A/Gb interface", I'd
say that this is not a spec which is going to help us out.
43.318 is the technical realization of the same technology.
>
> This diagram displays the location of the A/Gb
interfaces pretty clearly:
> https://www.nethawk.fi/products/playground_1600x1200.jpg

>
> Anyways, the access to the MSC which those specs define
is way lower (stack wise) than we have access to. If you
look at figure 2 and 3 in 43.318, the stack is pretty
clearly defined. The GA protocols just provide an alternate
transport layer for the GSM Layer 3 messaging, on which
messages from MM and friends travel, instead of going out
over RR/LAPDM/GSM. This technology is more akin to a mobile
handover between GSM and UMTS (Inter-RAT Handover), where
all the signaling and mobility stuff stays the same, just
the raw data transport (L1 and L2) changes.
>
> I can say with almost absolute certainty that we will
not be able to get this messaging without explicit support
from the GSM baseband module... And in that case, I would
fully expect that the baseband module would implement the GA
and IPSec stuff itself (maybe in a case where it owns the
WiFi controller) for security reasons.
>
> Wally, you seem to be pretty familiar with 07.07, have
you seen any extensions to support this technology from the
high level commands?
>
I haven't seen anything specific other the EAP and
definitely this
cannot be done without
support (modest I think) in the chipset.

At the R interface, it may require little more than a new
PDP type for
the GSM Layer 3.
This would most likely be carried on a separate multiplexor
channel.
Once a suitable secure tunnel is opened for transport, the
GSM stack
can perform the
handover as appropriate. I'd like to think a bit more about
the QoS
implications
I think the point is that the tunnel is secure and the TE
functions as
a connectivity
mechanism. Everything beyond the connection through the
public
internet is managed
entirely within the GSM stack. It is relatively safe to
export this
functionality through
the TE because everything is encrypted by the GSM stack. QoS
is probably needed
end to end to keep the packet delays reasonably for the RTP
payloads.
Link speed
to the chipset probably needs to be increased to lower
latency as well.

> I honestly think that it will take a VoIP-based
solution (supported by the service providers), since it is
really the only true open telephony technology, in order to
get the signaling and data transport to a high enough level
that we could implement this sort of thing without explicit
support in the baseband. With that said, from a network
perspective, some level of support in the baseband would
make things significantly smoother, so I would anticipate
that any provider doing such thing would just expect the
baseband chipset to implement at least some stuff. Keep in
mind that generally, Handover is fully controlled by the
network, with input from the MS.
>
I think that in relatively short order (in GSM terms) we
will see
interworking with GSM
directly through SIP gateways and tunneling of GSM streams
through the
public internet.
But I leave the non-technical discussions to a different
group. What
is relevant here is
that we don't preclude supporting these in the architecture
of gsmd or
its successors.

Cheers, Wally
> -Alan
>
>
>
>
>