Thank you for the prompt and invaluable
comments.
Basically, I agree with you on all the issues.
Please find my detailed reply comments in-line.
Jeong
From: Phillip Barber
[mailto:pbarber@broadbandmobiletech.com]
Sent: Thursday, August 19, 2004
7:18 PM
To: STDS-802-16@listserv.ieee.org
Cc: Moo Ryong Jeong; cyberk@kt.co.kr; kimjh7@kt.co.kr;
lsc@kt.co.kr; Toshiro
Kawahara
Subject: Re: [Harmonization] Idle
Mode Harmonization
----- 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.
[Jeong] I understand your explanation on why
seemingly conflicting statements of current draft are not actually conflicting if
we introduce the concept of logical BS, logical Paging Controller, logical
operation, and virtual or logical message. Also, I have to admit that your approach
would make the standard more concise in that we need only to describe a single
logical setting instead of describing each physical setting.
I have several concerns though.
- We
might have to explicitly introduce the concepts of logical BS, logical
Paging Controller, and the virtual or logical message in the standard and provide
sufficient explanation on the concepts so that the standard should be
interpreted as we intended. Remember I interpreted it in a wrong way
without your explanation.
- We might
have to make the standard clearer about when the logical operation or message
may be skipped or omitted in the physical world. In my observation, the
cases are when the operation or message are executed or exchanged within a
single or multiple logical entities without intervention of any physical
entity. But I’m not sure whether this is necessary and sufficient.
- I
feel we need to redefine “backbone” as a logical entity at
least in 04/245, since it may not physically exist between the logical BS
and the logical Paging Controller that are physically a single unit.
These are all about PICS, and any arbitrary
interpretation of the standard would be a real no-no for all of us.
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.
[Jeong]
Yes. Any discussion on the idea is more than welcome.
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
|