Re: [STDS-802-16] [Harmonization] Idle Mode Harmonization
Many good
observations.
See my comments
in-line.
Thanks,
Phil
----- Original Message -----
Sent: Thursday, August 19, 2004 8:31
PM
Subject: [Harmonization] Idle Mode
Harmonization
To Phil and all,
I have some comments on the
Idle mode harmonization draft (04/245).
(I was not able to attend the 8/9
(Mon) teleconference. I apologize if
my understanding is not correct, or the
issues were already discussed.)
I. Comment 1: On the start of Idle Mode
Timer and Idle Mode System Timer
- Related remedies in 04/245: 1
-
Problem
In 04/245, it's not defined when the Idle Mode Timer and the
Idle Mode
System Timer are to start. Unexpected behavior of MSS or BS related
with
the two timers may happen.
- Proposed resolution
Define
respective starting conditions of Idle Mode Timer and Idle Mode
System Timer.
The condition for Idle Mode Timer should be an MSS event,
while that of Idle
Mode System Timer a Paging Controller event.
Ex) Starting conditions
for Idle Mode Timer: MSS's successful
reception of DREG-CMD
message
Starting conditions for Idle Mode
System Timer: Paging
Controller's successful transmission of DREG-CMD message
when it is the
serving BS, or its reception of a notification from the
Serving BS that
DREG-CMD has been successfully transmitted.
[Phil Barber] I agree, the
language invoking the timers is not clear exactly when the timers start.
I will make an appropriate change to Remedy 1.
II. Comment 2: Can a paging controller respond to Idle Mode
Timer?
- Related remedies in 04/245: 1
- Problem
It's impossible
for a paging controller to comply with the "shall"
rule in the last sentence
of the last paragraph in Remedy 1. Because
expiration of Idle Mode Timer is
an MSS event, there is no way for a
paging controller to respond on an MSS
event (although it may respond at
the time estimated from the expiration of
Idle Mode System Timer).
- Proposed resolution
Delete "On
expiration of Idle Mode Timer or" in the last sentence of
the last
paragraph.
[Phil Barber] I agree. I will make the appropriate
change.
III. Comment 3: On incorrect descriptions when Paging Controller is
the
Target BS (or the Serving BS)
- Related remedies in 04/245: 1, 8,
11
- Problem
A Paging Controller may be the Target BS. It is true
at least when the
Paging Controller is the Serving BS and the MSS makes
location update or
network re-entry with the same BS. In that case, the
Paging Controller
shall not discard MSS service and operational information
on MSS network
entry and resumption of Normal Operation, because it'll have
to use
them. Also, the exchange of messages between the Target BS and
the
Paging Controller (for example, new location notification message
from
the Target BS to Paging Controller, MSS information from
Paging
Controller to Target BS, MSS information request message from Target
BS
to Paging Controller, MSS successful network re-entry
notification
message from Target BS to Paging Controller, and request to
stop
forwarding message from Target BS to Paging Controller) may either
be
unnecessary or not be using backbone network.
Similar problems
are there for the case when Paging Controller is the
Serving BS.
Many descriptions of 04/245 do not fit into the above two cases.
- Proposed
resolution
Remove "via the backbone" or "over the backbone," in the
remedies
since it is not necessarily the case.
Replace "to
receive/send a backbone message to inform/notify," with
"to inform" or "to
notify"
Replace "MSS information obtained from Paging Controller or
other
network entity" with "MSS information retained, or obtained from
Paging
Controller or other network entity."
Detailed resolutions
are as follows:
[Phil Barber] Actually, I disagree with
your observation. It is completely appropriate to instruct for the
deletion of the MSS retained information on the Paging Controller on
successful network entry/re-entry even if the Paging Controller and Target
BS are one and the same. The reason it is OK is because Paging
Controller is a logical entity distinction independent of the logical entity
Target BS. Requirement that Paging Controller discard MSS context does not
interfere with Target BS (now Serving BS) need to maintain the MSS
new service and operational information. Even though
they may be the same physical entity, for our purposes we have
defined them as logical entities for prosecution purposes, so there is
no conflict in giving one an instruction to purge and the other an
instruction to retain. The same observation is true for the Serving BS as
well.
I do agree that the messaging may not be over the
backbone. But, again, because we are discussing different logical entities, it
is completely appropriate to discuss the messaging as if it were going over the
backbone. For different logical entities that are, in fact, the same physical
entity, the message might also be 'virtual' or logical and not actually ever be
generated (since the origin and destination are the same).
1) Change the last sentence of
Remedy 1 as follows:
"The paging Controller shall discard all MSS
service and operational
information retained for Idle Mode management
purposes on expiration of
Idle Mode System Timer, or on MSS network
entry/re-entry or resumption
of Normal Operation unless it is the Target BS."
2) Change the second last sentence of section 6.3.21.9.2.1 in
Remedy 8
as follows:
"..., the Target BS shall notify the Paging
Controller of the MSS new
location information, the MSS shall assume the
Paging Group ID of the
Target BS, and the Paging Controller may inform the BS
at which the MSS
entered Idle Mode that ..."
3) Change the
second to fourth paragraphs of section 6.3.21.10 in
Remedy 8 as
follows:
"If MSS RNG-REQ includes an HO Indication and Paging
Controller ID
TLVs, and Target BS is not retaining nor had previously
received MSS
information, then Target BS may make an MSS information request
of
Paging Controller and Paging Controller may respond. Regardless
of
having received MSS information from Paging Controller, Target BS
may
request MSS information from another network management
entity.
Network re-entry proceeds per 6.3.9.5 except as may be shortened
by
Target BS possession of MSS information which was retained, or
obtained
from Paging Controller or other network entity.
For the
Target BS to notify an MSS seeking Network Re-entry from Idle
Mode of
re-entry process management messages that may be omitted during
the current
re-entry attempt due to the availability of MSS service and
operational
context information retained, or obtained from Paging
Controller or other
network entity, the Target BS shall place an HO
Process Optimization TLV in
the RNG-RSP indicating which re-entry
management messages may be
omitted...."
4) Change the first sentence of the seventh paragraph of
section
6.3.21.10 in Remedy 8 as follows:
"Regardless of the HO process
Optimization TLV settings, the Target BS
may elect to use MSS service and
operational information retained or
obtained from Paging Controller or other
network entity to build and
send ..."
5) Change the eighth and ninth
paragraphs of section 6.3.21.10 in Remedy
8 as follows:
"For a security
keying process that has not been determined to be
omitted in the HO Process
Optimization TLV settings, if MSS RNG-REQ
includes HO Indication and Paging
Controller ID TLVs, and Target BS has
been retaining or has received MSS
information, MSS and Target BS shall
use the embedded TLV PKM-REQ information
and the re-authorization
process as defined in 7.2.
If MSS RNG-REQ
includes HO Indication and Paging Controller ID TLVs, and
Target BS has been
retaining or has received MSS information, the Target
BS may use the MSS
information to build and send a REG-RSP management
message that includes
Service Flow remapping information in New_CID,
Old_CID and Connection_Info
TLVs."
6) Change the last sentence of the tenth paragraph of section
6.3.21.10
in Remedy 8 as follows:
"..., MSS may re-establish IP
connectivity and new Serving BS may send a
request to the old Serving BS or
other network entity to stop forwarding
pre-HO pending MSS DL
data."
7) Change the twelfth paragraph of section 6.3.21.10 in Remedy 8
as
follows:
"The Target BS shall notify the Paging Controller of MSS
successful
network re-entry and the Paging Controller may inform the BS at
which
the MSS ..."
8) Change the first sentence of section 6.3.21.8.2
in Remedy 11 as
follows:
"The BS at which the MSS re-entered the network
shall report to the
Paging Controller about MSS network re-entry."
IV.
Comment 4:
- Related remedies in 04/245: 4, 5, 6, 7
- Problem
In terms of retaining service flow information, there seems to be only
two
extremes: no retaining at all when Bit #6 is 0 and retaining
information of
all service flows when Bit#6 is 1. There is no way to
trade-off between the
two extremes.
[Phil Barber] Not so. It is entirely possible to retain
Service Flow information and thereby tickle Bit#2 where the BS would return the
remapped CIDs for SFIDs during Network Re-Entry from Idle Mode. Bit#6 represents
the most extreme form of context persistence where counters, timers, state
machines, etc... are maintained sufficient that MSS could transfer its context
to the new BS as if nothing had ever happened. But you are correct in that if
the Paging Controller retained only pieces of these elements (say counters and
timers) but did not maintain all elements, there would be no way to value
the lesser retained information and Bit#6 would not be used.
- Proposed resolution
Differentiation of service flows
according to the resource retaining
preference might be useful in making
trade-off between the fast recovery
from idle mode and the overhead for
retaining resource. Paging
preference of a service flow is not a perfect
match to the resource
retaining preference. However, it is reasonable to
expect that the
service flows of paging generation preference can be
beneficial from
resource retaining. At the same time, Paging Controller or
Serving BS
may reduce resource consumption by freeing up the resource
associated
with the service flows of no paging generation
preference.
Add following after the description on Bit #6 in Remedies
4, 5, 6, 7.
"Bit #7: Retain MSS service and operational information
associated with
Service Flows having paging preference of 'paging
generation'"
[Phil Barber] I do not necessarily disagree. However, I
would prefer to hear more discussion on this idea before incorporating
it.
Thank you,
Jeong
--
Moo Ryong Jeong, Ph. D
DoCoMo
Communications Laboratories USA, Inc.
181 Metro Drive, Suite 300
San Jose,
CA 95110, USA
(408)451-4761 Tel
(408)573-1090
Fax