Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] Request for clarification: Idle mode retain information Bit #6



Ronny,

I think the interpretation of "Full service" in Bit #6 is a matter of
consensus that we're going to make. I'm sure this is true at least for
the idle mode retain information. If there is consensus for the bit in
the HO optimazation case, that might be helpful to us although we're not
necessarily constrained by that.

I submitted a comment with regard to this issue. We can discuss and
resolve this issue at San Antonio.

Thank you,

Jeong
________________________________

From: Ronny (Yong-Ho) Kim [mailto:ronnykim@lge.com]
Sent: Wednesday, November 03, 2004 11:02 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



My interpretation of Bit #6 is exclusion of services associated with
other retaining information. If you interpret Bit #6 "Full service" as
including all the services related with Bits #0-#5, then similarly Bit
#6 in HO Optimization flags should be interpreted in the same way.
However bit #6 is not interpreted that way. I think Bit#6 "full service"
should be interpreted as additional information - along with network
address (IP address) - needed to make IP packet arrive either to the
last attached BS or Paging Controller. Therefore, technically we can
have all possible combinations with 6 different bits.





Thanks,

Ronny



-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]
Sent: Thursday, November 04, 2004 2:23 PM
To: STDS-802-16@listserv.ieee.org
Subject: 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.

*************************************************************