Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging

From: [email-masked]
Date: Thu, 12 Apr 2001 13:52:53 +0300

Hi Jim,

> Not sure how to do this constructively yet.  But I do think 
> the HLR/VLR for 3GPP2 and 3GPP are in fact in the way of IP 
> PDN and not the right models to assume for context xfr, 
> complete handoff (even if done at layer 2) for a "FULL IP Network" 
> (seems ALL-IP has beome a marketing term that is at best confusing 
> to the public when looking at what it means). Likewise for HSS too.

Thinking about the 3GPP case, if one were to implement a 'pure' or
full IP RAN, you would have to have a connection to the HSS (HLR) / 
AAA server.  The HLR/HSS is essentially a subscriber database,
which is using MAP & DIAMETER currently for different function.
On inter-RAN handovers, the HSS doesn't need to be contacted &
the SGSN is handling the billing.  

Looking towards the future, I think that we will see most (if not all)
the HSS interfaces moving to DIAMETER.  I'm not going to hazard
a guess at this, as this will be up to the Operators, who are 
sometimes fickle ... but I don't think that it is unreasonable to
plan for this already.

Anyhow, I don't think that there will be such a thing as 
'full context transfer' because different radio technologies and
different service providers will support different things.  I'm
thinking that CT will be a framework to transport blobs of data 
around.

In 3G networks, header compression, qos & security might be the first 
interesting parameters to transport around, but that doesn't 
mean that there isn't more than that.

best regards,
John

---

From: Jim Bound <[email-masked]>
Date: Thu, 12 Apr 2001 10:54:04 -0400 (EDT)

Hi John,

I agree and full context may not be operationally possible.  My issues is
the req of SS7 gunk to speak with HSS and GTP in 3G.  I want them dead.
Sorry.  Of course the functions are needed.  I believe the function HSS
provides is almost all but elimnated with UMTS evolution too and I think
our seamoby thinking process should eliminate them in our resultant to
get to real running code and message to the public and telcos.

/jim

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Apr 2001 08:24:29 -0700 (PDT)

The main problem with faithfully reproducing an
HLR-like thing in IP is that the PSTN does not
make a distinction between data access and call
control. In fact, they are one and the same along
with all of the baggage that implies. The most
harmful implication of this architecture is that
call control is a pretty complicated beast, and at
its heart there is the requirement for very
complex user information in the form of some sort
of database. Generally speaking, defining and
transporting a complex database schema is an
extremely difficult thing to do and leads to
ossification of applications because it violates
the localization principal. In the wireless PSTN
that was pretty unavoidable given the way that
MSC's are connected together. IP, on the other
hand, is far more flexible: there is no reason
whatsover why I can't localize most of the
processing (user preferences, etc) and only export
the few bits and pieces as is absolutely necessary
(like, say, data access admission control, QoS
limits, etc).

What I sincerely hope we are not headed for -- and
I am afraid some people think we are -- is the
misuse of AAA as a database transport protocol for
*call control*, and CT as a means of transfering
call control information (HLR records) between SIP
proxies and/or UA's. That way leads to Global
Database Standards and service stagnation. It
would be far simpler to keep those sort of
relationships local between my UA and my home
proxies which already have a vested interest to
work with each other that the visited network does
not.

ObSEAMOBYRequirements: 

  o The protocol will only focus on transfering
    context that pertains to the reestablishment
    of equivalent data access on the CT peer.

	    Mike