Re: [STDS-802-16] Broadcast
Sorry, screwed up. I meant that last message to be off-list.
Thanks,
Phil
----- Original Message -----
From: "Phillip Barber" <pbarber@BROADBANDMOBILETECH.COM>
To: <STDS-802-16@LISTSERV.IEEE.ORG>
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" <baraa.al.dabagh@INTEL.COM>
> To: <STDS-802-16@listserv.ieee.org>
> 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.
> >
>
****************************************************************************
> ********
> >
>