Title of Invention

METHOD FOR TRIGGERING RE-NEGOTIATION OF SESSION IN A TARGET ACCESS NETWORK WHEN AN ACCESS TERMINAL MOVES FROM A SOURCE ACCESS NETWORK TO THE TARGET ACCESS NETWORK HAVING DIFFERENT CAPABILITY IN A HIGH RATE PACKET DATA SYSTEM

Abstract The invention relates to a method for triggering re-negotiation of session when an Access Terminal moves from one access network (source AN) to another (target AN) of different capabilities in high rate packet data system. According to a preferred embodiment of the invention, Source AN is allowed to store all the protocol subtypes, protocols and applications that AT is capable of and also allowing AT to send this information in priority order during session negotiation and hence facilitating the transfer of this information from source AN to target AN during session transfer when AT moves from one AN to another AN. An alternate method is to let the AT send the protocol subtypes, protocols and applications and other AT capable information to target AN after it moves to new AN or by letting the Rev-A capable AN to query AT's capability information and then AT providing this information. The invention also proposes to effect the re-negotiation by introducing a revision (like Protocol revision) information in overhead information messages that AN broadcasts to all ATs.
Full Text FIELD OF TECHNOLOGY
This invention in general relates to the field of wireless mobile communication and in particular to cellular communication. It further associates with HRPD, EV-DO, CDMA2000, session negotiation, dormant handoff, etc. More particularly the invention relates to a method for triggering re-negotiation of session when an Access Terminal moves from one access network (i.e. source AN) to another (i.e. target AN) of different capabilities in high rate packet data system.
DESCRIPTION OF THE RELATED ART
In CDMA 2000 1x High Rate Packet Data (HRPD) systems as defined by 3GPP2, a region is divided into subnets and subnets may contain multiple cells with each cell being served by a Base Transceiver Station (BTS). A Cell is a physical grouping of one or more sectors that transmit the same power control command to an access terminal where each sector is a part of the access network that is identified as providing one CDMA channel. The Access Network (AN), i.e. the network equipment providing data connectivity between a packet switched data network (typically the Internet) and the Access terminal, typically controls multiple BTSs and covers one or more subnets. Access terminal (AT) is an entity, which a user can use to get a service from access network in HRPD system. AT may be connected to a computing device such as laptop or personal computer. It can also be a self-contained data device such as a personal digital assistant. Access network

(AN) in HRPD system contains the functionality such as session negotiation, resource allocation and mobility management among others.
In an HRPD network, each AT is assigned a Unicast Access Terminal Identifier (UATI) which is universally unique and is used to address the mobile when AN sends messages to AT. Whenever AT crosses a subnet (for eg: foot print of an AN), the AT sends a UATI Request message.
Figure 1 shows the structure of Sector ID/UATI and derivation of Subnet from Sector ID/UATI. The following can be observed.
• The Sector Id is divided into two portions. The 'n' MSBs represent the identifier for the subnet and the lower '128-n' bits identify a particular sector within a subnet.
• A subnet mask of length 'n' is a 128 bit value whose binary representation consists of 'n' consecutive Ts followed by (128-n' consecutive 'O's.
• The subnet from a Sector ID/UATI is obtained by performing a logical AND of the address and the subnet mask.
• Each sector advertises its Sector ID, which is also a 128-bit address. This is how the AT knows that it has entered the foot-print of a new subnet.
UATI has similar structure as Sector ID. Full UATI is of size 128 bits. UATI is subdivided into UATI 104 and UATI 024, which signify 104 most significant bits (MSB) and 24 least significant bits (LSBs) of UATI respectively. If AN doesn't send

UAT1104 and UATISubnetMask fields in UATIAssignment message, then they can be derived from SectorlD [127:24] and subnet mask of SectorParameters message of that particular sector.
AT sends UATI request message on Access Channel, which is the portion of the Reverse Channel that is used by access terminals to communicate with the access network when they do not have a traffic channel assigned (There is a separate Reverse Access Channel for each sector of the access network).
While sending UATI request message, AT includes the "ColorCode | UATI [23:0]" in the MAC layer header of every Access Channel capsule, where '|' denotes the concatenation operator. For Unicast packets, the MAC layer header of the Control Channel and Access Channel include the 'ColorCode | UATI[23:0]'.Color code is used because sending a 128-bit UATI takes too much space in the Access and Control Channel messages. The subnet part of the sector ID is compressed to an 8-bit color code and is used as an alias for the subnet address. When the subnet of the sector changes, the color code changes. This is shown in Fig. 2.
ColorCode is only 8-bits and therefore cannot be globally unique. It implies that Color Codes can be reused. The ColorCode re-use scheme must ensure that there is no sector that has two or more neighboring sectors which are in different subnets but which use same ColorCode. An example ColorCode re-use scheme is shown in Figure 3.

unce AI determines mat it nas crossed a suonet (or AN foot-print), then AT sends UATIRequest message to the new AN (which will be referred to as "target AN" henceforth) on access channel with UATIType = 10 in Access Terminal Identifier record (ATI record) of MAC header. Upon seeing the UATIRequest message, the target AN determines the address of the Source AN.
The target AN may be provisioned with a table that maps the to the address of the source AN. In particular, for each target AN sector, a table may be provisioned that maps the ColorCode of each of the Sector's adjacent subnets to the address of the AN responsible for the subnet. Hence the target AN determines the address of the Source AN that corresponds to the ColorCode received in the MAC layer header by performing a table look-up in the appropriate above mentioned table.
An example of call flow [2] for triggering the session retrieval and the actual session transfer from Source AN to target AN is shown in Fig. 4. The following stages are involved in the process
a. Once AT recognizes that it crossed AN (or subnet) footprint, AT sends UATI of an existing HRPD session (if available) to target AN. The UATI can be used as an identifier for the existing HRPD session when the target AN attempts to retrieve the existing HRPD session State Information from the source AN.

The target AN sends an A13-Session Information Request message to the source AN to request the HRPD session information for the AT. The A13-Session Information Request message shall include the received UATI, the Security Layer Packet and Sector ID. The target AN starts timer TA13req.
The source AN validates the A13-Session Information Request and sends the requested HRPD session information of the AT to the target AN in an A13-Session Information Response message. The target AN stops timer TA13req.
The AT and the target AN complete the establishment of the HRPD session. Depending on the state of the AT and the target AN, either an existing HRPD session may be re-established, or a new HRPD session may be initiated if required. This step may be null if no further over-the-air signaling is required.
The target AN sends an A13-Session Information Confirm to the source AN to indicate that the target AN has received the HRPD session information. Upon receipt of the A13-Session Information Confirm message, the source AN deletes the associated AT HRPD session information.
It is essential to mention here that the HRPD specification has various protocols each having many subtypes. Each protocol also has a default sub-type that is supported by all ATs and ANs, which are compliant to the HRPD specification [1].

HRPD specification has undergone a revision in which new subtypes for existing protocols and also new protocols and applications are introduced. By introducing the new protocol subtypes, new protocols and new applications, ATs capabilities are enhanced and also QoS for many applications is ensured. For the purpose of discussion here, we can call the first revision as Rev-0 and next revision as Rev-A.
Now, let us take the case of AT which is capable of Rev-A protocols but is powered up in Rev-0 AN and hence the session negotiated is all Rev-0 protocols. Now, if AT moves from Rev-0 AN foot-print to Rev-A AN foot-print, then AT can recognize this movement by recognizing the change of subnet (by looking at the overhead messages being transmitted by the sector of target AN). The following steps are executed after AT recognizes the subnet boundary crossing:
1. AT sends UATIRequest message to Target AN.
2. Target AN retrieves this ATs session from Source AN.
3. AT and AN continue using the session information and protocols that the Target AN retrieved from the Source AN.
The major problem experienced here is that even though both AT and target AN are capable of supporting advanced set of protocol subtypes, protocols and applications, they both continue using default set of protocols as negotiated by Rev-0 AN. Hence, AT and target AN are not able to use efficient/optimised procedures and QoS mechanisms provided in Rev-A of HRPD specification. This is despite the fact that Rev-A capable AT sends all the non-default subtypes for all

protocol types that it supports (in the order of preference) in Configuration Request messages during the session negotiation with Rev-0 HRPD AN.
The drawback here is that new HRPD session is not being re-negotiated to upgrade the session protocols to Rev-A even if the Rev-A capable HRPD AT moves to Rev-A capable AN after setting up the initial session in Rev-0 HRPD AN. This implies that efficient/optimised use of Rev-A protocol subtypes and improved QoS mechanisms are not possible even though both AT and AN are Rev-A capable.
As a solution to the above problem, the present invention proposes that, if Rev-A capable AT moves from Rev-0 AN to Rev-A AN, then the session needs to be re-negotiated between Rev-A capable target AN and Rev-A capable AT in order to facilitate negotiation of Rev-A protocol subtypes, protocols and applications for efficient operation which ensures better QoS capabilities also.
SUMMARY OF THE INVENTION
The primary object of the invention is therefore to provide a method for triggering re-negotiation of session when access terminal moves from one access network to another of different of capability in high rate packet data system.
It is another object of the invention to ensure that the efficient/optimised protocol subtypes, protocols and applications and improved QoS mechanisms being used through re-negotiation of session between Rev-A capable AT and Rev-A capable

It is yet another object of the invention to let the (Rev-0) Source AN to store all the protocol subtypes, protocols and applications that AT is capable of and then allowing AT to send this information in priority order during Session negotiation and hence facilitating the transfer of this information from source AN to target AN during session transfer when AT moves from one AN to another AN.
It is a further object of the invention to let the AT send the protocol subtypes, protocols and applications and other AT capable information to target AN after it moves to new AN or by letting the Rev-A capable AN to query AT's capability information and then AT providing this information
It is also an object of the invention effect the negotiation by introducing a revision (like Protocol revision) information in overhead information messages that AN broadcasts to all ATs.
Accordingly, a preferred embodiment of the invention provides a method for
triggering re-negotiation of session when access terminal (AT) moves from one
access network (source AN)) to another access network (target AN) of different of
capability in high rate packet data system, the method comprising the steps of:
(a) AT sending a UATI Request message to target AN with it's UATI in MAC
header of Access Channel capsule when AT recognizes that it has crossed
subnet boundary or AN foot print;

(b) target AN deriving the Source AN address from the UATI and initiating session transfer from Source AN to Target AN;
(c) source AN sending all the Session information along with all non-default subtypes of all protocol types and all Application Subtypes that the AT supports;
(d) source AN admitting the ATSupportedNonDefaultProtocolSubTypes parameter in the Session State Information record if the Source AN supports Extended Session State Information Record (ESSIR) defined in Inter-Operability Specification document;
(e) target AN checking whether both AN and AT can support better protocol subtypes, protocols and applications than the ones currently in use and hence initiating the session (re-)negotiation if both AT and AN are capable of advanced Protocol Types, Protocol Subtypes and Application Subtypes; and
(f) AN and AT continuing to use the re-negotiated Protocol Types, Protocol Subtypes and Application Subtypes.
An alternate embodiment of the invention provides a method for triggering re-negotiation of session when access terminal (AT) moves from one access network (source AN) to another access network (target AN) of different capability in high rate packet data system, the method comprising the steps of:
a) AT sending UATI Request message to Target AN after determining that it has crossed subnet boundary or AN foot print;
b) Target AN deriving the Source AN address from the UATI and retrieving the

session from Source AN;
c) AT sending the information related to all supported non-default subtypes for all protocols Types and all supported application subtypes and any other relevant capability information to target AN After UATIRequest and UATIAssignment transactions;
d) Target AN checking whether both AN and AT can support enhanced protocol subtypes, protocols and applications and initiating session re-negotiation if both AT and AN are capable of enhanced protocol subtypes, protocols and applications; and
e) AN and AT continuing to use the re-negotiated protocol subtypes, protocols and applications.
Yet another embodiment of the invention confers a method for triggering re-negotiation of session when access terminal (AT) moves from one access network (source AN)) to another access network (target AN) of different of capability in high rate packet data system, the method comprising the steps of:
a) AN broadcasting the information related to the minimum and maximum revisions that it supports in overhead information messages like sector parameter message;
b) AT checking the minimum and maximum revisions that the AN supports and comparing that with it's capabilities and also with the current HRPD session parameters;
c) Initiating the session re-negotiation If AT determines that session needs to be re-negotiated; and

d) AN and AT continuing to use the re-negotiated protocol subtypes, protocols and applications.
These and other objects, features and advantages of the present invention will become more readily apparent from a reading of the following detailed description taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 shows the SectorlD/UATI structure, which illustrates Subnet.
Figure 2 shows the SectorlD structure, which illustrate ColorCode.
Figure 3 illustrates ColorCode re-use.
Figure 4 shows Session transfer from Source AN to Target AN.
DETAILED DESCRIPTION OF THE INVENTION
A preferred embodiment of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiment is merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to

provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
The diagrams and message sequences are shown only to illustrate the example scenario/sequence and may not be the actual set of messages that are exchanged. Timers and other negative scenarios are not fully captured in the diagrams, as these are not critical for illustrating the invention. Also the description or identification of fields in each message is not critical for illustrating the invention. Only, the description of the message is understood when one goes through the steps of the related art.
The invention suggests that if Rev-A capable AT moves from Rev-0 AN to Rev-A AN, then the session needs to be re-negotiated between Rev-A capable target AN and Rev-A capable AT in order to facilitate negotiation of Rev-A protocol subtypes, protocols and applications for efficient operation which ensures better QoS capabilities also. According to a preferred embodiment of the invention, Source AN is allowed to store all the protocol subtypes, protocols and applications that AT is capable of and also allowing AT to send this information in priority order during Session negotiation and hence facilitating the transfer of this information from source AN to target AN during session transfer when AT moves from one AN to another AN.

Here, a new Parameter Record is to be included in Session State Information Record (SSIR) and is to be carried in A13-Session Information Response [2] when source AN is transferring session to target AN (see Fig 4) is defined. The Session State Information is to be used for transferring the session parameters corresponding to the InUse protocol instances from a source access network to a target access network. Session parameters are the attributes and the internal parameters that define the state of each protocol. This parameter record consists of all AT supported non-default subtypes of all protocol Types. Also, we define a new attribute record, which will carry all AT supported Application Subtypes. This new attribute is to be sent by Rev-A AT mandatorily. Being an attribute, AT Supported Applications information is automatically included in the SSIR when Source AN is transferring session information to Target AN when AT moves from one AN to another AN.
During the session negotiation, the access terminal includes, in the Configuration Request messages, all supported non-default subtypes of all protocols Types. Subsequently, Rev-A capable access terminal sends all the supported Application Subtypes in the ATSupportedApplicationSubtypes attribute and AN stores this information along with other session information. AN need not store HardLink subtype. It is to be noted here that according to the prior art, AN stores only the agreed protocol Subtypes as part of the session information. But the procedure according to the invention mandates the access network to store all non-default Subtypes of all protocol Types that are supported by the access terminal. Also in the prior art, AN does not have information about all the Application Subtypes that

the access terminal supports. In the new procedure, we have introduced a new attribute ATSupportedApplicationSubtypes for this purpose.
The detailed steps are as follows:
When AT recognizes that it crossed subnet boundary or AN foot print, then
AT sends UATI Request message to target AN with it's UATI in MAC header
of Access Channel capsule
Target AN derives Source AN address from the UATI and initiates session
transfer from Source AN to Target AN
Source AN sends all the Session information along with all non-default
subtypes of all protocol types and all Application Subtypes that this AT
supports. The ProtocolSubtypes for a protocol Type shall be in the same
order that the access terminal has sent in the ConfigurationRequest
messages.
Source AN includes the ATSupportedNonDefaultProtocolSubTypes
parameter in the Session State Information record if the Source AN supports
Extended Session State Information Record (ESSIR) defined in
Inter-Operability Specification document [2]
Target AN checks if both AN and AT can support better protocol subtypes,
protocols and applications than the ones currently in use and initiates
session (re-)negotiation if both AT and AN are capable of advanced Protocol
Types, Protocol Subtypes and Application Subtypes.

6. AN and AT continue using the re-negotiated Protocol Types, Protocol Subtypes and Application Subtypes.
The new parameter record (sent as SSIR) is defined as follows: ATSupportedNonDefaultProtocolSubTvpes parameter:

ParameterType This field shall be set to 0x02 for this parameter record.
Length This field shall be set to the length of this parameter record in
units of octets excluding the Length field.
ProtocolType This field has the following format:

TypeLength The sender shall set this field to '0' if the Type field is 7 bits long.
Otherwise, the sender shall set this field to T.

Typel This sub-field shall be set to the seven most significant bits of
the Type value for the protocol to which the associated ProtocolSubtypes belong to.
Type2 If the length of the Type value for the protocol associated with
the encapsulated parameter is 7 bits, then this sub-field shall be omitted. Otherwise, this field shall be set to the 8 least significant bits of the Type value for the protocol to which the associated ProtocolSubtypes belong to.
NumProtocolSubtypes
This field shall be set to the number of occurrences of the ProtocolSubtype field following this field in this record.
ProtocolSubtype This field shall be set to the non-default subtype of the protocol
Type encapsulated in this record. This field shall not be set to the HardLink subtype. The ProtocolSubtypes for a protocol

Type shall be in the same order that the access terminal has sent in the ConfigurationRequest messages.
ATSupportedApplicationSubtvpes Attribute:

Length Length of the complex attribute in octets. The access terminal
shall set this field to the length of the complex attribute excluding the Length field.
AttributelD The access terminal shall set this field to 0x1001.
Value ID The access terminal shall set this field to an identifier assigned
to this complex value.

NumAppSubtypes This field shall be set to the number of occurrences of the
ApplicationSubtype field following this field in this record.
ApplicationSubtype This field shall be set to the Application Subtype that the
access terminal supports.
Method-2:
According to alternate method of the invention, AT sends it's capability information (like all supported non-default subtypes for all protocols Types and all supported application subtypes) to target AN after it crosses AN foot print or subnet boundary.
The detailed steps are as follows:
1. After AT determines that it crossed subnet boundary or AN foot print, it sends UATIRequest message to Target AN
2. Target AN derives the Source AN address from the UATI and retrieves the session from Source AN;
3. After UATIRequest and UATIAssignment transaction, AT sends the information related to all supported non-default subtypes for all protocols Types and all supported application subtypes and any other relevant capability information to target AN
a. This step can be restricted only when AT is moving from one AN to another AN and the AT has default subtypes configured for all

protocols Types and Applications and if the access terminal supports non-default subtype for any protocol Type or Application Subtype, b. Also this step can be executed by AT voluntarily or upon Query from from the target AN (which could be rev-A capable AN). Target AN can query for this information if the access terminal has default subtypes configured for all protocols Types and Application Subtypes and if the access network supports non-default subtype for any protocol Type or Application Subtype.
4. Target AN checks if both AN and AT can support enhanced protocol subtypes, protocols and applications than the ones currently in use and initiates session re-negotiation if both AT and AN are capable of enhanced protocol subtypes, protocols and applications.
5. AN and AT continue using the re-negotiated protocol subtypes, protocols and applications.
The following message structures shows the possible message structure for Query message from AN and response message from AT.
ATNonDefaultSubtvpesPorotocolsQuerv message:
The access network sends this message when it wants to know the protocol subtypes supported by the access terminal.


MessagelD The access network shall set this field to 0x09.
TransactionID The access network shall increment this value modulo 256 for
each new ATNonDefaultSubtypesPorotocolsQuery message sent.
ATSupportedNonDefaultProtocolSubTvpes message:
The access terminal sends this message in response to ATNonDefaultSubtypesPorotocolsQuery message.


MessagelD The access terminal shall set this field to 0x0a.
TransactionlD The access terminal shall set this field to the Transactionl D
field of the corresponding ATNonDefaultSubtypesPorotocolsQuery message sent.
TypeLength The sender shall set this field to '0' if the Type field is 7 bits long.
Otherwise, the sender shall set this field to '1'.

ProtocolType This field has the following format:

Typel This sub-field shall be set to the seven most significant bits of
the Type value for the protocol to which the associated ProtocolSubtypes belong to.
Type2 If the length of the Type value for the protocol associated with
the encapsulated parameter is 7 bits, then this sub-field shall be omitted. Otherwise, this field shall be set to the 8 least significant bits of the Type value for the protocol to which the associated ProtocolSubtypes belong to.
NumProtocolSubtypes
This field shall be set to the number of occurrences of the ProtocolSubtype field following this field in this record.
ProtocolSubtypes This field shall be set to the non-default subtypes of the
protocol Type encapsulated in this record. The ProtocolSubtypes for a protocol Type shall be in the same order that the access terminal has sent in the ConfigurationRequest messages.

NumAppSubtypes This field shall be set to the number of occurrences of the
ApplicationSubtype field following this field in this record.
ApplicationSubtype
This field shall be set to the Application Subtype that the access terminal supports.
Met hod-3:
In yet another embodiment of the invention revision information, which will get incremented after every revision to HRPD protocols, is introduced. This revision information reflects the various sets of protocols and their subtype configurations, which will reflect various capabilities of those configurations. It comprises of the following steps.
1. AN broadcasts the information related to the minimum and maximum revisions that it supports in overhead information messages like sector parameter message.
2. AT checks the minimum and maximum revisions that the AN supports and compares that with it's capabilities and also with the current HRPD session parameters
3. If AT determines that session needs to be re-negotiated, then AT initiates session re-negotiation.

4. Once session re-negotiation is over, AN and AT continue using the re-negotiated protocol subtypes, protocols and applications.
It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a computer, mobile communication device, mobile server or a multi function device.
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from.



WE CLAIM
1. A method for triggering re-negotiation of session when access terminal (AT) moves from one access network (source AN) to another access network (target AN) of different of capability in high rate packet data system, the method comprising the steps of:
(a) AT sending a UATI Request message to target AN with it's UATI in MAC header of Access Channel capsule When AT recognizes that it has crossed subnet boundary or AN foot print;
(b) target AN deriving the Source AN address from the UATI and initiating session transfer from Source AN to Target AN;
(c) source AN sending all the Session information along with all non-default subtypes of all protocol types and all Application Subtypes that the AT supports;
(d) source AN admitting the ATSupportedNonDefaultProtocolSubTypes parameter in the Session State Information record if the Source AN supports Extended Session State Information Record (ESSIR) defined in Inter-Operability Specification document;
(e) target AN checking whether both AN and AT can support better protocol subtypes, protocols and applications than the ones currently in use and hence initiating the session (re-) negotiation if both AT and AN are capable of advanced Protocol Types, Protocol Subtypes and Application Subtypes; and
(f) AN and AT continuing to use the re-negotiated Protocol Types, Protocol Subtypes and Application Subtypes.

2. A method for triggering re-negotiation of session when access terminal (AT)
moves from one access network (source AN)) to another access network (target
AN) of different of capability in high rate packet data system, the method
comprising the steps of:
(a) AT sending UATIRequest message to Target AN after determining that it has crossed subnet boundary or AN foot print;
(b) Target AN deriving the Source AN address from the UATI and retrieving the session from Source AN;
(c) AT sending the information related to all supported non-default subtypes for all protocols Types and all supported application subtypes and any other relevant capability information to target AN After UATIRequest and UATIAssignment transactions;
(d) Target AN checking whether both AN and AT can support enhanced protocol subtypes, protocols and applications than the ones currently in use and initiating session re-negotiation if both AT and AN are capable of enhanced protocol subtypes, protocols and applications; and
(e) AN and AT continuing to use the re-negotiated protocol subtypes, protocols and applications.
3. A method for triggering re-negotiation of session when access terminal (AT)
moves from one access network (source AN)) to another access network (target
AN) of different of capability in high rate packet data system, the method
comprising the steps of:

(a) AN broadcasting the information related to the minimum and maximum revisions that it supports in overhead information messages like sector parameter message;
(b) AT checking the minimum and maximum revisions that the AN supports and comparing that with it's capabilities and also with the current HRPD session parameters;
(c) initiating the session re-negotiation If AT determines that session needs to be re-negotiated; and
(d) AN and AT continuing to use the renegotiated protocol subtypes, protocols and applications.
4. A method for triggering re-negotiation of session when access terminal (AT) moves from one access network (source AN)) to another access network (target AN) of different of capability in high rate packet data system, substantially as herein above described and illustrated with reference to the accompanying drawings.

Documents:

433-CHE-2005 AMENDED CLAIMS 17-10-2012.pdf

433-CHE-2005 AMENDED PAGES OF SPECIFICATION 17-10-2012.pdf

433-CHE-2005 CORRESPONDENCE OTHERS 30-10-2012.pdf

433-CHE-2005 EXAMINATION REPORT REPLY RECEIVED 17-10-2012.pdf

433-CHE-2005 FORM-1 17-10-2012.pdf

433-CHE-2005 FORM-3 17-10-2012.pdf

433-CHE-2005 POWER OF ATTORNEY 17-10-2012.pdf

433-CHE-2005 POWER OF ATTORNEY 30-10-2012.pdf

433-CHE-2005 AMENDED CLAIMS 27-09-2012.pdf

433-CHE-2005 AMENDED PAGES OF SPECIFICATION 27-09-2012.pdf

433-CHE-2005 EXAMINATION REPORT REPLY RECEIVED 27-09-2012.pdf

433-CHE-2005 EXAMINATION REPORT REPLY RECEIVED 31-10-2012.pdf

433-CHE-2005 FORM-13 27-09-2012.pdf

433-CHE-2005 FORM-3 27-09-2012.pdf

433-CHE-2005 OTHER PATENT DOCUMENT 27-09-2012.pdf

433-CHE-2005 OTHER PATENT DOCUMENT 1 27-09-2012.pdf

433-CHE-2005 POWER OF ATTORNEY 27-09-2012.pdf

433-CHE-2005 FORM-13 19-06-2006.pdf

433-che-2005-abstract.pdf

433-che-2005-claims.pdf

433-che-2005-correspondnece-others.pdf

433-che-2005-description(complete).pdf

433-che-2005-description(provisional).pdf

433-che-2005-drawings.pdf

433-che-2005-form 1.pdf

433-che-2005-form 13.pdf

433-che-2005-form 26.pdf

433-che-2005-form 5.pdf


Patent Number 255696
Indian Patent Application Number 433/CHE/2005
PG Journal Number 12/2013
Publication Date 22-Mar-2013
Grant Date 15-Mar-2013
Date of Filing 15-Apr-2005
Name of Patentee SAMSUNG INDIA SOFTWARE OPERATIONS PVT.LTD
Applicant Address BAGMANE LAKEVIEW,BLOCK B NO.66/1 BAGMANE TECH PARK,C.V.RAMAN NAGAR,BYRASANDRA BANGALORE 560 093
Inventors:
# Inventor's Name Inventor's Address
1 RICHA DAM EMPLOYED AT SAMSUNG ELECTRONICS CO., LTD, INDIA SOFTWARE OPERATIONS (SISO), HAVING ITS OFFICE AT, J.P. TECHNO PARK, 3/1, MILLERS ROAD, BANGALORE 560 052, KARNATAKA, INDIA
2 VADLAPUDI TSV PRASAD EMPLOYED AT SAMSUNG ELECTRONICS CO., LTD, INDIA SOFTWARE OPERATIONS (SISO), HAVING ITS OFFICE AT, J.P. TECHNO PARK, 3/1, MILLERS ROAD, BANGALORE 560 052, KARNATAKA, INDIA
PCT International Classification Number G06F1/00
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA