On
behalf of Mathieu Péresse
-----------
Hi
all,
sorry about not having taken part of the discussion
earlier...
Our General Ref Model (ref (1)) aims to be comprehensive and
simple, maybe at the expense of accuracy...
[Kalyan] It is true that if we keep it as simple as possible, we can't
add accuracy to it. That is the reason why
I
started with your model :-)
As Andrea says, this
model can be refined and adapted to show the real internals of one (or more)
specific technologies.
-> Answers from Kalyan's
comments:
- compared to orignial figure, the
management plane is substituted with "Media Independent L2 Transport".
Management plane is technology specific and is already covered by the
respective boxes
[MP] The reason why we put a "Management box" in the lower layers
"metabox", was because each technology has its own management plane, and
it
was too dificult to make it appear on the figure. So the layout means, the MIH
can interact with the data plane of each available technologies AND
with
the management plane of each technologies... There may be a better way to
represent that.
[Kalyan] Let me try to explain why we changed it a bit. If you refer to
our modified model, you can see that MIH is having interaction with 2 higher
layer
and
2 lower layer components. One higher layer and one lower layer component are
local entities of MIHF at UE. The other higher layer and other
lower
layer entities are used for communicating with MIHF at the other end
(in network for example) using transport mechanisms.
This
division may help us to say that all the local interactions could be carried
over SAPs and all the transport events could be carried out over
other
mechanisms (eg. socket communication for IP).
[MP] I think the Lower
Layer transport and Higher Layer Transport boxes are not needed this the
concept of "service transport" is carried in the black arrows (L3 transport)
and in the grey arrows (L2 transport).
[Kalyan] The point is that the connection between the MIHF and the
transport was not clear, will it be carried out by the technology
specific or
is
it an independent one. Therefore we tried to bring it to the front.
- The direction of ES, CS, IS locally
between MIHF and L2-Transport box is bidirectional. It is because, just like
higher layer, this transport is used to carry the information between the
peers. Since the L2-Transport box is situated in the terminal, it is local
communication between MIHF and itself
[MP] We wanted to
show that Events and Commands could be bidirectionnal, that means Commands
could also control higher layers and Events could be sent from an higher layer
to the MIH. This is going to be discusses in the comment resolution.
-> Answers from Ulises' comments:
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.
[MP] OK, but that justs
add complexity in the picture.
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.
[MP] That's a valid point. Maybe we
should clearly isolate the 3GPP/2 world from the 802 world in the
figure.
2) In ref (3) 3GPP and 3GPP2 communicates toward a MIH
Network Entity
using higher layer transport. This is not described in ref
(1)
[MP] In our diagram, the MIH Network Entity is located in the Upper
Layer box on the Network Side.
But we didn't made any assumption on the
kind of software entity that was running there.
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.
[MP] Yes
this is described, but indirectly: you go from the MIH on the Terminal side,
use the "local interactions"
white arrows to interact with higher layers
(for example a Media Independent Measurement Report you want to send using
layer 3),
then this message is transported using L3 (the black arrows) and
passed to the network side upper layers, who pass it to the MIH entity using
the "local interactions" (white arrows).
Regards,
Mathieu
On 11/14/05, Olvera-Hernandez, Ulises <Ulises.Olvera-Hernandez@interdigital.com>
wrote:
f.y.i
Ulises
-----Original
Message-----
From: Olvera-Hernandez, Ulises
Sent: Monday, November 14,
2005 3:38 PM
To: 'Koora Kalyan Com Bocholt'; STDS-802-21@listserv.ieee.org
Subject:
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
--
a+
thieum.