Presentation is loading. Please wait.

Presentation is loading. Please wait.

SFH Updating Notification (16.2.23) Document Number: IEEE C802.16m-10/0056r2 Date Submitted: 2010-3-16 Source: Chun-Yuan Chiu, Ming-Hung Tao, Yung-Han.

Similar presentations


Presentation on theme: "SFH Updating Notification (16.2.23) Document Number: IEEE C802.16m-10/0056r2 Date Submitted: 2010-3-16 Source: Chun-Yuan Chiu, Ming-Hung Tao, Yung-Han."— Presentation transcript:

1 SFH Updating Notification (16.2.23) Document Number: IEEE C802.16m-10/0056r2 Date Submitted: 2010-3-16 Source: Chun-Yuan Chiu, Ming-Hung Tao, Yung-Han Chen, E-mail:{ccy, MHTao, chenyunghan, Yan-Xiu Zheng, Fang-Ching (Frank) Ren zhengyanxiu, frank_ren}@itri.org.tw ITRI Wern-Ho Sheen whsheen@itri.org.tw Chaoyang University of Technology / ITRI * http://standards.ieee.org/faqs/affiliationFAQ.html Venue: IEEE Session#66, Orlando, Florida, USA. Re: IEEE 802.16-10/0011, “IEEE 802.16 Working Group Letter Ballot#31”, on P802.16m/D4 Base Contribution: This is base contribution. Purpose: To be discussed and adopted by TGm for 802.16m LB#31. Notice: This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16. Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: and.http://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/guides/opman/sect6.html#6.3 Further information is located at and.http://standards.ieee.org/board/pat/pat-material.htmlhttp://standards.ieee.org/board/pat

2 SFH Update In current D4: –When the system information is changed, it may not be applied immediately. –The Start super-frame offset in the P-SFH IE is used to indicate where the new system information is applied. –The time interval between the system information changing and taking effect provides a time buffer for AMSs to update the new system information.

3

4 Problem When an AMS is in Sleep Mode or scanning for other ABSs: –If the S-SFH SP has changed and taken effect during its Sleep Window/ scanning interval, the AMS does not check the P-SFH IE and then miss the new system information. –After the AMS returns to Listening Window/scan interleaving interval, it may need much time to obtain all system information due to long S- SFH SP scheduling periodicity. –The normal operation will be affected.

5 Proposed Solution IDEA: ABS can transmit a unicasting message to AMS for notifying the coming of system information update. Add a SFH update indicator in AAI_SLP-RSP/AAI_SCN-RSP For some AMS, if the system information will change and take effect during its Sleep Window/scanning interval, –if the AMS has ability to receive SFH during Sleep Window/scan interval, the serving ABS may send a unsolicited AAI_SLP-RSP/AAI_SCN-RSP with SFH update indicator = 1 in prior Listening Window/scan interleaving interval to notice the AMS to still receive SFH during following Sleep Window/scan interval. –Else, the serving ABS may send a unsolicited AAI_SLP-RSP/AAI_SCN-RSP with SFH update indicator = 0 to the AMS in prior Listening Window/scan interleaving interval to reschedule the collided Sleep Window/scanning interval.

6 Clarification In some cases, AMSs may have ability to do scanning and performing SFH updating simultaneously, e.g., –performing intra-frequency preamble measurement –Multi-antenna capability ABS always has chance to send a unsolicited AAI_SLP- RSP/AAI_SCN-RSP to AMS because: –System information does not change frequently. The rate of change may be in units of minutes or hours. So we think updating System information is also not urgent (in units of seconds).

7 Proposed Text (1/3) Add the following text in page 336, line 56 in Section 16.2.23 –When an AMS is in Sleep Mode or scanning for other ABSs, if the S-SFH SP will change and take effect during its Sleep Window/scanning interval, the serving ABS may send a unsolicited AAI_SLP-RSP/AAI_SCN-RSP to it in prior Listening Window/scan interleaving interval. –The unsolicited AAI_SLP-RSP/AAI_SCN-RSP may reschedule the Sleep Window/scanning interval, or notice the AMS to still decode SFH IE during following Sleep Window/scanning interval.

8 Proposed Text (2/3) Modify Table 702: NameValueUsage Response_Code 0b00 : Request by ABS in Unsolicited manner 0b01 : Approval of AAI_SLP-REQ 0b10 : Rejection of AAI_SLP-REQ 0b11 : Reserved This indicates response type of AAI_SLP-RSP message. Operation 0b00 : Exit Sleep Mode 0b01 : Enter Sleep Mode 0b10 : Change Sleep Mode 0b11 : Switch Sleep Cycle setting This indicates operation type of AAI_SLP-RSP message. This field appears when Response_Code is 0b00 or 0b01. SFH update indicator 0b0: nothing 0b1: SFH Update is coming This field appears when Response_Code is 0b00 or 0b01 and Operation is not 0b00. ……

9 Proposed Text (3/3) Modify Table 689: NameValue Usage Scan duration Duration (in units of AAI subframes) of the requested scanning period. SFH update indicator 0b0: nothing 0b1: SFH Update is coming Included only when Scan Duration > 0 Scan Purpose 0b0: scan BS(s) which is in the list of the AAI_NBR-ADV message 0b1: scan BS(s) which is not in the list of the AAI_NBR-ADV message ……

10 Annex Modify Table 702 (based on MAC message tables proposed in C802.16m-10/0386): M/OAttributes / Array of attributes Size (bits) Value / NoteConditions MControl Message Type 8MAC control message typeNA MResponse_Code 2This indicates response type of AAI_SLP-RSP message. 0b00 : Request by ABS in Unsolicited manner 0b01 : Approval of AAI_SLP-REQ 0b10 : Rejection of AAI_SLP-REQ 0b11 : Reserved NA OOperation 2This indicates operation type of AAI_SLP-RSP message. 0b00 : Exit Sleep Mode 0b01 : Enter Sleep Mode 0b10 : Change Sleep Mode 0b11 : Switch Sleep Cycle setting When (Response_Code == 0b00 || Response_Code == 0b01) OSFH update indicator 1This indicates if SFH will update or not. 0b0: nothing 0b1: SFH Update is coming When (Response_Code == 0b00 || Response_Code == 0b01) && (Operation != 0b00) …… ………

11 Annex Modify Table 689 (based on MAC message tables proposed in C802.16m-10/0305): M/OAttributes / Array of attributes Size (bits) Value / NoteConditions MScan duration8 Duration (in units of AAI subframes) of the requested scanning period. OSFH update indicator1 0b0: nothing 0b1: SFH Update is coming Present only when Scan Duration > 0 MScan purpose1 0b0: scan BS(s) as listed in the AAI_NBR-ADV message 0b1: scan BS(s) as listed in the AAI_NBR-ADV message ……………


Download ppt "SFH Updating Notification (16.2.23) Document Number: IEEE C802.16m-10/0056r2 Date Submitted: 2010-3-16 Source: Chun-Yuan Chiu, Ming-Hung Tao, Yung-Han."

Similar presentations


Ads by Google