|
Vladimir,
Thanks for your quick response.
My comments are inlined below under
[YONG2].
I think that we can harmonize together.
If there is another company to have another comments
on it, please let us know.
Thanks,
Yong
----- Original Message -----
Sent: Tuesday, August 17, 2004 5:55 AM
Subject: RE: [STDS-802-16-MOBILE]
[Harmonization] MBS Harmonization
Yong,
Thanks for your letter.
See my comments
below,marked as [VY].
Vladimir >
-----Original Message----- > From: Yong Chang [ mailto:yongchang@samsung.com]
> Sent: Monday, August 16, 2004 3:17 AM
> To: Vladimir
Yanover; Roger B. Marks
> Cc: stds-802-16@ieee.org
> Subject:
Re: [STDS-802-16-MOBILE] [Harmonization] MBS
Harmonization
>
>
> Dear Vladimir and all,
>
>
First of all, I want to say sorry for not asking you before.
> But, the
authors shown in the initial drafts are folks who are having
> comments
on MBS issue now.
> I had tried to tell who is involved in making a
harmonization
> on MBS now.
> When we upload the next version, we
will strike out your name from the
> Harmonization
Draft.
>
> Second of all, as I told in Harmonization Conference
calls,
> we have still open issues in MBS now.
>
> Last of
all, my technical comments are inline below with [YONG]
>
> I hope
to understand what we are going to do.
>
> Thanks,
>
>
Yong Chang
>
>
> ----- Original Message -----
> From:
"Vladimir Yanover" <vladimir.yanover@alvarion.com>
> To: "Roger B.
Marks" <r.b.marks@ieee.org>
> Cc:
<stds-802-16@ieee.org>
> Sent: Sunday, August 15, 2004 8:31
PM
> Subject: RE: [STDS-802-16-MOBILE] [Harmonization] MBS
Harmonization
>
>
> > Thanks, I am completely
satisfied
> > Vladimir
> >
> > > -----Original
Message-----
> > > From: Roger B. Marks [mailto:r.b.marks@ieee.org]
>
> > Sent: Friday, August 13, 2004 5:00 PM
> > > To: Vladimir
Yanover
> > > Cc: stds-802-16@ieee.org
> > > Subject:
Re: [STDS-802-16-MOBILE] [Harmonization] MBS
> Harmonization
>
> >
> > >
> > > Vladimir,
> >
>
> > > I've edited the file, striking out your name.
>
> >
> > > I've also noted in the index that "Vladimir
Yanover has
> been deleted
> > > from the author list at his
request."
> > >
> > > Let me know if you have any
problem with this solution.
> > >
> > > Roger
>
> >
> > >
> > > At 12:54 +0300 2004-08-13,
Vladimir Yanover wrote:
> > > >All,
> > >
>
> > > >I was surprised to find my name in
contribution
> > > H80216e-04_005. It makes
> > >
>wrong impression that I basically agree with its content.
> >
> >I never saw this document before publication and was never
>
> > asked to sign on
> > > >it. So I cannot be
responsible
> > > >for content of the document as well as for
statements
> > > expressed in the
> > > >document
from the name of Alvarion.
> > > >
> > > >I find
this way of actions inappropriate and request to
> > > remove the
document
> > > >from 802.16 WEB site or at least to publish
another version
> > > without my name.
> > >
>
> > > >
> > > >My view on multicast
services is the following.
> > > >1. Requirements
> >
> >- ability to receive MC content while in normal
> operations
[not Idle]
> > > >- ability to employ power saving, at least
while in
> normal operations
> > > >- MC content will be
available only to authorized MSSs
> > > >
> > >
>Ability to receive MC content while in Idle Mode should be a
> >
> separated
> > > >capability.
>
##################
> [YONG]
> We don't need to put any limitation
that MBS is applicable to
> only Normal
>
operations.
[VY] We are talking on requirements here. If we
drop requirement for ability to receive MC data in Idle mode, then no
additions to MAC are needed,
therefore no new features in the system to
develop. For me it is a strong motivation to have a separated capability. I
believe, many members have same position.
Now, if we extend
requirements to support Idle mode, we need new features like new DL-MAP
IE (you call it MBS_MAP IE ) to help Sleep control in Idle mode.
As
you might see from my letter, I 1) accepted idea to have such IE 2)
suggested to make such IE general [not related to multicast business].
If
we do it, then we also do not need abovementioned restriction [separated
capability for Idle mode].
Let me know if it is OK for
you.
[YONG2] That's fine.
I do not intend to apply MBS_MAP IE only to MBS business. This MBS_MAP IE
generally can be used for telling when the next frame associated with
the CID is transmitted
from the BS.
Most companies do not want
to have different ways for MBS pending on the mode that the MSS is
currently in.
>
As I told several times, our MBS proposal is applicable to all MSS
>
types(e.g., awake, sleep, and idle) with the same information
element.
[VY] I don't understand what is "MSS of awake type" or
'MSS of sleep type". Any clarification would help a
lot.
[YONG2] They are MSS
in awake mode, MSS in sleep mode.
What I tried to say
is that one unified way is needed for MBS like service regardless of the mode
that the MSS is currently in.
> For obtaining power saving,
we want to use the same mechanism
> to be applied
> to all MSS
types.
> Explictly, the MSS can receive the registered MBS
content
> only when it is
> successfully authenticated and
authorized for MBS application
> content that
> it has
requested.
> There is no technical reason to consider the ability
to
> receive MBS content
> while in idle mode as a separated
capability.
> Technically, we can have much gain when the MSS in idle
mode
> can receive the
> MBS content seamlessly over multiple BSs
because the MSS can
> receive the
> MBS application content on
moving multiple BSs without any
> network re-entry
>
procedure.
> Additionally, the MBS does not limit the current
normal
> operation scenario.
> That is, the concurrent
service(e.g., both unicast service on normal
> operation and MBS
simultaneously) is always possible.
> ##################
>
>
> > >
> > > >2. To satisfy above requirements actually
no additional MAC
> > > features needed.
> > >
>What we need is few informative sentences:
> > > >- Some of
DL Service Flows are for distributon of
> multicast content
> >
> >- While the MSS is in normal operations mode [not Idle], all
>
> > procedures are
> > > >performed as in 6.3.13
[establishment of connections], usual
> > >
>authorization/security stuff
> > > >is applicable. The MSS
may go to sleep and be wakened by
> > > TRF-IND with
> >
> >reference to the CID associated with multicast
service
>
> ##################
> [YONG]
> I told your
positions in previous Harmonization conference
> calls on issues
>
and remedies.
> If I understand your proposal correctly, your proposal
for DL SFID
> pre-reserved for MBS usage can be applicable to idle
mode.
[VY] I said that there is a problem of CIDs used for
transmission of multicast content. If a an MSS in Idle mode
is synchronized
with a BS, and the BS is using certain CID for multicast transmission, how the
CID becomes known
to those MSSs? Simple solution: assume that there is a
mapping SFID onto CID, same for the whole network and it is known to both BS
and MSS.
We don't need to specify it in the standard, just to say that such
mapping exists.
We may to do one step further and to
specify that certain set of CIDs is allocated for that [e.g. those allocated
in UL for multcast polling].
[YONG2] At least O.K.
to me. > However, it
seems to me that what you said on authorization
> and security
for
> MBS is very very complex.
> If I follow your scenario, the
MSS shall perform the current
> network entry
> procedure always
whenever the MSS moves multiple BSs.
[VY] I don't understand sentence "the MSS moves multiple
BSs", so cannot comment on this part.
I don't understand also what is "my scenario".
[YONG2]
Your sentence "While the MSS is in normal
operations mode [not Idle], all procedures are performed as in
6.3.13 [establishment of connections], usual authorization/security
stuff is applicable." implied to me that the USUAL
authorization/security, not MBS authorization/security is
applied.
Under your sentence, the MSS shall be
re-authorized and shall change the multicast security key acrossing multiple
BSs.
Based on what you said in your comment below,
you are thinking the same authorization/security stuff with what we are
having.
> You can not obtain Macro Diversity since the user-specific
security
> mechanism is applied to the MBS.
[VY] My interpretation of above is: you're saying that
if upper level security mechanism is applied,
diversity combining cannot be used. If this interpretation is correct,
I'd like to say that I don't understand
why diversity combining cannot be used. If several BSs transmit same
content and it is encrypted at upper layer with same key,
then in the air we shall see same transmissions [MAC PDUs]. Same is
correct for encryption at MAC level:
if two BSs use same key [for encryption of MAC PDU
payload], combining is possible, otherwise it is not.
[YONG2]
That's what I am trying to say. I think that
your previous sentence might mislead me misunderstanding what you tried to
say.
> Accordingly, your proposal using current normal
operation
> does not have any
> performance improvement on
receiving MBS content.
> Moreover, your proposal is very heavy and
overhead to the BS
> and MSS because
> BSs shall know how many
MSSs are currently receiving the specific MBS
> content,
> how
many MSSs are sleep mode currently, and MSS shall join
> the specific
MBS
> content at the network whenever MSS wants to change his
MBS
> application
> channel.
>
> Conclusively, your
scenario following the current normal
> operation is based
> on
current multicast service using IGMP on IP and above layer.
[VY] Yong, I didn't say a word on IGMP or IP multicast
service.
I would appreciate if you read my letter more carefully.
Thanks
[YONG2] O.K. You
correct my misunderstanding.
> The current standard can provide what you have in your
mind
> at the sacrifice
> of performance improvement(e.g., Macro
Diversity), simplicity(e.g., BS
> management, MSS join and leave
procedure)
> and generality(e.g., regardless of the MSS's
mode).
> Repeatedly speaking, our simplified MBS proposal does
not
> effect on the
> current normal operation.
>
##################
>
>
> > > >
> > >
>3. Ability of MSS to receive MC content while in Idle mode
> >
> should be a
> > > >separated capability. In this case
authorization should be
> > > supported by
> > >
>upper layers.
> > > >For example, the content may be
encrypted and only
> > > authorized MSSs will have
> >
> >the key. Mapping of MC SFIDs onto CIDs shall be known to all
BSs
> > > >in the network and to all relevant MSSs [mechanism
is out of
> > > scope of 16e]
>
>
##################
> [YONG]
> As I said earlier, what you said in
the above is fine to me.
> Now, we are waiting for another company's
comment for harmonization.
> ##################
>
> >
> >
> > > >The only issue remains power save while in
Idle mode. To
> > > provide that,
> > > >MBS_MAP
Information Element may be useful, but I would
> make it more
>
> > >general: allow any CID to be encoded including Basic CID
of
> > > some MSS. Then
> > > >such IE would signal
to relevant MSS[s] that there will be
> > > no DL traffic
at
> > > >the CID within certain time interval [so the MSS may
save
> > > power, go for
> > > >scanning etc.]
Accordingly the name should be changed
> [e.g. to "Idle
> >
> >interval IE"].
> ##################
> [YONG]
> I do
not understand what you are proposing.
> MBS-MAP extended IE is for the
prediction when the next MBS frame is
> transmitted.
> Why this
feature should be bound with MSS's Basic CID?
> MBS_MAP IE is not
relevant to the MSS but relevant to the
> Multicast CID of
> MBS
content.
> This MBS_MAP has already covered normal operation. Don't
need
> to limit to
> the Idle Mode only.
[VY] Let me spell out my suggestion.
1. Define IE of same structure as you suggest
2. Make it not specific to MBS. It means allow to use it for
all CIDs, not only for those carrying multicast content.
3. Change it's name
Hope, this helps better understanding
[YONG2] My responses
are
1. O.K.
2. O.K.
3. How about Pre-scheduling IE instead
of MBS_MAP IE ?
> ##################
>
> > > >
> > >
>Other concepts are more less covered by existing
> > >
constructions. For example
> > > >virtual connection / "MBS
Zone" functions are covered by
> Service Flow
> > >
>concept
> ##################
> [YONG]
> For the virtual
connection concept, I can be willing to harmonize your
> concept because
most of companies
> agreed with the concept that MBS connection
infomation shall
> be the same
> over multiple
BSs.
>
> MBS Zone is applicable to tell the Macro Diversity Zone
and regional
> specific deployment
[VY] So you do agree to replace "virtual connection"
with Service Flow?
I would appreciate that
[YONG2]
We need explicit text to show how
Service Flow works like virtual connection that I
proposed.
By the way, Service Flow does not replace the
MBS Zone because
MBS Zone is designed for the MSS to know
whether or not
the MBS connection information previously
stored is maintained when it moves into another BS.
> ################## > > > > > > > >
>Vladimir > > > > > > > >>
-----Original Message----- > > > >> From: Beomjoon
(BJ) Kim [ mailto:beom@LGE.COM]
> > >
>> Sent: Thursday, August 12, 2004 11:31 AM
> > >
>> To: STDS-802-16-MOBILE@listserv.ieee.org
> > >
>> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
>
> > Harmonization
> > > >>
> > >
>>
> > > >> Dear Yigal
> > >
>>
> > > >> You mean that every BS will be able
to support Macro
> > > >> Diversity in PHY
level.
> > > >> Am I right? If so, we agree with you
in that the negotiation
> > > >> procedures are not
necessary.
> > > >>
> > > >> Also,
if you have another comment or answer, please give me a
> > >
>> feedback.
> > > >>
> > >
>> Thank you
> > > >>
> > >
>> Regards,
> > > >>
> > >
>> BJ
> > > >>
> > > >>
----- Original Message -----
> > > >> From:
<owner-stds-802-16-mobile@LISTSERV.IEEE.ORG>
> > >
>> To: <STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
> >
> >> Sent: Thursday, August 12, 2004 10:40 AM
> > >
>> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
>
> > Harmonization
> > > >>
> > >
>>
> > > >> > Dear BJ,
> > >
>> >
> > > >> > I am not aware that
there currently exists a possibility
> > > >> that a
BS will not
> > > >> > support the MBS zone in the
PHY level, and I'm not sure we
> > > >> want to
promote
> > > >> > BS that do not support this very
important capability, so I
> > > >> don't think
a
> > > >> > negotiation is required.
> >
> >> >
> > > >> > BR,
>
> > >> > Yigal
> > > >>
>
> > > >> > -----Original Message-----
>
> > >> > From:
owner-stds-802-16-mobile@listserv.ieee.org
> > > >>
> [mailto:owner-stds-802-16-mobile@listserv.ieee.org]On
> > > >> Behalf Of Beomjoon
>
> > >> > (BJ) Kim
> > > >> >
Sent: Wednesday, August 11, 2004 2:03 PM
> > > > >
> To: STDS-802-16-MOBILE@listserv.ieee.org
> > > >>
> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
> > >
Harmonization
> > > >> >
> > >
>> >
> > > >> > Dear Yong Chang and
all involved in MBS
> > > >> >
> > >
>> > I'm BJ from LG Electronics.
> > >
>> > We want to clarify a few things and our position
regarding
> > > >> the issue in the
> > >
>> > uploaded contribution by Yong Chang.
> > >
>> >
> > > >> > 1) Basically, we
agree to that Pre-Advermisement may not be
> > > >>
necessary under
> > > >> > the assumption of Macro
Diversity.
> > > >> > Therefore, NBR-ADV message
may not include MBS Zone ID of
> > > >> neighbor BSs
(if
> > > >> > there is no need for an MSS to
perform HO under the
> assumption).
> > > >>
>
> > > >> > 2) However, when an MSS attempts to
enter network at a BS,
> > > >> it is
necessary
> > > >> > for the MSS to negotiate MBS
capability with the BS whether
> > > >> or not the
BS
> > > >> > can support MBS based on Macro
Diversity. It is because all
> > > >> BSs may
not
> > > >> > support MBS with Macro Diversity.
So, we have proposed that
> > > >> Mode
Support
> > > >> > Indication (MBS support) should
be included in
> > > REG-REQ/RSP in our
> > >
>> > contribution (H80216e-04/01).
> > >
>> >
> > > >> > 3) Also, we have
proposed a Backbone message to manage the
> > > >> BSs
included in
> > > >> > MBS zone.
> > >
>> > We want to hear your opinion about the backbone
message.
> > > >> > (Alvarion people seem to think
it may be out of scope.)
> > > >> >
> >
> >> > Additionally, we have a question.
> > >
>> >
> > > >> > Under the
environment where Macro Diversity is supported,
> > >
>> we understand that
> > > >> > there
is no need for an MSS receiving only MBS traffic to
> > >
>> perform Handover
> > > >> >
procedures.
> > > >> > However, there may be a case
where an MSS starting to
> > > >> receive MBS
traffic
> > > >> > from BS 1 moves to BS 2.
>
> > >> > In this case, BS 2 does not know the MSS is in
its coverage
> > > >> because the MSS
> >
> >> > did not perform HO procedures.
> > >
>> >
> > > >> > In this
situation,
> > > >> > Q1: If there is DL traffic
addressed to the MSS, how can
> > > >> either BS1 or
BS2
> > > >> > trasmits the traffic to the MSS
without any session
> > > >> information of the
MSS?
> > > >> > If the MSS is in Idle Mode when the
DL traffic arrives (at
> > > >> this time the
DL
> > > >> > traffic will arrive at BS1),
the DL traffic may be
> > > >> delivered to the
MSS
> > > >> > using the existing procedures of
Idle Mode.
> > > >> > However, if the MSS is in
Normal Mode or Sleep Mode, it is
> > > >> impossible
to
> > > >> > deliver the traffic to the
MSS.
> > > >> >
> > > >>
> Q2: If the MSS has UL traffic to transmit, should the MSS
> >
> >> perform Initial
> > > >> >
Network Entry at BS2?
> > > >> >
> > >
>> > Thank you
> > > >> >
>
> > >> > Regards,
> > > >>
>
> > > >> > BJ
> > > >>
>
> > > >> > ----- Original Message
-----
> > > >> > From:
<owner-stds-802-16-mobile@listserv.ieee.org>
> > >
>> > To: <STDS-802-16-MOBILE@listserv.ieee.org>
>
> > >> > Sent: Wednesday, August 11, 2004 4:44 PM
>
> > >> > Subject: [STDS-802-16-MOBILE] [Harmonization]
MBS
> Harmonization
> > > >> >
> >
> >> >
> > > >> > >
All,
> > > >> > >
> > >
>> > > I have uploaded the initial draft for MBS
Harmonization
> > > >> on the upload
> > >
>> > > server.
> > > >> > > I
showed in this draft how many comments on MBS
> were given.
> >
> >> > >
> > > >> > > For
conference call of MBS only, what I heard from
> > > the chair
of
> > > >> > > Harmonization is that
>
> > >> > >
> > > >> > >
Time: August 5(Thursday), 3:30 PM (PST)
> > > >> >
> Bridge Information: Chair will give information ASAP.
> > >
>> > >
> > > >> > > If anyone
have a contribution with MBS, then please
> > > >>
upload it on the
> > > >> > server
> >
> >> > > before the meeting.
> > >
>> > >
> > > >> > >
Thank,
> > > >> > >
> > >
>> > > Yong Chang/Ph.D
> > > >> >
> Samsung Electronics, LTD
> > > >> >
>
> > > >> > >
> > >
>> > >
> > > >> >
> >
> >> >
> > > >> >
> >
> >>
> > > >>
> > > >> This
mail passed through mail.alvarion.com
> > > >>
> >
> >>
**************************************************************
> >
> >**********************
> > > >> This footnote
confirms that this email message has
> been scanned by
> > >
>> PineApp Mail-SeCure for the presence of malicious code,
>
> > >> vandals & computer viruses.
> > >
>>
**************************************************************
> >
> >**********************
> > > >>
> > >
>This mail was sent via mail.alvarion.com
> > > >
>
> >
>*************************************************************
> >
***********************
> > > >This footnote confirms that this
email message has been
> scanned by
> > > >PineApp
Mail-SeCure for the presence of malicious code, vandals &
> >
> >computer viruses.
> > >
>*************************************************************
> >
***********************
> > >
> > >
> >
>
> > > This mail passed through mail.alvarion.com
> >
>
> > >
**************************************************************
> >
**********************
> > > This footnote confirms that this
email message has been scanned by
> > > PineApp Mail-SeCure for
the presence of malicious code,
> > > vandals & computer
viruses.
> > >
**************************************************************
> >
**********************
> > >
> > This mail was sent via
mail.alvarion.com
> >
> >
>
**************************************************************
>
**************
> ********
> > This footnote confirms that this
email message has been scanned by
> > PineApp Mail-SeCure for the
presence of malicious code,
> vandals & computer
>
viruses.
> >
>
**************************************************************
>
**************
> ********
>
>
>
>
>
> This mail passed through
mail.alvarion.com
>
>
**************************************************************
>
**********************
> This footnote confirms that this email message
has been scanned by
> PineApp Mail-SeCure for the presence of malicious
code,
> vandals & computer viruses.
>
**************************************************************
>
**********************
>
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
|