Re: [STDS-802-16] Broadcast
I agree we need a specific broadcast CID.
As for the modulation considerations, we should also note the fact
that when using a broadcast as a mean to transfer data, there is not
guarantee for the delivery, and the application should see for it.
Therefore, I agree with Phil there is not need to constrain all BC
CID transmissions.
Ofer
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Phillip
Barber
Sent: 21 April, 2004 7:46 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Broadcast
I agree with this as well. A specific true, broadcast CID specific to this
application would be a better idea.
Also, there is a problem in that the current language for Broadcast CID says
that it should use lowest-common-denominator modulation calculated based on
connected SS for the BS. For the purposes of 16e 'Idle-Mode', the broadcast
CID used would always have to default to the lowest modulation supported by
the PHY mode on the BS since the PHY mode connection information for Idle
Mode MSS is unknown. No need to similarly constrain all Broadcast CID
transmissions.
Thanks,
Phil
----- Original Message -----
From: "Jeff Mandin" <jmandin@STREETWAVES-NETWORKS.COM>
To: <STDS-802-16@LISTSERV.IEEE.ORG>
Sent: Wednesday, April 21, 2004 12:07 PM
Subject: Re: [STDS-802-16] Broadcast
> Ken Stanwood wrote:
>
> >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
> >
> >
>
> I think that's a good idea (perhaps a necessary one). Another reason to
> put it into .16e is that an SS
> that HOs to a new BS will need access to the data broadcast connection..
> The SFId for the broadcast
> service should be "well-known" too.
>
> This all assumes an 802.3 CS.
>
> - Jeff
>
> > _____
> >
> >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> 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>
> >http://daidalos.av.it.pt/~pneves
> >
> >MSN contact: <mailto:etneves@hotmail.com> 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 power 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.
>
>***************************************************************************
*
> >********
> >
> >
> >
> >
>