| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I too agree that we dont need a well known broadcast CID for data
transmission in the DL for 802.16d. The current draft provides the
mechanism through which data broadcast can be achieved.
-Raja
-----Original Message-----
From: Yigal Leiba [mailto:yigall@RUNCOM.CO.IL]
Sent: Wednesday, April 21, 2004 9:45 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Broadcast
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.
********************************************************************************
****