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

Re: [STDS-802-16] [STDS-802-16-MOBILE] [HARMONIZATION] 7/26 Telecon agenda; inventory of comments/contribs



Title: [STDS-802-16-MOBILE] [HARMONIZATION] 7/26 Telecon agenda; inventory of comments/contribs
Dear Donnie and all
 
In my opinion, Keep Alive Mechanism is not necessary, even if it is for OFDMA PHY.
As Yigal commented in last session, existing RNG-REQ/RSP mechanism can be used for this purpose.
 
Suppose a BS wanna know whether a specific MSS is still available or not.
In this case, the BS allocates an uplink bandwidth using UL-MAP message for the MSS.
If the MSS is still available, it will transmit data if it has data to transmit or RNG-REQ message otherwise.
This procedures are defined in 16RevD. (refer to figure 90 "Periodic CDMA Ranging - SS" in page 214.)
Therefore, this uplink opportunity allocation mechanism can be adopted to check an MSS availability, even if it is not clarified in specific.
 
Regards,
BJ
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]
Sent: Tuesday, July 27, 2004 10:28 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [STDS-802-16-MOBILE] [HARMONIZATION] 7/26 Telecon agenda; inventory of comments/contribs

Could you put Comment #370 under the Category: Miscellaneous:?
That comment is about OFDMA Keep Alive Mechanism For Session Information Management and Yong Chang of Samsung mentioned Samsung plans to propose using RNG-REQ for that purpose.
 
Donnie Lee of SK Telecom
----- Original Message -----
Sent: Tuesday, July 27, 2004 12:15 AM
Subject: [STDS-802-16] [STDS-802-16-MOBILE] [HARMONIZATION] 7/26 Telecon agenda; inventory of comments/contribs


Telecon Reminder:
Monday, July 26th, 8 PM U.S. Pacific Time - 916-356-2663, Bridge: 2, Passcode: 9856750

Proposed Agenda:
* Review inventory of comments / contributions as starting point for harmonization adhoc (see list below)

* Review plans / proposals for new contributions within scope of letter ballot recirc.

* Start reviewing categories listed below.

Comments / Contributions Inventory:
As a first step to the harmonization effort, we need to inventory comments/contributions that were withdrawn or rejected in Portland but which may be candidates to work from. I have summarized below what I believe are all of these comments and contributions based on the final USR file. Also, after the D4 draft becomes available, gaps / inconsistencies might emerge which we will have to address in this adhoc.

Category: MBS Support:
* Comment 341 (Contrib. 04/201r1) - Enhanced broadcast / multicast capabilities - was rejected
Yong Chang's brief email on this:
This is the harmonized contribution with the following:
- Comment 538/Contribution 191: Multicast CID assignment for Multicast and Broadcast Service in IEEE 80216e
- Contribution 193: Channel Request messages for Multicast and Broadcast Service in IEEE 80216e
- Comment 342/Contribution 195: A New MAP IE for Group Messaging Service in IEEE 80216e
The proposal in this contribution is that:
1. Multicast transport CID is defined and is used for differentiating the multicast and broadcast content.
2. MBS_MAP IE is used for support the power saving in idle mode.
3. MBS_ZONE IE is used for support the mechani sm to let the MSS know whether or not MBS related session and security information are changed

The Zone_Switch IE is used for the MSS to change the DL-MAP information after detection of MBS_Zone change.
4. MBS Security is out of scope of this contribution because it has already accepted
In addition to these contributions, there were another contributions for MBS:
- Comment 338/Contribution 196: Live Poll messages for Multicast and Broadcast Service in IEEE 80216e
- Contribution 194: Multicast Group Membership Query message for Multicast and Broadcast Service in IEEE 80216e
Related PHY(MBS) contribution (which this adhoc will not discuss)
- Comment 417/Contribution 169r1: Enhanced feature for multimedia broadcasting
The contribution proposed the time-diversity effect in addition to macro-diversity effect.
Category: Handover Support:
* Comment 353 (Contrib. 04/156r1) - Safety Channel HO - was rejected
* Complete Soft HO and Fast BS switching contribution - especially Fast feedback channel and SDLs
* Comment 483 (backbone signaling) - this is ruled out of scope, so do we want to come up with requirements / assumptions for another TG to work on or perhaps propose informative text on assumptions for handover support?

* Comment 530 - was withdrawn. Related comment is 532 which was rejected.
* Does the spec cover all frequency reuse scenarios such as 1x3 (question posed by carriers)
* Preferred base stations for handoffs - contribution 04/142
Category: Idle mode and Paging Support:
* Comment 527 (Contrib. 04/222) - Enhanced paging in MOB-PAG-ADV - was rejected
Category: Scanning and Association related Optimizations:
* Comment 315 (Contrib. 04/167r2) - Enhancement of scanning and association
Category: Fixes to SDLs and informative text in Annexes:
* No contributions on this to date
Category: Miscellaneous:
* Comment 309 (Periodic ranging while in Sleep mode) - was rejected
* Comment 310 (Contrib. 04/194r1) - was rejected
* Comment 324 (Service Level Prediction) - was rejected
* Comment 370 (Contrib. 04/48r4) - was rejected
* Comment 537 (Contrib. 04/213r2) - was rejected

Plus - Following comments were withdrawn, do we need to revisit them -
#293
#294