Hi, Laurent and SG16 Members:

In the last H.323 Ad Hoc Mobility conference call, I promised that I'd provide comments on Alcatel's MTD-107b via email. I see that Alcatel wants some modifications on the editor's document. I feel that it is the editorial comments and, it is better to address via emails. (The editor of Annex H could also deal with this directly while letting us know via email, and we can also provide our inputs if Alcatel send it to the editor.)

My comments have been summarized in following categories: 1. To add/modify new texts, 2. To take out some architectural functional entities that have already been agreed upon (some of them may be only place holder for now because the actual solution decides how to deal with these entities) and 3. To add some new functional entities per Alcatel's proposal that has not been supported by the contribution providing solutions.

For items like category 1, we can easily decide. First of all, we are not too concerned to add texts now because the actual solution will drive how to augment the texts better. It would be better NOT to spend too much time to augment the text.

For items like category 2, let me add this: we made the decision in the last Red Bank meeting after a long discussion. These items have been put as place holders only. If we want to change now, it will put us back where we had been before the last Red Bank meeting. My question is: Can we not differ until such time we agree on a common solution?

For items like category 3, I'd propose that let us see contributions in support of these functional entities before we decide why we need it unless it is obvious that we all agree that we need these entities.

Let me go for each item of the contribution.

We all agree, like Alcatel, that the H.323 mobility solution will be independent of the radio link layer. I also added that the solution will not only be independent of the radio link layer, but it should also be independent of layers that reside under the H.323 layer: Transport layer, Network layer, Link Layer, and MAC layer.

If the proposed solution does not satisfy the above requirements, we will definitely not accept the solution. We have not proposed any solution yet. We have used some terminologies only and some of these terminologies may have "abstraction" of the lower layer. Please note that when I say an "abstraction," it only mean that an "event" may be initiated at the H.323 layer. That does not mean that the H.323 mobility layer will do the job of the lower layer if the lower layer is able to do perform this function. If the lower layer can perform this function, the H.323 layer will simply delicate that function to the lower layer generating an event. (A similar analogy is the multicasting: Application layer [T.125's MCS], Network Layer [IP multicast], and Link Layer [ATM multicast].)

Section 5.1:

Let editor decide whether the text proposed should be used at this stage. Even if the editor agrees, I'd request not to use "possible radio," because this is also true for all lower layers including the radio link.

"Location Area Identity," "Temporary Identity," and "Paging Mechanism" cannot be taken out because of the reason explained in category 2. If we keep it as place holder, what is the harm? We can always re-visit it if we do not support these functions through the proposed solution.

Regarding "Paging," I have explained that a GK may only use the LRQ message to resolve the address. However, the actual paging may be "implemented" by any functional entity in the radio link layer (pl. see a functional entity in the IMT-2000/3GPP architecture). In reality, the GK will rely on the radio link layer entity to do job for "paging." At best the GK will be a paging-aware entity to deal with the mobile wireless environment.

I have no problem to agree with the text if other people agree. The text associated with the LRQ message that you have proposed as if we have decided how the LRQ message will be used by the GK. In fact, AT&T's contribution proposes a similar mechanism and I am waiting to see that people need to agree on the solution that has been proposed . In this respect, your text falls into category 3.

Section 6:

Why do you want to add such restrictive texts at this stage? It will create more controversy than solving the problem. I'd suggest the same is true for H.323 in general that the H.323 layer solution is independent of the lower layer. This global statement itself is good enough to take care of all text that you have proposed. More importantly, the texts suggest as if we know the solution. I feel that we have not come to this stage yet to make statements like this. For example, the call flows of the solution that we all agree will provide us all those steps that you are proposing from steps 1 through 6.

I'd propose not to add the suggested text now.

Architectural Model:

I'd propose not to add this now because it is applicable when the interworking between the H.323 (mobile/non-mobile) and non-H.323 (mobile/non-mobile) system will be addressed. When the H.323 mobility solution will be applied in the context of IMT-2000/3GPP networking environment, we will definitely address this particular architecture.

Rather, I'd propose to use the architectural reference diagram agreed upon by all members (Nokia has distributed that diagram to all SG16 members).

Thanks to you for providing more insights how the H.323 mobility architecture should be independent of the lower layers.

Best regards, Radhika R. Roy, AT&T +1 732 420 1580 rrroy@att.com