[STDS-802-16] Issues for the usage of the Secondary managemen t connection
Peretz,
Subject of the discussion [in my perception] was: do we need new MAC level
arrangements to specify how "L3 multicast" traffic is delivered to the terminal.
I don't see why L3 multicast traffic cannot be delivered over regular multicast
MAC connection.
Agree, although one (L3 multicast advertisement) is signaling and regular
multicast MAC connection is slated for bearer, correct?
It is different from IP messages used to configure MAC/PHY at the terminal
[for which purpose Secondary Management connection was invented]. So if MIP host
functionality is collocated with the terminal, we can simply do nothing [in MAC
spec].
Secondary question [not related to the discussion directly] that I raised
was: where does IP multicast traffic of "management" nature
come from? It is highly undesirable at the air interface.
same view from the 3GPP2 camp.
Ronny pointed to MIP advertisements as an example. This example is valid
if MIP host functionality is collocated with the terminal (option A) and my
reaction was that there is another solution which does
not include delivery of multicast traffic over the air (option B: MIP Proxy
at BS). Generally speaking, partitioning of functions
supporting network level mobility [e.g. location of MIB host functionality]
is not in scope of 16e, so it should be another discussion.
For that another discussion, reference to legacy terminals is a valid
motivation for option A, but I don't find it sufficient for "option A only".
So MIP based terminals will be supported by option A and MIP proxy (option B)
will be used by terminals that do not support a MIP client.
For me integration with 3GPP networks is not a primary application for 802.16e.
but interoperability with with 802.11 may be a primary application where a user
is seamlessly moving from hot-spot to hot-zone.
Fortunately existing MAC tools provide for acceptable solution for both A and B.
Good. Will review this with you in San Antonio.
Vladimir