stds-802-16-mobile: Handoff Ad-hoc and Sleep Mode activity
Dear 802.16e fans,
Following meeting #25, it was decided to re-activate the Handoff ad hoc group, with scope expansion to deal also with the sleep-mode issues.
The comment resolution process pointed out some issues, which should be resolved and/or discussed for both topics, and I'm taking this floor to start the discussion and formal activity of the handoff\sleep-mode ad hoc group.
For those of you that haven't had the chance to look at the last Tge commentary database (document 802.16e-03_10r1.usr) I have summarized the relevant comments for this group's activity.
I will appreciate any input about those issues, as well as any input concerning the handoff\sleep mode issues as defined in the current Tge working document, and was not expressed in the comments raised at meeting#25.
Please use the Tge reflector (stds-802-16-mobile@ieee.org) and the Tge uploading directory (stating that this is an input for the Ad hoc) as working tools.
Itzik.
--->
Comments for Tge:
Page:9 Line:42
Comment:
There's no value range for BS rating. Is this supposed to be similar to 'Service level prediction''?
What does ignoring this parameter mean? Maybe that the rating is unknown?
Resolution:
Itzik Kitroser to provide necessary text.
Page:11 Line:48
Comment:
I would think that 'U' is simply the 802.16 air interface. This poor attempt at defining a reference model actually needs to be integrated with section 1.3.
Resolution:
Move to section 1.3.
Action Itzik to re-write this section prior to re-issuance of the document.
Page:18 Line:15
Comment:
The sub-clause 6.2.17.2.2 claims that it specifies a break-before-make type HO, i.e., Hard HO. However, there are two problems with such a claim:
1. it is possible to support Soft HO with the proposal specified in the current document
2. it is not consistent with the previous spec, on page 1, which says "Two HO variants are define: ..."
As specified in the paragraph starting line 1, page 18, a MSS may use a scanning interval for UL ranging as well as a procedure called association. If such an association procedure is well defined to be a "make". Then, the two HO variants are really defined in the doc.
Resolution:
The text is not clear concerning the types of handoffs supported. Text will be provided by the handoff ad hoc for the next meeting (26)
Page:6 Line:54
Comment:
With a reasonable number of neighbors, this is going to be quite overhead heavy.
Resolution:
(Nico’s suggestion): Consider defining this compound TLV as offset to the DCD/UCD advertised by this BS (i.e. a TLV is default identical to that of the current BS unless advertized differently). With networks belonging to one operator, this should in general reduce the overhead substantially.
ACTION: Itzik to clarify what TLVs will be sent in the DCD/UCD settings.
Page:24 Line:38
Comment:
Could be I missed something, but I don't see the need for this fast ranging.
If the SS already sent a RNG-REQ with MAC Address, then the BS can send a RNG-RSP back with a basic CID, which can be immediately used to allocate bandwidth for maintenance ranging.
This new IE doesn't provide anything new or faster than the current specification.
Resolution:
Revise the MAC Address note to read "MSS MAC address as provided by the serving BS".
NOTE: Two additional tables are required: one for SC, one for OFDMA - ACTION Itzik to provide those two tables.
Page:17 Line:28
Comment:
The mechanism of responding to a SCN-REQ with DL-MAP_IE is rather weird. A map is used to allocate bandwidth, it's not intended to provide timing information for other purposes. The correct and consistent implementation of this is to respond with a SCN-RSP providing a list of combos of basic CIDs and number of frames the indicated MSSs
are allowed to be AWOL.
It doesn't make any sense to request this in OFDM symbols as defined in table 56ae, since it takes multiple frames to synchronize to other DLs and the only criteria of being back is decoding the maps again.
Resolution:
ACTION: Handoff ad hoc: Incorporate it as a separate message rather than a MAP IE.
Page:25 Line:16
Comment:
As stated before, this scanning_IE is an inconsistent mechanism.
Resolution:
ACTION: Handoff ad hoc: Incorporate it as a separate message rather than a MAP IE.
Page:3 Line:29
Comment:
Why not allow the BS to send unsolicited SLP-RSP message?
Resolution:
ACTION: Expand the scope of the ad hoc to include discussions on sleep mode and contribution 802.16e/03-31.
Page: Line:
Comment:
Section 6.2.17.3 is empty, particularly there are no information on coexistence of fixed and mobile-SS on the same air-interface instance
Resolution:
ACTION: Ad hoc group to draft text for this section (Itzik) for the July meeting.
Also:
Discuss contributions:
1. C80216e-03_28 א Fast Handoff service
2. C80216e-03_30r1 א Reporting of scanning results
3. 802.16e/03-31 א Sleep mode enhancement
<--- End of comments