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.