|
Yong,
I see
that zone of our disagreement is comparatively small
See my
answers below marked as [VY2]
Vladimir
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.
[VY2] So we agree to extend usage of
renamed MBS_MAP IE. This also eliminates need in special capability for Idle
mode
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.
[VY2] Yes. See previous
comment.
> 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.
[VY2] Once the MSS is in normal operations [not Idle mode] , it must
perform all usual procedures including authentication and establishment of
connections.
Now, the question is whether multicast
connections must be handled this way also. I think, it may help. It
will allow the BS to know that the MSS is a consumer of multicast data
and to establish bidirectional communication with the MSS [for example, to
provide at upper layer a security update]
> 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.
[VY2} Seems no
disagreement
here?
> 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 ?
[VY2} Is it really a prescheduling? Seems
reasonable to define the meaning of the IE as "BS says that for N frames
there
will be no transmission at the CID".
But I don't recommend to make it "BS says that after N
frames there will certainly be
a transmission at the CID". We don't need to
restrict ourselves. MSS receives the IE, goes to sleep,
awakes and starts to listen.
It may listen for
several frames before receives a multicast transmission. Or BS may
decide to send one more IE of
this type etc.
Another recommendation is to allow CID in the IE to
be a Basic CID of the MSS. Then the IE will provide yet another way to allocate to the MSS
a vacation time
[similarly to Sleep Mode].
> ##################
>
> >
> >
> > > >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.
[VY2} OK, I am sending to Yong a
small doc with such wording [cannot send it to the
reflector].
Feel free to use
it.
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 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.
************************************************************************************
|