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

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