Re: [STDS-802-16-MOBILE] [STDS-802-16] [STDS-802-16-MOBILE] [Harmonization] MBS Harmonization
Hi Yong and Vladimir,
A few points:
1. What distinguishes MBS service from standard multi-receiver Service
Flows is that MBS uses precisely synchronized transmission over multiple
BSes. This is an ironclad requirement if the service is to benefit from
both macrodiversity of multiple transmitters and seamless transitions
when moving (as Yong has mentioned).
Since accomplishing synchronized transmission means performing certain
functions (ie. classification, fragmentation, scheduling) at a
centralized point (ie. the MBS Server) distinct from the individual BS,
I'm surprised that there seems to be almost no text that mentions this.
2. I agree with your point Vladimir that there are strong arguments for
doing encryption at the point of distribution (just as the scheduling
and fragmentation is done at the point of distribution). However the
current draft states that encryption can be done either at the point of
distribution or at the BS. When done at the BS regular 802.16 security
will not ensure that the exact same keys and IVs are used at each BS.
Hence there is currently special security defined for the MBS case.
3. My specific suggestions for the current MBS draft text (section 3 only):
a) use the term "MBS connection", since "multicast connection"
describes a regular service flow that happens to have multiple listeners
(eg. connection for broadcasts in LAN emulation)
b) Include text to emphasize that classification, fragmentation,
and scheduling is done at MBS Server entity (MBS Server-BS interface is
not part of 16e scope)
c) MBS_IE: I agree with Vladimir that it should be more general
If I have time I'll try to put together some text for b).
BR,
- Jeff
Yong Chang wrote:
>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 -----
> From: Vladimir Yanover
> To: Yong Chang
> Cc: stds-802-16@ieee.org
> 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 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.
> ************************************************************************************
>
>
>
>