Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.
>  >
>
****************************************************************************
>  ********
>  >
>