Should we Break H.323 Model for Mobility?

[Tom-PT Taylor]

Nothing in H.323 prevents the GK from consulting other functional entities
when necessary to track the location of a user.  I have been following the
discussion from afar, but my impression is that (1) it is proposed to
distinguish a domain-specific Location Function in support of user mobility
and (2) the work on mobility is partly about how the GK interacts with this
function.  It makes sense that the technology of mobile communications --
really just a transport issue from the point of view of H.323 -- should be
treated separately from the technology of multipoint multimedia
communications, which is what H.323 was designed for.  Moreover, the
architectural distinction is useful to avoid undue restriction of the
possible business models -- the mobility service provider may well be
different from the multimedia communications service provider.

> -----Original Message-----
> From: Roy, Radhika R, ALARC [SMTP:rrroy at ATT.COM]
> Sent: Friday, April 14, 2000 10:48 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Should we Break H.323 Model for Mobility?
>
> Hi, Everyone:
>
> H.323 has some definite architectural notion such as terminal, GK, GW, MCU
> and(MC, MP). One of the fundamental corner stones is the GK. The H.323
> entities (e.g., terminals, GWs) register with the GK. A GK manages a zone
> with the information of all registered users along with other functions
> (e.g., bandwidth, resource management, etc).
>
> The "registration" with the GK is the fundamental corner stone of H.323
> where an association is made by each user. That is, a GK becomes the basic
> source to have the information related to each user.
>
> H.323 mobility protocol MUST also follow the same H.323 architectural
> concept. If this basic notion is not maintained, it breaks the basic
> foundation of H.323.
>
> It appears that H.323 mobility likes to define additional databases like
> VLFs and HLFs that will store the information related to the mobile users.
> These databases are supposed to help the function of a GK in order to
> manage
> the mobility related information.
>
> If people think that an H.323 will be able to register with a VLF
> directly,
> does it not mean we are by-passing the basic foundation of H.323 model?
> Does
> it not opening the entirely a new set of problems in H.323? It will create
> a
> parallel architecture like GK in H.323 what is not needed at all because
> solutions have provided that are consistent with H.323 model and there is
> no
> need to do this. We probably have to do all over again what we have done
> for
> the GKs and BEs. We inviting unnecessary problems that are yet to imagine
> where we may end up with. Why do we need to do that if one can do this
> using
> the consistent H.323 model of GK?
>
> In another situation, we have to go step-by-step. First intra-zone, then
> inter-zone, and last of all inter-domain. Contributions are there to
> address
> those problems.
>
> The mobile users that move between cells, those cells are expected
> primarily
> remain the control of a given GK (in some cases it may be two GKs). These
> scenarios mostly seem to be intra-zone and inter-zone and may involve a
> single service provider. Of course, there will also be the calls between
> the
> two adm domains of two service providers.
>
> More importantly, solutions are inter-dependent. That is, we cannot
> address
> the problems of inter-zone without knowing the intra-zone. In the same
> token, we cannot address the inter-domain problems without knowing the
> inter-zone problem. Contributions are there. Let us proceed accordingly.
>
> Last of all, I am reminding the mess that we have made in Annex G. Now
> people are hungry to use the more powerful and efficient Annex G messages
> between the GKs. Contributions were brought to do this, but the proposals
> had been rejected by a very few. Who is suffering?
>
> Best regards,
> Radhika R. Roy
> AT&T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000415/e46e88c9/attachment-0001.htm>