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.