Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Comm Model update



fyi
This has some valid questions/response w.r.t comm. model that others may
also have.

BR,
-Vivek

-----Original Message-----
From: Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com] 
Sent: Monday, October 17, 2005 9:50 AM
To: Gupta, Vivek G
Cc: francini@LUCENT.COM; Peretz Feder; subir@research.telcordia.com
Subject: Re: Please review and comment on the revised comm model
contribution

Hi, Vivek,

Thanks for the review and comments. Please see my response in-line.

Gupta, Vivek G wrote:

>  
> 
> There are several questions here and not necessarily all because of
the 
> updates. But having an answer may help with the telecom tomorrow and 
> future progress.
> 
>  
> 
> 1] What is the purpose of having this comm. model in draft?
> 
> What are the next set of activities if any related to this and what is

> the expected impact of that on the draft?
> 

The purpose is simple - to give a top level view of all the 
communication relationship of 802.21 entities. We do not have this top 
level view in the current draft and adding it can enhance the 
readability of the document. This top level model can also provide a 
level of consistency and guidance to the subsequent service specific 
architecture diagrams if they can be derived from a common top level 
model. The next steps would be to insert this into the draft and 
continue enhancing the description text to make it more accurate (as 
your following suggestions/questions do).

> 
> 2] MIH Point of Service: A network-side counterpart of an MIH-enabled
UE 
> for the exchange of MIH messages:
> 
> A UE may be connected to multiple access networks (L2 links) at any 
> time. Will there be only a single instance of MIH PoS across all 
> networks at any time? If yes, then Why?
> 
> If not then what is the significance/difference between MIH PoS and
just 
> MIH Function?

For conciseness, the model shows only one UE and one network. But I 
believe in practice a UE is free to connect to as many networks as its 
developer wants. In such a case, there can be a MIH PoS in each of the 
connected networks. Even within a single network, the UE may talks to 
more than one MIH on the network side (e.g., a UE getting ES/CS from a 
MIH on its PoA while at the same time getting some IS from a server 
inside the network. Here both the MIH on the PoA and the MIH on the IS 
server would be qualified logically as a MIH PoS).

> 
> Is the use of term "counterpart" accurate here? Can we use something 
> like "instance"? "A network side instance of MIH-Function for exchange

> of messages with MIH-Function enabled UE"...
> 

Good question. I will let Andrea to respond.


> 
> 3]MIH pairing:
> 
> Can there be multiple MIH pairings for a single UE at any given time?
> 
> What about communication between other (non UE type) MIH Function
entities?
> 
> Why do we not need to define pairing here...?
> 

We can remove the pairing def here. It is not used in the model
description.

> 
> 4] "The UE exchanges MIH information with MIH PoS's. Generally, the
MIH 
> PoS resides at an interface on a network node with which the MIH 
> function of the node is registered for MIH services. An MIH PoS may or

> may not be co-located with a PoA on the same (L2) interface"
> 
>  
> 
> a] Is MIH-Function required/mandated to be located at any PoA?

No. There can be PoAs with no MIH on it.

> 
> b] For L2 communication between UE and network, should MIH-Function be

> located at PoA?

Yes, but not mandated (e.g., a MIH enabled UE moves into a legacy
network).

> 
> c] For L2 communication between UE and PoA are there any specific 
> requirements w.r.t MIH-Function on PoA or is everything optional?

Not mandated, but without a MIH on the PoA, the MIH services the UE can 
get may become severely limited. But I believe the case should be
allowed.

> 
> d] For a UE connected through a single access network (L2) is it 
> possible to have MIH PoS in PoA and another MIH PoS somewhere else in 
> network for L3 communication?
> 

Yes, I believe so. See the example I gave above.

> 
> 5] "It can happen that an interface on an MIH-capable node (i.e., a
node 
> that contains an MIH function instance) does not host an MIH PoS
because 
> the local MIH function is not registered with that interface for MIH 
> support. However, an MIH PoS may still be found in the same network
node 
> at a different interface"
> 
> What is meant by registering local MIH Function with that interface?
How 
> is this done? Why is this required?
> 

E.g., a node has 3 interfaces - 802.11, 802.16, and 802.3. But by design

the 802.3 is only there for sys admin/OMA purposes while only the .11 
and .16 interfaces are for MIH-enabled wireless services. In other 
words, this is just to simply state that "not every interfaces on a 
MIH-enabled box will automatically be part of the 802.21 scope".

> 
> 6] "The UE may use L2 transport for exchanging MIH information with an

> MIH PoS that is co-located with a PoA."
> 
> This seems to imply that for L2 MIH communication between UE and PoA, 
> the MIH-Function must be co-located with PoA.
> 
> Maybe we can be explicit about this if this is always true.
> 

Most likely this is true, but I am not sure this is absolutely true or 
we want to have a restriction to make it always true. Open for
suggestions.

> 
> 7] The UE must use L3 transport for exchanging MIH information with an

> MIH PoS that is not co-located with a PoA.
> 
> Is it possible for PoA to have something like proxy MIH or relay MIH
or 
> something else that knows how to communicate with real MIH PoS and
thus 
> still allow for L2 communication or are these possibilities too 
> far-fetched and must be rejected.
> 
> (I agree with above in principle but having an answer may help in 
> convincing others...)
> 

This is definitely allowed but in such a case, the proxy MIH or relay 
MIH would be called the MIH PoS and the real MIH would not logically 
qualify as a PoS.

> 
> 8] Communication Model: Interface R1:
> 
> R1 can be over either L2 or L3? Should we really mention both L2 and
L3 
> here in this case? Is one preferable over another...when?
> 
> Do we want to give any general guidelines as to which one to pick or 
> just leave this as is?
> 
> IMO this gives rise to some confusion in people's minds as to what to 
> use and some guidelines may help.
> 

L2 is preferred in my view for obvious engineering reasons, but I can't 
rule out that others may have some reason to use L3 here. IMO, a top 
level model should be as accommodating as possible to different views as

long as they are not harmful.

> 
> 9] Can there be multiple instances of R3 at any given time for a
single 
> UE (with single L2 connection or multiple L2s)?
> 

If a particular design requires, why not.

>  
> 
> 10] Which ones out of R1, R2, R3, R4 and R5 are in scope of 802.21 and

> which not?
> 
> Should we include some kind of a table specifying that?
> 

Good idea. Right now I can't say any one of them is absolutely out of 
scope. We can at least create a place holder for such a table at the 
moment and fill it out once we reach a group agreement on an item.

> 
> 11]  Made minor changes to below definitions:
> 
>  Link: Communication medium for the exchange of messages between 
> adjacent L2 nodes.
> 
>  Point of Attachment (PoA): Network-side endpoint of link with UE as
the 
> other endpoint.
> 

Ok.

regards,
-Qiaobing

>  
> 
>  
> 
> Thanx much
> 
> -Vivek
> 
>  
> 
> -----Original Message-----
> From: Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com]
> Sent: Friday, October 14, 2005 4:01 PM
> To: francini@LUCENT.COM; Peretz Feder; Gupta, Vivek G; 
> subir@research.telcordia.com
> Subject: Please review and comment on the revised comm model
contribution
> 
>  
> 
> Hi, co-contributors,
> 
>  
> 
> Please see the revised comm model document attached. I've tried to
> 
> re-draw the figure and re-word the text using the new definitions from
> 
> Andrea. Please provide your comments ASAP. Once we agree on the
changes
> 
> I would like to send the updated document out to the 802.21 list
before
> 
> the tele-conf on 10/18.
> 
>  
> 
> regards,
> 
> -Qiaobing
>