Re: [STDS-802-16] Broadcast
Most of what you concerned is network specific issue.
In 3G broadcast service architecture model, the broadcast content server is
located in the centralized manner on IP network.
Currently, most of 3G carriers are considering this architecture.
That is, it is generally assumed that the content provider transmits the
same broadcast content stream encapsulated in IP packet in the synchronized
manner to all BSs.
For synchronization on the interface between content provider and all BSs,
the time-stamp and the sequence number of RTP/RTCP may be used.
MSS can obtain the IP multicast address associated with an application
content(e.g., CNN) at the stage of the authentication/authorization.
Accordingly, the IP multicast packets are not different in each BS from the
content server.
These IP multicast packets with the same content are transmitted to the MSS.
Then MSS can achieve the soft combining effect.
If you consider the 3rd party content server, not owned by the operator,
then the 3rd party content server shall be managed and controlled by the
operator because it use the operator's resource.
If the MSS connects to the 3rd party content server directly on the current
transport CID, this is not broadcast service but unicast service from MSS
perspective.
Just the MSS is managed by network with IGMP signaling.
Unfortunately, the synchronization issue within BS is implementation issue.
What you suggested like DOCSIS and DVB mechanism is meaningful if the
broadcast content server is directly connected to PHY.
However, the generalized architecture is that the content server is located
on IP network so far.
That is, IP multicast packet is inevitable.
Then, we can consider two different architectures for broadcast service.
One is your scenario. The BS shall either have broadcast content server in
itself or provide the tunneling path between broadcast content server and
BS.
The other is mine. The BS connects the broadcast content server directly on
IP network.
How can we consider these two architectures in our 16e standard?
Thanks
Yong Chang/Ph.D
Samsung Electronics
From: "Yigal Leiba" <yigall@runcom.co.il>
To: <STDS-802-16@LISTSERV.IEEE.ORG>
Sent: Thursday, April 22, 2004 2:24 PM
Subject: RE: [STDS-802-16] Broadcast
> I think the broadcast service you are referring will be very hard to
> conceive under the MAC layer, because IP multicast packets will be
different
> in each BS, even if their content is the same. You will also face a horde
of
> synchronization issues.
> One possible solution to the problem is to map such broadcast service
> directly to the PHY, to enable the benefits of soft combining,
> non-interrupted HO, etc. The MAC should of course be used to describe,
> maintain and provision the broadcast area.
> An example of how this might work can be seen in DOCSIS and DVB networks,
> where the MPEG content is mapped directly to the physical media.
>
> Yigal
>
> -----Original Message-----
> From: owner-stds-802-16@listserv.ieee.org
> [mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Yong Chang
> Sent: Thursday, April 22, 2004 9:31 AM
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] Broadcast
>
>
> Yes. What you proposed is one of alternatives for receiving the same
> multimedia broadcast content on handover.
> However, you know, since your procedure follows the current handover
> scenario of 16e, there may be a little interruption of the broadcast
content
> receipt.
>
> Based on 3G experience, we can achieve the performance improvement by
> combining softly the same broadcast content if the CID is the same over
all
> BSs.
> That is, since the CID for the specific broadcast content is the same in
the
> overlap region between two BSs, then the MSS can receive two identical
> broadcast content from two BSs and combine them together.
> This can give the MSS the better quality of the broadcast application
> content.
> In this situation, the MSS does not need to perform the handover
procedure.
>
> I believe that the commonly same CID over all BSs for the MBS(Multimedia
> Broadcast Service) is preferred.
>
> Thanks again,
>
> Yong Chang/Ph.D
> Samsung Electronics
>
>
> ----- Original Message -----
> From: "Phillip Barber" <pbarber@broadbandmobiletech.com>
> To: <stds-802-16@ieee.org>
> Sent: Thursday, April 22, 2004 8:52 AM
> Subject: Re: [STDS-802-16] Broadcast
>
>
> > Currently under 16e, you would re-map the Multicast CID from the old
> Serving
> > BS to a new Multicast CID on the new Serving BS at time of HO. This
will
> > either involve adding the MSS to an existing, appropriate Multicast CID
on
> > the new Serving BS or creating a new Multicast CID.
> >
> > Thanks,
> > Phil
> > ----- Original Message -----
> > From: "Yong Chang" <yongchang@SAMSUNG.COM>
> > To: <STDS-802-16@LISTSERV.IEEE.ORG>
> > Sent: Wednesday, April 21, 2004 6:45 PM
> > Subject: 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.
> > > >
> > >
> >
>
****************************************************************************
> > > ********
> > > >
> > > >
> > >
> >
> >
>
>