[Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first draft]]] ]

Roy, Radhika R, ALARC rrroy at ATT.COM
Fri Sep 17 12:55:37 EDT 1999


Hi Ed:

I appreciate your reply.

To support wireless handset in pure H.323 environment, we may think couple
of scenarios: 1. Wireless LAN,  2. H.323 Wireless handset (2a. WAU that is
NOT aware of H.323, 2b. WAU that is H.323-aware), and 3. (Non-H.323)
wireless handset interfacing an H.323 system via a IWF (GW).

In addition, we also have situations what mobile IP [IETF] is dealing with.
I would call this as scenario 4.

H.323 needs not to be aware of the radio link environment in scenarios 1 and
2a and, the H.323 mobility solution is independent of the lower link layer.
The general H.323 mobility problem needs to address intra-zone, inter-zone,
and inter-domain mobility management (change of point-of-attachment
[network, zone, domain]) before bringing the radio link issues. In this
context, we need to address (GK) discovery, registration, location updates,
call establishment, roaming, and handover in the H.323 layer. We will find
that H.323 needs extensions to support mobility.

In scenario 2b (I guess is that your contribution is primarily concerned
with) is a special case. That is, WAU is both H.323- and radio link-ware. As
a result, your contribution is proposing some extensions in H.323 to deal
with this situation. This is a very interesting situation that we need to
consider as a special case. What I would suggest that let us address this
situation in the light of cases 1, 2a, and 4 where the H.323 mobility
solution is provided without being aware of the radio link.

Then, we need to address scenario 4: For example, cellular-PSTN and H.323
Mobile system interworking. We have drafted this requirement as the
"INTERWORKING." In this context, we might see that H.323 may need more
extensions to support mobility.

That is, the radio traffic that you are concerned with may be dealt later
once we see that we have solved the mobility problems in the H.323 layer.
Then, we can apply it in some specific scenarios like the radio environment
as you have started (scenario 2b). The point is that the general solution
should also be capable to solve the problem that you have undertaken (if
needed some extensions can be made).

The question is: what would be the approach to solve the H.323 mobility in
the H.323 layer?

The paper of W. Liao published in the INFOCOM'99 conf provides some ideas.
This paper might be a good start to solve the mobility problem in the H.323
layer. However, we have to go a long way to meet all requirements of
mobility in H.323 beyond what has been discussed in this paper.

As APCs indicated, more contributions (e.g., AT&T, Lucent, others) are
coming in the upcoming Red Bank (Oct 18-22) conf.

With respect to the MC (not necessarily MCU) to provide the handoff, it can
be placed with the GK, GW, or other entities (e.g., WAU) as needed. This
might be an option for implementations. However, handoff will be in the
H.323 layer (Please also see the above paper). Then, we can translate this
into the corresponding radio layer. The handoff in the radio layer can be
implementation specific. In fact, we might need all functionalities that you
have proposed in the radio layer.

Again, your contributions have provided valuable insights to address H.323
mobility problems.

Hope this will help.

Best regards,
Radhika




> -----Original Message-----
> From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> Sent: Wednesday, September 15, 1999 10:44 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first
> draft]]]]
>
> Hi Roy,
>
> Just to take this off-line for the moment, but only for clarification.
>
> If we support a H.323 wireless handset in a pure H.323 environment. Where
> do
> you see the AIR interface access to the H.323 network? In the context
> of a pure IP mobile network without interworking. What I mean is do
> we only provide a BTS access to the network run all the radio traffic
> through
> the
> network.  Or do we provide something like a RAN (WAU)
> to handle the radio traffic on the edges?.
>
> The radio traffic that I been mentioning is not directly related to H.323
> call
> setup
> that is Mobile Terminal paging and all radio channel management functions.
>
> But, whether we use a BTS or WAU for wireless access to the IP
> network will greatly influence the way we do handovers in a pure
> IP network. This does not affect roaming.
>
> One suggestion you provided on handover was using the MCU,
> I could work with that. But something like the WAU can provide
> the MCU function in the edges between H.323 (MT to MT), or MT to PC.
> Since the only device that requires handover is the wireless
> Mobile Terminal (MT).
>
> Best Regards,
>
> Ed
>
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi Ed:
> >
> > I understand your approach. Your approach is an INTERWORKING between the
> > H.323 and PSTN-Wireless networking environment.
> >
> > First, we need to solve all mobility problems in the H.323 layer. Once
> we
> > solve H.323 mobility problems in a transport independent way, we can
> then
> > implement that solution in a special "INTERWORKING" environment: H.323
> > system (e.g., IP network) with an interface (e.g., WAU) to the
> PSTN-wireless
> > system.
> >
> > There are two steps: 1. Solve the mobility problems in H.323 layer
> > (Terminal, User, and Service Mobility) and 2. Implement the H.323
> mobility
> > problems in specific networking environments for "Interworking".
> >
> > The H.323 mobility problems solved in the H.323 layer should be
> applicable
> > for all circumstances. For example,
> >
> > 1. Mobile IP (IETF)
> > 2. PSTN-wireless (PLMN)
> > 3. Emerging mobile and wireless networks
> >
> > That is, the general H.323 mobility solution will also complement the
> > solution that you are proposing. There may be some differences in
> approach
> > that you are proposing, but it (H.323 mobility) will achieve the same
> > objectives what your contribution is up to. In fact, I welcome your
> > contribution because it has provided us valuable insights of the
> mobility
> > problems in the context of H.323 and PSTN-Wireless networking
> environment.
> >
> > Best regards,
> > Radhika
> >
> > > -----Original Message-----
> > > From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> > > Sent: Tuesday, September 14, 1999 9:21 PM
> > > To:   ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject:      Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first
> > > darft]]]]
> > >
> > > Thank you all for your comments.
> > >
> > > Roelands Marc wrote:
> > >
> > > > Hi all,
> > > >
> > > > I am struggling with some conceptual problems concerning the Annex-H
> > > > proposal of Edgar Martinez, feeling that this has some commonality
> with
> > > the
> > > > remarks of Roberto Winkler and Simon Binar on it. IMHO, the proposed
> > > > architecture, and especially the WAU and the GK, are mixing all
> kinds of
> > > > mobility related functionality in a single, strongly coupled,
> > > > do-it-all-in-H.323 layer, involving radio access up to H.323
> application
> > > > layer.
> > >
> > > I believe there is a clear separation of functional requirements
> between
> > > the
> > > radio control
> > > functions of the WAU, and the Network control and Mobility Management
> > > functions
> > > in the GK. Would it make everyone happy if we called WAU RAN? For
> network
> > > efficiency
> > > the WAU would handle all the Radio link resources at the edges,
> thereby
> > > preventing
> > > traffic overloading on the network.
> > >
> > > >
> > > >
> > > > Specifically, I have some difficulties with the following:
> > > >
> > > > 1. No clear division in terminal and user mobility aspects in the
> basic
> > > > H.323 architecture is taken as a starting point: shouldn't there be
> > > > specified somewhere in general, in conjunction with the H.323 set of
> > > > protocols, that IP addresses represent terminals in an IP network,
> and
> > > that
> > > > users can only be represented by logical names from a directory
> (i.e.
> > > > aliases), and whether an "endpoint" is a user or a terminal? If this
> is
> > > > decided on, the H.323 registration procedure is just what is needed
> to
> > > have
> > > > user mobility, by dynamically associating a logical user name with
> one
> > > or
> > > > multiple terminals upon user request. With terminals identified by
> IP
> > > > addresses, terminal mobility would further be strictly a network
> access
> > > > problem.
> > > >
> > > > 2. Annex-H is supposed to handle user and service mobility, so why
> would
> > > the
> > > > handover problem, as any other terminal mobility related problem, be
> > > handled
> > > > here instead of independently in Annex-I?
> > >
> > > In  the second day of the Ad-hoc SG-16 meeting, some of us discussed,
> > > the possibility of combining Annex H and I, if no contributions came
> > > in for Annex-I.
> > >
> > >
> > > >
> > > >
> > > > 3. Mobility is not an issue in H.323 alone, e.g. consider roaming
> and
> > > > handover for a connection-oriented data application, so why should
> it be
> > > > handled in H.323 on its own? Or put otherwise, is H.323 support
> really
> > > > required on a terminal in order to be able to roam, as a user of
> some
> > > > service, or as a terminal accessing a network?
> > >
> > > I specifically asked where do we focus, and was told to assume that
> > > there will be H.323 wireless sets. And focus only on H.323 terminals,
> > > to get the work started. And that other types of terminals would
> > > be handled separately.
> > >
> > > >
> > > >
> > > > 4. Although the proposal pays attention to the identification of
> several
> > > > degrees of locality for roaming and handover, solving all control
> issues
> > > > (radio access, IP-networking, etc.) in a single application layer
> still
> > > > leads to both resource sub-optimality and complexity. E.g. why
> should
> > > the
> > > > WAU be aware of anything having to do with (user) mobility
> management?
> > >
> > > I believe there is a misunderstanding the mobility management
> > > and services is handle by in the network e.g, GK.
> > > The Radio Resource management is at the edges which is aware
> > > of the terminals radio links.
> > >
> > > >
> > > >
> > > > Instead I would propose to use an approach of highly independent
> layers,
> > > > following good Internet tradition, and solving the problems as
> locally
> > > as
> > > > possible (both geographically and architecturally). Here's the
> layers I
> > > > think at least should be distinguished:
> > > >
> > > > - MAC level: terminal micro-mobility across radio cells, ethernet
> > > segments,
> > > > etc. can exist without any consciousness of this at the IP level
> (e.g.
> > > using
> > > > wireless LAN tunneling techniques);
> > > >
> > > > - IP network level: terminal macro-mobility across the Internet
> should
> > > be
> > > > invisible to higher layers (e.g. by means of Mobile IP v4 or v6 and
> the
> > > > improvements suggested for delay-sensitive traffic like RTP streams:
> > > Mobile
> > > > IP HAWAII, or draft-elmalki-mobileip-fast-handoffs-01 to name but a
> few;
> > > > note that route optimization is also worked on in this area);
> > > >
> > > > - "terminal real-time signaling" application level: the level where
> > > > telephony and MM signaling like H.323 can be placed (restricting GW
> and
> > > GK
> > > > functionality to strictly this level); here Annex-H might define
> > > transport
> > > > for additional parameters and vertical signaling, useful for serving
> the
> > > > "user services" application level (below); at this lowest
> application
> > > level
> > > > packet to circuit switched network boundaries may be crossed (cf.
> the
> > > > evolving traditional telephony networks vs. the Internet);
> > > >
> > > > - "user services" application level: user and service mobility takes
> > > place
> > > > here, making use of a network- (and H.323) independent naming system
> > > > (directories using e.g. DNS, LDAP schemas, etc.) and e.g. back-end
> > > services,
> > > > "behind" or "on top of" one or several GKs for realizing UM, user
> > > mobility
> > > > support for a larger scope than just H.323, smart user assistance,
> etc..
> > > >
> > > > This approach has not only the general advantage that every layer
> can
> > > evolve
> > > > technically independent of all others, it also has the specific
> > > advantage
> > > > that it realizes true consolidation of mobility for telephony and
> > > > traditional data applications.
> > > >
> > > > As a last point, it is not clear to me at which of these levels
> H.450
> > > would
> > > > belong.  As it is specified now it is on top of H.323, but suppose
> one
> > > would
> > > > like to adopt a service provision model where a user could subscribe
> to
> > > a
> > > > telephony-related service , wouldn't it be nice then to be able to
> offer
> > > > this across different telephony technologies (a bit like where IN
> aims
> > > at)?
> > > > A comparison to using a HTTP service control layer (Annex-K) might
> be
> > > > interesting here.
> > > >
> > > > I cannot imagine that these fundamental issues where not previously
> > > > discussed in ITU-T SG16 or Tiphon WG7, so if anyone can give me some
> > > > arguments why an approach as I tried to describe here could not be
> > > followed,
> > > > I would be glad to know about it.
> > >
> > > Your comments are very good and your suggestions are very applicable
> to
> > > what we are working on, but unless a contribution is presented to the
> > > proper
> > > groups e.g., ITS-sg16 q13/14 they would just fade away. ITU
> > > recommendations
> > > are contribution driven.
> > >
> > > Best Reagrds,
> > > Ed
> > >
> > > >
> > > >
> > > > Regards,
> > > > Marc Roelands
> > > > Siemens ICN Atea
> > > > Atealaan 34
> > > > B-2200 Herentals
> > > > Belgium
> > > > Tel.: +32 14253965
> > > > Fax:  +32 14222994
> > > > E-mail: marc.roelands at siemens.atea.be
> > > >
> > > > -----Original Message-----
> > > > From: Roberto Winkler [mailto:wnk at FUB.IT]
> > > > Sent: Tuesday, September 14, 1999 10:34 AM
> > > > To: TIPHON_WG7 at LIST.ETSI.FR
> > > > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first
> > > > darft]]]]
> > > >
> > > > Jin, Edgar,
> > > >
> > > > If I may try to give my 2 cents in this discussion, I think that the
> > > > problems/weakness of 3GPP considered systems (which Edgar is
> speaking
> > > > about) cannot match with the faults identified by Lucent's
> contribution,
> > > > which is focused on the unique issue of R99 terminal support in the
> All
> > > IP
> > > > R00 network. Considering these 3GPP contributions does not help in
> > > > understanding Edgar's point of view.
> > > > I have already sent a few e-mails to comment the proposed mobile
> H.323
> > > > architecture and would like to summarize here my view, hoping to get
> > > > reactions:
> > > > - the role and reason for being of WAU is unclear (as TIPHON is
> focused
> > > on
> > > > user and service mobility, why worry about the access medium ?)
> > > > - the redefinition of several RAS channel messages is confusing (why
> > > does
> > > > the RAS channel terminates at WAU ?)
> > > > - protocol stacks and interface definitions are missing from the
> > > picture.
> > > >
> > > > best regards
> > >
> > > --
> > > Edgar Martinez - Principal Staff Engineer
> > > Email mailto:martinze at cig.mot.com
> > > FAX 1-847-632-3145 - - Voice 1-847-632-5278
> > > 1501 West Shure Drive, Arlington Hgts. IL 60004
> > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
> > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/
>
> --
> Edgar Martinez - Principal Staff Engineer
> Email mailto:martinze at cig.mot.com
> FAX 1-847-632-3145 - - Voice 1-847-632-5278
> 1501 West Shure Drive, Arlington Hgts. IL 60004
> Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
> Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/



More information about the sg16-avd mailing list