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.