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,
- Mobile IP (IETF)
- PSTN-wireless (PLMN)
- 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@CIG.MOT.COM] Sent: Tuesday, September 14, 1999 9:21 PM To: ITU-SG16@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:
- 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.
- 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.
- 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.
- 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@siemens.atea.be
-----Original Message----- From: Roberto Winkler [mailto:wnk@FUB.IT] Sent: Tuesday, September 14, 1999 10:34 AM To: TIPHON_WG7@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@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@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/
participants (1)
-
Edgar Martinez [1]