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

[Roy, Radhika R, ALARC]

Hi Everyone:

I fully agree with Roelands Marc's comments (along with Roberto Winkler and
Simon Binar) that Edgar Martinez's proposal is "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."

H.323 mobility problems needs to be addressed in H.323 layer. That is, H.323
is independent of the underlying transport network (e.g., IP, ATM, MAC,
radio-access, wireless LAN, etc.). However, H.323 solutions (fixed or
mobile) can be implemented over any packet-based network (PBN). In this
context , we also produced a terms of reference document (TD-34) in the last
SG!6 Q.13 Berlin meeting.

Now Roelands's comments also clarify more how H.323 mobility problems need
to be addressed. I support almost all the points mentioned by Roelands.
Please also see my comments enclosed below.

Best regards,
Radhika R. Roy
AT&T
+ 1 732 370 2542
rrroy at att.com

PS: Once the general mobility problems are solved in the H.323 layer, a
specific implementation what Edgar Martinez has proposed in the context of
the PSTN-radio-access (e.g., WAU) can be addressed very easily (e.g.,
wireless-PSTN-[WAU]-H.323 [ e.g., IP Network] Mobility).

> -----Original Message-----
> From: Roelands Marc [SMTP:Marc.Roelands at SIEMENS.ATEA.BE]
> Sent: Tuesday, September 14, 1999 10:17 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first
> darft]]] ]
>
> 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.
        [Roy, Radhika R]  I fully agree with Roelands Marc.

> 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.
        [Roy, Radhika R]  Yes, Edgar Martinez's proposal does not separate
clearly  between the terminal and user mobility. We need to solve problems
step-by-step as specified in the terms of reference document (TD-34): 1.
Terminal Mobility, 2. User Mobility, and 3. Service Mobility.

> 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?
        [Roy, Radhika R]  Per last SG16 Q.13 Berlin meeting, Annex H will
deal with all: 1. Terminal Mobility, 2. User Mobility, and 3. Service
Mobility.

> 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?
        [Roy, Radhika R]  H.323 needs to handle roaming and handover in the
H.323 layer as well if this is NOT transparent to the H.323 layer. For
example, a handover to a "new" connection may cause to release resources to
the "old" connection by the GK. The multipoint controller (MC) that has the
capability to create new connections while terminating the old one via ad
hoc conferencing can be used to provide handover in the H.323 layer (In
turn, this may also be coordinated for implementation of the handover in the
physical [wireless] layer).
>
> 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?
        [Roy, Radhika R]  Yes, we need to solve mobility problems in H.323
layer in a transport independent way (however, specific implementations can
be offered at the radio access layer, IP network layer, etc.).


> 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);
        [Roy, Radhika R]  H.323 mobility solutions shall be transparent to
the lower transport layers.

> - 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);
>
        [Roy, Radhika R]  Yes, I agree.

> - "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);
        [Roy, Radhika R]  Annex H will also specify 'Interworking" between
H.323 and non-H.323 (e.g., wireless-PSTN-H.323 [IP]) system. However, in an
H.323 system, both GW and GK will be using the H.323 protocol.

> - "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..
        [Roy, Radhika R]  H.323 service mobility needs more careful
considerations because H.323 is yet to standardize backend services
protocol.

> 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.
        [Roy, Radhika R]  TD-09 and TD-34 clearly indicate how H.323
mobility problems need to addressed. Contributions are solicited by SG16.

> 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.
        [Roy, Radhika R]  It is clearly an issue. We need to address this as
we go forward.

> 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.
        [Roy, Radhika R]  All issues were discussed in the last SG16 Berlin
meeting. Contributions are solicited (Edger Marinez's proposal is one such
contribution. More contributions are expected in this area).


> 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