Video Conference Sept 12-15, 1999

[videoconf at nfmail.com]

Roberto,

Tell me more...

Roberto Winkler wrote:

> Edgar, all
>
> thanks for the reply, but I have some more....
>
> Again, with reference to the WAU, whose capabilities and role I still don't
> quite understand, I don't see how can it 'intercept' messages belonging to
> the RAS channel (i.e. addressed to or coming from the Gatekeeper), without
> a true redefinition of the whole system.

I disagreed with your last statement " without
a true redefinition of the whole system". If we designed
a system that needs to be redefined everytime we provide
a new service then we did something wrong. It may be true for
some other systems you are looking at, like G _ _ _ or 3_ _ _.

The Radio sub-system WAU is just a (GW) which provides
the Radio Control Function (RCF) and bearer connection. It maintains
the state of the radio links connections, for a given call, between the a
user agent/terminal agent and the network as perceived by the RCF.
It establishes, maintains, modifies and releases a radio and fixed line
bearer connection between a mobile and the network.

The MT to WAU relationship we hope to re-use the Radio technology
defined by UMTS/3GPP. The MT to H.323 IP relationship we plan
to re-use the H.323 elements and the TIPHON system.

>
> But, most important, I think that Mr. Martinez's contribution cannot be
> appreciated in its entirety without a clear and precise description of the
> functionalities and capabilities of the blocks in the proposed reference
> architecture, which I feel is missing from the picture as it is now. As a
> matter of example, with reference to the WAU, the following items should be
> clarified:
> - capabilities and functions
> - protocol stack
> - differences to other Gateways
> - differences to Gatekeepers

All of the above is already available in one form or another,
it has been presented in other contributions I had provided
to ITU and WG7. The contributions can modified specificity
for the new H.323 Annex H 'user and services mobility"
once the framework is agreed on. Plus Annex H it is open
for contributions and you or anyone are welcome to
provide some.

>
>
> To my humble opinion, this should be the first task to be accomplished,
> before aiming at message flows.

We need both and will have both, but this is the same old  problem that
network architects face and everyone has their own opinion. I rather first
know from a high level, what we are trying to provide before jumping
in to details. Have you ever been asked to "show me a call flow or block
diagarm" what you are trying to do? Call flows without the intended protocols
message to be used,  in a specific system makes little sense to me.

Regards,
Ed

>
>
> Thanks very much and best regards everybody
>
>   Roberto Winkler
>
> Roberto Winkler
> Senior Researcher
> Fondazione Ugo Bordoni
> Via B. Castiglione, 59
> 00142 Rome Italy
>
> tel +39 0654803411
> fax. +39 0654804404
> e-mail wnk at fub.it
>
> -------------------------------------------------------------------
> Mail archive for TIPHON_WG7  can be browsed at the following url :
>
>             http://www.etsi.org/tiphon/mailing.htm
> -------------------------------------------------------------------

-- Forwarded --
Subject:
Re: H.323 mobility draft
 Date: Mon, 06 Sep 1999 10:54:19 -0400
From:  "Edgar Martinez [1]" <martinze at cig.mot.com>
 Organization: NSS-NAT
To: Roberto Winkler <wnk at FUB.IT>
CC: TIPHON_WG7 at LIST.ETSI.FR
References: 1

Dear Roberto,

Thank you for your comments.

Responses follow:

Roberto Winkler wrote:

> hello
>  I have the following basic questions about the document in subject:
>
> - what does IMIS mean ?

ASN.1 data type IMIS in section  8.5 and the
call flows is a typo it will be correct.

IMSI ::= TBCD-STRING (SIZE (3..8))

imsi     IMIS OPTIONAL (typo in document)
should be
imsi     IMSI OPTIONAL (correction)

>
> - I have the impression that many message flows in section 8 break the
> usual RAS channel definition, because messages that in the 'original' H.323
> are exchanged between endpoint and gatekeeper are now intercepted by WAU,
> whose role (and mapping to UMTS architecture) is really unclear to me.

> As
> an example, there is the GRQ/GCF exchange in 8.2.1.2
> and ARQ/ACF exchanged between WAU and GK in 8.3.1.1.

The WAU is not that much different that a MCU or Gateway which
may register a single Transport Address or multiple Transport Addresses.
To the GateKeeper the WAU will look like (GW) end-point. Of course of we want
to support
wireless mobility some tweets will have to be done in the H.323  procedures to
handle
H.323 (MT) wireless  or Fixed Terminal mobility. But, it should not beak the
under lining core set procedures for basic H.323.

>

Text from H.323v3 section 7.2.2
http://standard.pictel.com/ftp/avc-site/Incoming/

7.2.2 Endpoint registration:

Registration is the process by which an endpoint joins a Zone, and
informs the Gatekeeper of its Transport Address and alias addresses.
As part of their configuration process, all endpoints shall register with
the Gatekeeper identified through the discovery process. Registration shall
occur
before any calls are attempted and may occur periodically as necessary
(for example, at endpoint power-up).

A Gateway or MCU may register a single Transport Address or multiple
Transport Addresses. The use of multiple Transport Addresses may simplify
the routing of calls to specific ports.

An endpoint shall send a Registration Request (RRQ) to a Gatekeeper.
This is sent to the Gatekeeper's RAS Channel Transport Address. The endpoint
has the Network Address of the Gatekeeper from the Gatekeeper discovery process

and uses the well-known RAS Channel TSAP Identifier. The Gatekeeper shall
respond with either a Registration Confirmation (RCF) or a Registration Reject
(RRJ).
See Figure 8. An endpoint shall only register with a single Gatekeeper.

The RRQ may be repeated periodically (i.e. at terminal power-up), so the
Gatekeeper
shall be able to handle multiple requests from the same endpoint. If a
Gatekeeper receives
an RRQ having the same alias address and the same Transport Address as an
active
registration previous RRQ, it shall respond with RCF.

Snip...

Regards,
Ed

>

>
> Clarifications are appreciated
>
> best regards
>
>    Roberto Winkler
>
> Roberto Winkler
> Senior Researcher
> Fondazione Ugo Bordoni
> Via B. Castiglione, 59
> 00142 Rome Italy
>
> tel +39 0654803411
> fax. +39 0654804404
> e-mail wnk at fub.it
>
> -------------------------------------------------------------------
> Mail archive for TIPHON_WG7  can be browsed at the following url :
>
>             http://www.etsi.org/tiphon/mailing.htm
> -------------------------------------------------------------------

--
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/