| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I believe we don't require a well-known broadcast CID in the DL. This is
mostly because, as DJ pointed out, broadcast is a service associated with
the CS, and it is highly possible than on the same BS you have terminals
that support one CS using one broadcast CID, and other terminals,
supporting a different CS, using another broadcast CID.
In addition to that, the well-known broadcast CID buys you
nothing, because a broadcast connection will still have to be established
on a per terminal basis (because not all terminals need it, and it
interferes with sleep and idle modes, etc.). So if you are already
establishing the connection, there is little extra overhead in providing
a CID to go along with it. This way you keep at the flexibility in terms
of what modulation to use on a broadcast connection, how many of them to
establish, etc.
Yigal Leiba
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of
Johnston, Dj
Sent: Wednesday, April 21, 2004 10:14 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
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.
********************************************************************************
****