Re: [STDS-802-16] Broadcast
No, it is not simple as you said.
As I pointed out, the main merit of the MBS(Multimedia Broadcast Service) is
coming from the mobility.
That is, even though the subscriber is moving anywhere, he/she can
successfully receive the corresponding MBS content from the BS without any
interruption.
If the subscriber is fixed, the method to provide MBS is very simple. Just
open a CID per each broadcast content, not multicast CID.
Multicast group is managed on IP layer with IGMP signaling. The service
authorization and the authentication are performed on IP layer after the
user authentication.
There procedure are behind of 802.16d. That's all.
If you said just within 16d. yes. it's very simple as I said above.
My point is how to provide the MBS without any interruption by the secure
manner when the MSS moves.
Again, the main rationale for broadcast service is found in 16e rather than
16d.
Thanks,
Yong Chang/Ph.D
Samsung Electronics.
----- Original Message -----
From: "Al Dabagh, Baraa" <baraa.al.dabagh@intel.com>
To: <stds-802-16@ieee.org>
Sent: Thursday, April 22, 2004 8:12 AM
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
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.
>
****************************************************************************
********
>
>