----- 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
BScould 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.