RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

["Riegel, Maximilian" <[e-mail]>]

There are no issues with the broadcast/multicast channels with the
exception that they consume much more radio resource than unicast
channels for the same amount of information and they do not work well
with advanced power down modes of terminals.

If information has to be delivered concurrently to many terminals in a
cell like in the IPTV case during world soccer games, multicast channels
are well suited. If they are less than about 5 subscribers to a
particular data stream in a cell, the efficiency of multicast channels
becomes questionable. If broadcast/multicast information is intended for
only one terminal (like an ARP request) and there are other ways to find
the right link, it is much better not to use a multicast/broadcast
channel but deliver the packet on a unicast channel to the terminal.
And in a IEEE802.16e system there are quite a few alternatives to the
'brut-force' multicast channel, especially when the architecture enables
access to all of the configuration data.

Bye
Max

-----Original Message-----
From: ext Burcak Beser [mailto:[e-mail]] 
Sent: Friday, September 07, 2007 7:31 AM
To: Riegel, Maximilian; Jongtaek Oh; [e-mail]
Cc: ?????; ?????; ??????; ?????
Subject: RE: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

I did not hear any issues with 802.16 broadcast channel(s). If there
were any issues, then the communication of IEEE 802.16 transmission
management will have a lot of issues as well and the unicast service
flows will not be utilized at all.

Lets make the assumption that all SS' but one can connect at 64QAM, and
a single one can only connect with QPSK If we want to send multicast
packets to some number of SS connected, the advantage of sending
individual packets disappear with 4 SS (all of them being 64QAM) or 1 SS
(connected through QPSK). More than that the broadcast through QPSK
channel will be more advantageous.

For applications such as IPTV the use of Broadcast (or Multicast)
Service Flows will almost always (practically always) be the most
efficient.

I would like to understand better why Broadcast channels are not even
considered.

Kind regards,
-burcak

-----Original Message-----
From: Riegel, Maximilian [mailto:[e-mail]]
Sent: Thursday, September 06, 2007 2:48 AM
To: Jongtaek Oh; [e-mail]
Cc: ?????; ?????; ??????; ?????
Subject: RE: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Please do not mix up MBS services (MCBCS in the WiMAX Forum) with MBS in
the IEEE802.16 specification. MBS in the IEEE802.16 specification
describes the possibility to share a downlink connection with multiple
MSs/SSs.

MBS Services are fully supported by this I-D (please see chapter 6.1).

There are good reasons not to deploy IEEE802.16 MBS channels for
Ethernet broadcasts. Annex A lists purely for information some of the
issues coming up with deployment of IEEE802.16 MBS channels.

Indeed there is an ongoing activity in the WiMAX Forum on MCBCS, which
works on network solutions to increase the efficiency of MBS channels
especially at the cell edge. The issues listed in annex A will remain,
but the effects on the link capacity will become smaller. Unfortunately
new issues will appear for real deployments.

Is there any publication explaining the benefits and issues of
IEEE802.16 MBS channels more in detail? Annex A is little bit too much
radio and I would like to remove annex A if there is any reference we
can use instead.

Any hint for a reference?

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[e-mail]]
Sent: Thursday, September 06, 2007 6:05 AM
To: [e-mail]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

I have some comment about the
draft-ietf-16ng-ip-over-ethernet-over-802.16-02,
especially for broadcasting and multicasting issue.

1. Firstly, it describes the functionality of IEEE 802.16 network for
MBS services, very pessimistically.
    As it mentioned, the specification and technology for MBS is not
perfect. But it is under developing by NWG of WiMax forum,
    and the broadcasting and/or multicasting in the radio link could be
possible, not impossible.
    This draft is for standard RFC, not for informative RFC, so only
specification related matters must be defined in the draft
    and leave the room for new technology can come in.

2. MBS service is important for network operators and service providers
to compete with the other cellular networks.
    For example, 3GPP Release99 can broadcast messages using cell
broadcasting technology.
    WiMax forum is developing MCBCS related technologies and
specifications which deals with the solution against the problems the
appendix A cited.
    For example, the unicasting or the broadcasting methods are to be
decided at the BS or AR according to the number of users in the cell.
    If all the IETF documents exclude the possibility of broadcasting
and multicasting transmission method, then they could be useless to the
WiMax industry.

In conclusion, I suggest to remove all the sentences which state the
negative respects of  multicast/broadcast for 802.16 network including
Appendix A.


Jongtaek Oh
Hansung Univ.
Seoul, Korea




----- Original Message -----
From: "Daniel Park" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 05, 2007 11:43 AM
Subject: RE: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02


> reminding...
>
> No show in the list for this WGLC. If you have any comments/feedbacks
on
> this call, please speak up now. Also, if you are ok with this version
(no
> changes), please show up your positive on this list. Otherwise, this
WGLC
> can't pass...!
>
> Daniel Park
>
>> -----Original Message-----
>> From: Daniel Park [mailto:[e-mail]]
>> Sent: Thursday, August 16, 2007 3:50 PM
>> To: [e-mail]
>> Subject: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02
>>
>> Folks,
>>
>> This is a WGLC on draft-ietf-16ng-ip-over-ethernet-over-802.16-02
>> "Transmission of IP over Ethernet over IEEE 802.16 Networks".
>>
>> o Intended publication: Proposed Standard RFC
>>
>> The latest version can be found at:
>> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ip-over-et
>> hernet-over-80
>> 2.16-02.txt
>>
>> Due to vacation period, it will expire on September 7 2007.
>>
>> -------------------------------------------------------
>> Daniel Park & Gabriel Montenegro
>> Chairs, 16NG Working Group
>>
>>
>>
>> _______________________________________________
>> 16NG mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/16ng
>>
>>
>
>
>
> _______________________________________________
> 16NG mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/16ng
>


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng




_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng