From pbarber@BROADBANDMOBILETECH.COM Fri Apr 23 10:44:31 2004 Date: Thu, 22 Apr 2004 15:33:25 -0600 From: Phillip Barber To: l.napoli@ieee.org Subject: Re: [STDS-802-16] Broadcast Sorry, screwed up. I meant that last message to be off-list. Thanks, Phil ----- Original Message ----- From: "Phillip Barber" To: Sent: Wednesday, April 21, 2004 6:36 PM Subject: Re: [STDS-802-16] Broadcast > You are absolutely right. > > I think that some members are getting confused distinguishing between how we > are using 'Broadcast' to mean one thing at the network level and another at > the MSS/BS level. > > As I was clarifying for Pedro Neves: > > Look in the D4 document, 10.4 Well-known addresses and identifiers, Table > 298-CIDs, Page 569 > > You will see that there is a range of available Multicast CIDs and a single > Broadcast CID. Essentially there is only one Broadcast CID because we use > Broadcast CID within 16d/e for management message and, in very rare cases, > limited data payload distribution to all SS/MSS connected to a BS. What we > usually consider Broadcast and/or Multicast data traffic in IP networks is > attached to Multicast CIDs in all cases at the BS for DL transmittal. A > Broadcast data stream would simply be sent on a Multicast CID comprised of a > group including some or all SS/MSS connected to the BS. > > Sound right? > > Thanks, > Phillip Barber > President > Broadband Mobile Technologies, Inc. > 972-365-6314 direct (US) > +44 (0) 7909 794959 mobile (UK) > 925-396-0269 fax > > ----- Original Message ----- > From: "Al Dabagh, Baraa" > To: > Sent: Wednesday, April 21, 2004 6:12 PM > Subject: Re: [STDS-802-16] Broadcast > > > > There is no issue here. > > > > Here is how you do it in "d": > > > > - Create 2 multicast groups: > > > > 1- multimedia broadcast content (e.g., the one content is the pay-per-view > service like HBO and ESPN" > > > > 2- "free-per-view" > > > > - Associate only the MSS that are authorized for the "multimedia broadcast > content" service to multicast group 1 > > > > - Associate all MSSs to the second one. > > > > Baraa Al-Dabagh > > BWD > > Intel Corporation > > baraa.al.dabagh@intel.com > > Phone: 408-545-6078 > > -----Original Message----- > > From: owner-stds-802-16@listserv.ieee.org > [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Yong Chang > > Sent: Wednesday, April 21, 2004 3:10 PM > > To: STDS-802-16@listserv.ieee.org > > Subject: Re: [STDS-802-16] Broadcast > > > > First of all, we need to understand the characteristics of broadcast > service. > > > > Broadcast service is a kind of service that all MSS successfully > registered to the specific multimedia broadcast content(e.g., the one > content is the pay-per-view service like HBO and ESPN,, and the other > content is the free-per-view like CNN and advertisement, sort of public > broadcast service.) can receive the encrypted broadcast content anywhere > under the given time period. > > > > This definition gives us the following requirements: > > > > 1. MSS(Mobile SS) rather than SS is preferred because any moving > subscriber can receive this broadcast content. > > 2. The current broadcast CID is not appropriate for this broadcast service > because any MSS can not receive the specific broadcast content. > > 3. New identifier associating the broadcast application content with one > transport connection on MAC layer is required. > > 4. Even though the MSS moves anywhere, the specific broadcast content is > always successfully received by this MSS locating anywhere. > > 5. The broadcast service security mechanism applied to the service > authorization and authentication, content data encryption and so on shall be > provided. > > 6. Since the specific multimedia broadcast content may require high > bandwidth over the air, sometimes above 64 kbps per each content, the DL > burst for broadcast service may be newly designed. > > > > Generally, I believe that the broadcast service feature is to be discussed > in 16e rather than 16d as a separated section. This issue is very challenge > to us.. > > > > > > Best Regards, > > > > Yong Chang/Ph.D > > Samsung Electronics. > > > > > > > > ----- Original Message ----- > > From: Johnston, Dj > > To: stds-802-16@ieee.org ; STDS-802-16@listserv.ieee.org > > Sent: Thursday, April 22, 2004 2:13 AM > > Subject: RE: [STDS-802-16] Broadcast > > > > The issue of data broadcast needs to be understood in the context of what > CS service you are providing. > > > > Broadcast data (as opposed to broadcast management) is a feature of the CS > service. So for example 802.1 defines broadcast behaviour within the context > of 802. This is not completely trivial, the behaviour of 802 broadcast data > on an 802 network is subject to a number of rules. The behavior at the > 802.16 MAC CPS layer is the multicast service. > > > > At present it is the job of the CS to map between the CS broadcast service > and the MAC CPS multicast service. I submitted a few comments about the need > to clarify the CS broadcast behavior in order to make both ends of the link > behave the same. > > > > So if a CS is presenting and 802 broadcast service, it needs to know who > is in the 802 broadcast group and set up a multicast group to all these SSs. > You may be doing something different to the default. There may be VLANs or > provider bridging or distinct, isolated 802 networks being served to users. > > > > So in 802.16, broadcast data is not broadcast data. It is a specially > managed aspect of the MAC CPS multicast service to provide an equivalent to > a CS layer broadcast service. > > > > If we want to go down a route of defining broadcast data in the MAC CPS, > then we need to have a reason. > > E.G. > > A MAC CPS layer broadcast service will enable CS layer broadcast > service with lower on air management messaging > > or > > A MAC CPS layer broadcast service will prevent redundant specification > of broadcast behaviour in multiple CS specs. > > > > I don't see that either of these is true. Therefore I don't see a need for > a broadcast CID on the downlink. > > On the uplink, there is no broadcast. Data goes only to the BS, since that > is what the PHY layer supports. The CS is free to create a multicast CID to > provide that function. > > > > So I see no need to a broadcast CID in the MAC CPS. > > > > DJ > > > > > > -----Original Message----- > > From: owner-stds-802-16@listserv.ieee.org > [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Ken Stanwood > > Sent: Wednesday, April 21, 2004 8:48 AM > > To: STDS-802-16@listserv.ieee.org > > Subject: Re: [STDS-802-16] Broadcast > > The basic situation is this: > > > > 1. The "Broadcast" connection that currently exists was intended for MAC > usage. There is now way to indicate a user service over it. > > 2. Multicast polling groups are just that, polling groups, not > connections. The "CID" is a replacement for the SS's Basic CID which is > actually used in maps a a shortened SS ID rather than really a connection > ID. > > 3. Terminals are unaware whether a connection is multicast or unicast, > with the exception of it having a different security association. > > 4. A broadcast DL connection would be established today by setting up a > connection with the same parameters to all SS's. It's data would need to be > transmitted in a region that all SS's could listen to, or be re-broadcast to > sets of SS's if no such region existed as could possibly happen with AAS or > DL OFDMA. > > > > We should consider whether a true broadcast well-known connection would be > useful. If so, I recommend putting it in 16e since it's an extra feature. > > > > Ken > > > > > > From: owner-stds-802-16@listserv.ieee.org > [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Pedro Neves > > Sent: Wednesday, April 21, 2004 4:42 AM > > To: STDS-802-16@listserv.ieee.org > > Subject: Re: [STDS-802-16] Broadcast > > The draft does not specify one broadcast and one multicast connection for > sending data from the BS to the SS's? > > > > As Vladimir said, multicast polling groups are used, but what about data > transfer from the BS to the SS's? I thought CIDs were allocated for this > type of transmissions. > > > > > > Regards, > > Pedro Neves > > > > -------------------------------------------------------------------- > > Pedro Miguel Naia Neves > > Instituto Telecomunicações - http://www.av.it.pt > > Aveiro - Portugal > > Phone: +351 234 377 900 > > Mobile: +351 96 618 75 82 > > Homepage: http://daidalos.av.it.pt/~pneves > > MSN contact: etneves@hotmail.com > > > > > > From: owner-stds-802-16@listserv.ieee.org > [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Vladimir Yanover > > Sent: quarta-feira, 21 de Abril de 2004 12:06 > > To: STDS-802-16@listserv.ieee.org > > Subject: Re: [STDS-802-16] Broadcast > > > > Eyal, > > Seems that the standard does not preclude from sending data over broadcast > connection. Another question is whether > > we may establish a service flow associated with broadcast connection. I > think, we cannot, then there is no way > > for data entering CS SAP to be routed to broadcast connection. > > By the way, multicast connections are not related to multicast [polling] > groups. > > Vladimir > > -----Original Message----- > > From: Eyal Verbin [mailto:everbin@AIRSPAN.COM] > > Sent: Wednesday, April 21, 2004 1:39 PM > > To: STDS-802-16@LISTSERV.IEEE.ORG > > Subject: [STDS-802-16] Broadcast > > Section 6.1 of the standard states that " In addition to individually > addressed messages, messages may also be sent on multicast connections > (control messages and video distribution are examples of multicast > applications) as well as broadcast to all stations." > > > > Correct me if I'm wrong, but broadcast transmission is limited to MAC > management messages (MAPs, DCD,...) and can't be used to transfer data. > Therefore, the only way to broadcast data is to form a multicast group > containing all SS's > > > > Eyal > > > > -----Original Message----- > > From: owner-stds-802-16@listserv.ieee.org > [mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Don Leimer > > Sent: Monday, April 19, 2004 8:26 PM > > To: STDS-802-16@listserv.ieee.org > > Subject: Re: [STDS-802-16] Clarification regarding SS power level control > > Only one more comment. The final 4dB of error will also be reduced by > subsequent BS commands, and relative error diminishes to +/- 0.5dB for the > final error (relative to the BS's capability to measure power) > > -----Original Message----- > > From: Raja Banerjea [mailto:RBanerjea@PROXIM.COM] > > Sent: Monday, April 19, 2004 9:14 AM > > To: STDS-802-16@LISTSERV.IEEE.ORG > > Subject: Re: [STDS-802-16] Clarification regarding SS power level control > > The power control method is a closed loop method where the Base station > asks for further power control corrections if required. If the base station > requests the subscriber station in the RNG-RESP to increase the power level > by 30dB the SS should increase it by 30dB with a relative accuracy of 4dB. > > If the Base station is going to increase the power of the SS in 5 steps > and the BS requests the SS to increase the power by 8dB the SS will increase > it by 8dB with a relative accuracy of 4dB. In the subsequent RNG-RESP > message the BS instead of requesting a power increase of 8dB will request > for 8dB+(relative accuracy). Therefore after each increase requested from > the BS the relative accuracy should be 4dB. > > This assumes that the BS can make an accurate measurement of the SS's > power increase. > > Any comments ? > > Regards, > > -Raja > > > > -----Original Message----- > > From: Crozier, Eugene [mailto:Eugene_Crozier@SRTELECOM.COM] > > Sent: Monday, April 19, 2004 6:26 AM > > To: STDS-802-16@listserv.ieee.org > > Subject: Re: [STDS-802-16] Clarification regarding SS power level control > > My understanding of this is that the step size should be greater than 1 dB > but less than 8 dB (I'd assumed for the relative accuracy that the 50% of > the step size can be no more than 4 dB), but the number of steps is based on > the step size and the relative accuracy to achieve the minimum control > range, so for 1 dB steps, the number of steps can be between 60 and 20 > (30/0.5 and 30/1.5) for a 30 dB range, and for 8 dB step size the number of > steps between 8 and 3 for the 30 dB range. > > > > Regards > > > > Eugene Crozier > > -----Original Message----- > > From: Eyal Verbin [mailto:everbin@AIRSPAN.COM] > > Sent: Monday, April 19, 2004 8:22 AM > > To: STDS-802-16@listserv.ieee.org > > Subject: [STDS-802-16] Clarification regarding SS power level control > > Power level control for the OFDM PHY is defined in section 8.3.9.1: > > " For an SS not supporting subchannelization, the transmitter shall > support a monotonic power level control of 30 dB minimum. For an SS > supporting subchannelization, the transmitter shall support a monotonic powe > r level control of 50 dB minimum. The minimum step size shall be no more > than 1 dB. The relative accuracy of the power control mechanism is +/-50% of > the step size in dB, but no more than 4 dB. As an example, for a step size > of 5 dB the relative accuracy is 2.5 dB. For a BS, the transmitter shall > support a monotonic power level control of 10 dB minimum." > > Looking at the SS (subchannelization) for example, it is possible to go > from Min power to Max power either in 5 steps of 8 dB or in a single step of > 50dB. In the first option the accumulated offset can reach 5*4dB (20dB) > wheras in the second option the tolerance is limited to 4dB. > > Does anyone have a more clear interpretation of this text? > > Eyal Verbin > > > > > > 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. > > > **************************************************************************** > ******** > > >