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]DRAFT of Idle Mode Consensus Contribution



Phil and all
 
I am Pyung-Su Park from Hanaro Telecom
 
I have one comment about HO Process Optimization flags in DREG-CMD and one editorial comment.
 
I agree with Ronny's comment that putting Idle Mode Retain Information in DREG-CMD is more natural than HO Optimization.
I understand the purpose of HO Process Optimization in DREG-CMD which is the same mechanic we used in the HO Process at Session #32. Because Idle Mode Retain Information and HO Optimization has identical Bits, I think Idle Mode Retain Information can be delivered to MSS for indicative purpose then MSS can indirectly know the actual set of information the BS and network elect to retain. And I think HO Optimization flags, which process can be omitted, should be delivered to MSS through RNG-RSP at Network Entry or Location Update rather than DREG-CMD. Therefore, expressing like "Retain MSS service and operational information¡¦" is more right than "omit ¡¦ during current re-entry processing" at the time of Idle Mode Initiation.
 

In the text in 6.3.21.10 Network Re-Entry from Idle Mode, at page 12 of the DRAFT(DRAFT of Idle Mode Harmonization Rev.3.pdf
), I think replacing "During HO" with "During network re-entry from the Idle Mode" is correct.
 
 
Thanks,
 
PS, Park
Hanaro Telecom
 
----- Original Message -----
Sent: Monday, August 09, 2004 11:42 PM
Subject: Re: [STDS-802-16] [STDS-802-16-MOBILE] [Harmonization]DRAFT of Idle Mode Consensus Contribution

See my comments in-line.
 
Thanks,
Phil
 
----- Original Message -----
Sent: Monday, August 09, 2004 7:10 AM
Subject: RE: [STDS-802-16] [STDS-802-16-MOBILE] [Harmonization]DRAFT of Idle Mode Consensus Contribution

Phil and all

 

I have several comments on the latest DRAFT that Phil has uploaded.

 

1. Idle Mode Retain Information in DREG-REQ

   - Network Address would be more appropriate than Network Address Acquisition in Bit #3.

    

[Phil Barber] I agree.

 

2. HO Process Optimization in DREG-CMD

- Because HO Process Optimization is an answer for MSS request by ¡®Idle Mode Retain Information¡¯, I think ¡®Idle Mode Retain Information¡¯ makes more sense in DREG-CMD than ¡®HO Process Optimization¡¯. Language such as ¡°omit XXX during current re-entry processing¡± in HO Process Optimization would be a little inappropriate.

 

[Phil Barber] I disagree. We are not specifying exact information to be retained in Idle Mode Retain Information, only information that will enable certain handover process optimization MAC management message skipping outcome. So using the HO Process Optimization flags here as indicative base on the actual set of information the BS and network elect to retain is appropriate. This is exactly the same mechanic we used HO Process Optimization for in optimizing the HO Process at Session #32.

 

3. Paging Group ID in RNG-RSP

- DRAFT describes that Paging Group ID is delivered in case of successful Location Update, but successful Location Update can be made without paging group change. I think paging group ID shall only be included if Location Update Response = 0x01 and Location Update is Zone Update. Some mechanism should be provided to distinguish Zone Update from Timer Update.

 

[Phil Barber] I agree.

 

4. I doubt if Idle Mode supports BS initiated Idle Mode.

 - IEEE 802.16 REVd says ¡°The BS may transmit the DREG-CMD unsolicited or in response to an SS DREG-REQ message¡±. If BS initiated Idle Mode is supported, some language should be provided in order for the MSS to have chance to request ¡®Idle Mode Retain Information¡¯. If this is considered to be necessary, following text change could be considered.

 

The DREG-CMD may include the following parameters encoded as TLV tuples. In case of unsolicited DREG-CMD with Action Code=0x05, following parameter shall be included:               

REQ-duration

Waiting value for the DREG-REQ message re-transmission (measured in frames)

 

[Phil Barber] You are missinterpreting how REQ-duration functions. REQ-duration is a back-off interval. If Serving BS sends REQ-duration, then MSS shall not send a DREG-REQ during the REQ-duration interval. A Serving BS could send and use the message to tickle the MSS into requesting DREG-REQ for initiation of Idle Mode. I will have to look at the exact mechanics for doing this.

 

5. Idle Mode MSS vs Mobile IP (periodic control message)

- If an MSS uses Mobile IP, periodic control message such as Agent Advertisement should be delivered to the MSS. If an MSS in Idle Mode doesn¡¯t receive this Agent Advertisement from the network, MSS will try to re-enter network (IP layer will generate Agent Solicitation Packet). If my understanding is right, Agent Advertising rate is once every 7 to 10 minutes, and the default lifetime is 30 minutes. (RFC1256, RFC 3344) Because this lifetime is used for Mobile to detect its movement, MSS using mobile IP in Idle Mode will be back to normal mode in 30 minutes after Idle Mode initiation.

If MOB-PAG-ADV can inform MSSs in Idle Mode of periodic control message as shown below when the BS listens Agent Advertisement from the Network (it would be every 7 to 10 min), MSSs in Idle Mode will listen to CID at designated time and MSSs will be able to continue Idle Mode.

 

MOB-PAG-ADV_Message_Format() {

 

 

¡¦.

 

 

¡¦

 

 

Advertisement Indication

1 bit

0 : OFF, 1 : ON

If(Advertisement Indication == 1){

 

 

Time

16 bits

Periodic Network Control Message such as Agent Advertisement message will be transmitted after ¡®Time¡¯ frames.

CID

16 bits

Connection ID which conveys Periodic Network Control Message (Agent Advertisement message)

}

 

 

}

 

 

 

[Phil Barber] Doing this through the PAG-ADV message is a bad idea. We have previously decided that putting unicast data in the PAG-ADV is very, very bad. It is not confirmed delivery, so its usefullness is suspect (unless of course you require the MSS to do a Location Update to acknowledge receipt in which case that is hardly better than doing optimized network re-entry). And it eats up poor coding rate broadcast air time. It is far preferable to use the Idle Mode Timer and policy manager to manage this requirement for this specific implementation. At worst, the MSS has to re-enter the network every 30 minutes which is not onerous and would still result in 99.99% of time in Idle Mode.

 

 

 

 


From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org]
Sent: Monday, August 09, 2004 7:40 AM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [STDS-802-16-MOBILE] [Harmonization]DRAFT of Idle Mode Consensus Contribution

 

I have uploaded the latest DRAFT of the document into the Harmonization upload directory. While I received no additional comments since early last week, I made substantial clean-up, and language changes, to the document transforming it into a more readable format. I also fixed some missed, necessary corrections to the document. The document is now ready for Ad-Hoc group review.

 

Thanks,
Phil