Re: [STDS-802-16] Request for clarification: Idle mode retain information Bit #6
Hi Ronny, Phil and all:
Thank you for the kind explanation, Ronny.
Now we have two questions:
Q1. Is Bit #2 meaningful when Bit #6 is set (to 1)?
Q2. Is Bit #2 meaningful when Bit #6 is unset?
There seems to be no disagreement in that the answer to Q2 is YES. But,
regarding Q1, Ronny's answer is YES while Phil's is NO.
To resolve this problem, we need consensus on the following issues:
1. Interpretation of "Full service" in Bit #6
If "Full service" excludes the services associated with SBC-REQ/RSP,
PKM-REQ/RSP, REG-REQ/RSP, Network Address, Time of Day, and TFTP (as
opposed to the meaning of "Full service"), then the answer to Q1 would
be YES.
Otherwise (that is, if it includes all the services related with Bits
#0-#5 and possibly something more), the answer would be dependent on the
consensus on the second issue below.
2. Priority of Bit #6 over Bits #0-#5
Let's assume that we had consensus that Full service includes all the
services related with Bits #0-#5 with something more, and consider the
case when Bit #6 is set to 1.
If Bit #6 has higher priority over Bits #0-#5, then Bit #6 is enough to
determine what kind of resources are to be retained; Bits #0-#5 is just
meaningless (this is the case what Phil said, I think), and the answer
to Q1 is NO.
If Bit #6 has lower priority, then theoretically, we can make the Bits
#0-#5 to be meaningful by not retaining the resource associated with the
Bits having the value of 0 (I think this is the case what Ronny
demonstrated with reference to Bit #2 and Bit #6). Although
theoretically possible, I failed to see any practical significance of
doing this. Even in Ronny's demonstration, it was necessary to set Bits
#2 and #6 at the same time if we want to have practical significance
(that is, to receive DL traffic).
In summary, I agree with the interpretation of "Full service" as
including all the services related with Bits #0-#5. I also agree with
the idea that prioritizes Bit #6 over Bits #0-#5.
What seems certain is that we need a little more work to remove the
ambiguities about Idle mode retain information Bits. I'll be honored if
I can do that job.
Thank you,
Jeong
--
Moo Ryong Jeong, Ph. D
DoCoMo Communications Laboratories USA, Inc.
-----Original Message-----
From: Ronny (Yong-Ho) Kim [mailto:ronnykim@lge.com]
Sent: Tuesday, November 02, 2004 7:57 PM
To: Moo Ryong Jeong; STDS-802-16@listserv.ieee.org
Subject: RE: [STDS-802-16] Request for clarification: Idle mode retain
information Bit #6
Jeong
IF Bit#6 is set 0 and CS classifier information is not retained, BS (or
Paging Controller) can not take packets, IP packets to be more specific,
from the network. If BS can not take IP packets from the network, no DL
traffic will be delivered to Idle Mode MSSs. If MSS wants to receive DL
traffic from the network then MSS should request to set bit#3 and bit#6
at
the same time.
Thank you,
Ronny
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]
Sent: Wednesday, November 03, 2004 12:39 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Request for clarification: Idle mode retain
information Bit #6
Phil and all,
Thank you for the kind and prompt reply.
If no one disagree with Phil, wouldn't it be better to explicitly
require Bit #6 to be 0 so as for the Bits #0-#5 to be interpreted as in
the current draft?
If we do so, we'll have additional 64 reserved combinations of Bits
#0-#5 (when Bit #6 is 1) that can be used for further optimizations,
which may be necessary in the future.
As to Bit #7, I'm preparing a proposal of using the bit to limit the
resource retention when Bit #2 or Bit #6 is set so that only the
resource of the service flows with positive Resource Retention
Preference (or Paging Preference) should be retained.
Thank you,
Jeong
--
Moo Ryong Jeong, Ph. D
DoCoMo Communications Laboratories USA, Inc.
-----Original Message-----
From: Phillip Barber [mailto:pbarber@broadbandmobiletech.com]
Sent: Tuesday, November 02, 2004 2:58 PM
To: Moo Ryong Jeong; STDS-802-16@listserv.ieee.org
Cc: Ronny Kim; Kim Minsung; ???; Chulsik Yoon; Mo-Han Fong
Subject: Re: Request for clarification: Idle mode retain information Bit
#6
I think that setting Bit#6 to '1' is just like setting Bits#0-5 to '1'
PLUS it includes retention of other stateful elements like MAC state
machines, counters, CS classifiers, etc...
So when Bit#6 is set to '1', the values for all other Bits are
meaningless.
Thanks,
Phil
----- Original Message -----
From: "Moo Ryong Jeong" <jeong@docomolabs-usa.com>
To: <ronnykim@lge.com>; <cyberk@kt.co.kr>;
<pbarber@BROADBANDMOBILETECH.COM>; <jungje.son@samsung.com>;
<csyoon@etri.re.kr>; <mhfong@nortelnetworks.com>;
<STDS-802-16@listserv.ieee.org>
Cc: "Toshiro Kawahara" <kawahara@docomolabs-usa.com>
Sent: Tuesday, November 02, 2004 4:26 PM
Subject: Request for clarification: Idle mode retain information Bit #6
Hi all,
Can anybody clarify the usage of idle mode retain information Bit #6?
When the bit is set (to 1), is it possible for any other bit (that is,
any of the Bits #0-#5) to be unset?
The answer appears dependent on the interpretation of the term "Full
service." If "Full service" excludes the services associated with
SBC-REQ/RSP, PKM-REQ/RSP, REG-REQ/RSP, Network Address, Time of Day, and
TFTP (as opposed to the meaning of "Full service"), then the answer
would be YES. Otherwise (that is, if it includes all the services
related with Bits #0-#5 and possibly something more), the answer would
be NO.
Thanks,
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
**********************Confidentiality Note**********************
Privileged/Confidential Information may be contained in this e-mail and
any attachment to it and may be covered by existing non-disclosure or
confidentiality agreements. If you are not the addressee (or authorized
to receive for the addressee), you may not use, copy or disclose to
anyone any information contained in this e-mail. If you have received
this e-mail in error, please notify the sender immediately by reply
e-mail and delete it from your system. Thank you very much.
*************************************************************