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

AW: [802.21] AW: [802.21] Comments on Ref. Model



Hello Andrea,

I too agree that the "general" model should be as simple as possible. The
intention
of our submission is to merge the ideas and to have a compact model which
can be
understood by all. In our contribution, we mentioned the technology specific
terms,
but they are ment to show interactions with technologies in general (thus
conisdered
as examples).

>The use of the General Reference Model figure as a template for the
following figures 
>was the simple rationale for the proposal that we submitted in Reference
>(2) of your exchange (actually barely mentioned in your discussion). Could
you 
>elaborate on your reasons to reject this approach?

We have considered it too and that is the reason we mentioned it . If you
look
at our contribution, there is transport layer which is the transport plane
from ref(2).

Regards,
Kalyan



-----Ursprüngliche Nachricht-----
Von: Andrea Francini [mailto:francini@lucent.com] 
Gesendet: Dienstag, 15. November 2005 17:44
An: STDS-802-21@listserv.ieee.org
Cc: Koora Kalyan Com Bocholt; ulises.olvera-hernandez@interdigital.com
Betreff: Re: [802.21] AW: [802.21] Comments on Ref. Model


Hello Kalyan and Ulises:

I have a general comment regarding the purpose of the "General MIH Reference
Model" figure (Figure 3 in Section 5.5 of the current draft):

Since Figure 3 describes the "General" model, I believe that any reference
to specific access technologies should be removed from it. Otherwise the
figure turns out to be a compact summary of the technology-specific figures
that follow in Sections 5.5.1 through 5.5.5., instead of working as a
template for their generation. In a technology-specific subsection, it would
be ideal to be able to replace the generic labels of the General Reference
Model (such as "Lower
Layers") with specific names based on the specific technology being
considered in the subsection (e.g., "LLC" in the MIH Reference Model for
802.3), without touching anything else.

The use of the General Reference Model figure as a template for the
following figures was the simple rationale for the proposal that we
submitted in Reference
(2) of your exchange (actually barely mentioned in your discussion). Could
you elaborate on your reasons to reject this approach?

Thank you,

Andrea


Koora Kalyan Com Bocholt wrote:
> 
> Hi Ulises,
> 
> at first thank your for the comments and for keeping up the 
> discusssion. Indeed there are many similarities between different 
> representations. The main background why we put up the figure is to 
> have a simple but effective and abstract figure.
> 
> >1) Ref (1) shows the transport of MIH services between Lower Layer at 
> >the network side and 802.21 MIH function as a local interface. 
> >However there are other cases to consider. For example, in ref (3) we 
> >show this scenario as the collocated case. However we also show that 
> >these services can transported over higher layer transport or layer 2 
> >as well. Furthermore in ref (3) we stress that at the network side 
> >there is no direct
> communication
> >between 3GPP/3GPP2 lower layers and the MIH function.
> 
> In Ref(3) you have elaborated the network side too whereas in Ref(1) 
> it is abstract. I feel Ref(3) is subset of Ref(1). Further, there is a 
> new entity called "MIH Network Entity" apart from MIHF. The function 
> of this entity is not clear to me.
> 
> >2) In ref (3) 3GPP and 3GPP2 communicates toward a MIH Network Entity 
> >using
> 
> >higher layer transport. This is not described in ref (1)
> 
> Infact it is there, MIHF communicating with Upper Layers. And upper 
> layer is communicating with MIHF peer over higher layer protocols.
> 
> >3) However the scenario where just a L3 interface is used to 
> >communicate between two MIH peers is not described. This is depicted 
> >in ref (3) as double-headed arrow that goes from MIH to MIH simply 
> >using a Higher Layer Transport
> 
> Yes, that is the reason we proposed to add it in our reference model.
> 
> >4)...Here I have a comment and a question: If it is already included 
> >in the box, why would we need to specify a L2 transport? ...
> 
> The reason behind this is to keep the mechanism of L2 transport 
> independent of media (as in Ref(2)). An example to this is typical 
> Ethernet frame. Though it is 802.3, it can be carried over different 
> medias like 802.xx. We can also think here of PPP, ATM or what else. 
> The representation is some what similar to stating "higher layer", 
> here too we are not mentioning whether it is TCP or UDP or some other 
> protocol. Presently, it is clear to all it will be IP.
> 
> >...Also from ref (1) the common layer 2 transport (or lower layer) 
> >depicted
> 
> >in the figure indicates that both 3GPP/3GPP2 and 802 components used 
> >the same L2 transport, this is not accurate...
> 
> As I mentioned, the intention was to put an abstract figure which 
> tries to cover all the concepts. Again, the model you mentioned can be 
> seen as sub-set of the it.
> 
> >...1) Over the management plane (e.g.,through the introduction of a 
> >new an action frame format), and 2) Over the Data Plane using LSAP 
> >(through the introduction of a new ethertype).....
> 
> >From my understanding both are layer 2.
> 
> I have noted that you have changed the 802-Interface at client side in 
> the doc attached to the email. I like it better than the previous 
> diagramm :-) The point which needs a clarification from my side is, 
> how MIHF communicates
> 
> with MGMT (over SAPs or over Transport protocol). This question is 
> also valid for all local interactions.
> 
> With best regards,
> Kalyan
> 
> -----Ursprüngliche Nachricht-----
> Von: Olvera-Hernandez, Ulises 
> [mailto:Ulises.Olvera-Hernandez@InterDigital.com]
> Gesendet: Montag, 14. November 2005 21:39
> An: Koora Kalyan Com Bocholt; STDS-802-21@listserv.ieee.org
> Betreff: RE: [802.21] Comments on Ref. Model
> 
> Hi Kalyan,
> 
> I noticed that in the introduction you referred to two contributions 
> 21-05-0413....(let us call it ref (1)) and 21-05-0423..-(let us call 
> it ref
> (2)) where as I understand you based the document for discussion. I would
> like us to consider also contribution
> "21-05-0425-00-0000-InterDigital3GPPAmendments" as it is addressing the
same
> issue (let us call it reference (3) for the purpose of this discussion).
If
> we look at section 5.1.1 from ref(3), the proposed reference model is
> fundamentally the same reference model that we agree to use for our
> presentations to both 3GPP and 3GPP2. I find that this model looks quite
> similar to the one you are proposing except for the
> following:
> 
> 1) Ref (1) shows the transport of MIH services between Lower Layer at 
> the network side and 802.21 MIH function as a local interface. However 
> there are other cases to consider. For example, in ref (3) we show 
> this scenario as the collocated case. However we also show that these 
> services can transported over higher layer transport or layer 2 as 
> well. Furthermore in ref (3) we stress that at the network side there 
> is no direct communication between 3GPP/3GPP2 lower layers and the MIH 
> function.
> 
> 2) In ref (3) 3GPP and 3GPP2 communicates toward a MIH Network Entity 
> using higher layer transport. This is not described in ref (1)
> 
> 3) Ref (1) shows communication from MIH function in the client station 
> to its peer at the Network through a higher layer transport. This is 
> consistent with ref (3). Then the interface goes through what it is 
> referred to as 'Higher Layer' before it communicates with the MIH 
> peer. This is very similar to ref (3) for case where the interface 
> goes through the MIH Network Entity (e.g., the Upper Layer being part 
> of the MIH Network Entity). However the scenario where just a L3 
> interface is used to communicate between two MIH peers is not 
> described. This is depicted in ref (3) as double-headed arrow that 
> goes from MIH to MIH simply using a Higher Layer Transport.
> 
> 4) You also indicate that the management plane has been replaced by 
> what it is referred to as L2 transport and that the Management Plane 
> is technology specific and therefore it is already covered in the 
> corresponding box. Here I have a comment and a question: If it is 
> already included in the box, why would we need to specify a L2 
> transport? Also from ref (1) the common layer 2 transport (or lower
> layer) depicted in the figure indicates that both 3GPP/3GPP2 and 802 
> components used the same L2 transport, this is not accurate. 
> Furthermore, we have discussed two different mechanisms to send MIH 
> information both peer to peer and locally: 1) Over the management 
> plane (e.g.,through the introduction of a new an action frame format), 
> and 2) Over the Data Plane using LSAP (through the introduction of a 
> new ethertype). It is not obvious how the "Lower layer Transport" 
> transport handles these two mechanism, in particular considering that 
> they interface between the LLT and the MIH function is depicted as a 
> local interface. This might be accurate for locally generated events 
> but not for peer to peer remote events.
> 
> I have taken some of the concepts that you introduce and they are now 
> reflected in a newer version of fig.3 from ref (3). I added both 
> snippets from this e-mail and fig.3 from ref (3) to your document and 
> I'm sending it back attached to this e-mail. I enabled change tracking 
> within the document, although changes are quite obvious. Comments are 
> appreciated.
> 
> Regards,
> Ulises
> 
> -----Original Message-----
> From: Koora Kalyan Com Bocholt [mailto:kalyan.koora@SIEMENS.COM]
> Sent: Thursday, November 10, 2005 8:32 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: [802.21] Comments on Ref. Model
> 
> Hello all,
> after going through couple of presentations/comments, we had some 
> internal discussions on the reference model. Please find our 
> point-of-view in the attached document. This can be discussed in 
> detail later in the IEEE meetings or on the reflector.
> 
> Awaiting your comments,
> with regards,
> Kalyan