Title of Invention

METHOD FOR INTER-WORKING IN A MULTI PROTOCOL REVISION BASED ON EVOLUTION DATA OPTIMIZED (EVDO) COMMUNICATION SYSTEMS

Abstract The invention explains a system and method for interworking in a multi-protocol revision based EVDO communication system is described. In this scheme, session configuration can be performed by access terminal (AT) and access network (AN) in multi-protocol scenario. AT maintains a set indicating all the protocol revisions it supports. AT and AN start their session negotiation with the subtypes corresponding to the highest protocol revision supported by AT and AN.There are two scenarios in which AT sends the Unicast Access Terminal Identifier (UATI) request message with protocol revisions: power up and idle handoff.
Full Text FIELD OF THE INVENTION
The present invention, in general, relates to the field of mobile communication technology. The invention relates to EVDO and its evolved communication systems having multiple protocol revisions. It describes a system and method for efficiently operating in a system in which the access terminal is moving across access networks supporting different protocol revisions. More particularly, the invention relates to a system and method for inter-working in a multi protocol revision based EVDO communication systems.
DESCRIPTION OF RELATED ART
The EVDO communication system consists of several protocols and applications which define the procedures to be followed by the access network (AN) and the access terminal (AT) to communicate with each other. Each protocol/application has several subtypes. A subtype of a protocol/application defines a distinct procedure to be used for the operation of that protocol/application. Each subtype of a protocol/application contains several configurable attributes which governs its operation. The EVDO communication system provides procedure to negotiate and configure the protocol/application subtypes and their corresponding attributes between the AT and AN. Configuration Request and Configuration Response messages are exchanged between AT and AN to negotiate protocol/application subtypes and their corresponding attributes.

The set of negotiated and configured protocol/application subtypes and the corresponding attributes constitutes an EVDO session. In other words, an EVDO session refers to a shared state between the AT and the AN. This shared state stores the protocols/applications and the protocol/application configurations that were negotiated and are used for communications between the AT and the AN. Session configuration protocol (SCP) defines the procedure to negotiate and configure multiple EVDO sessions. These multiple EVDO sessions negotiated and configured by SCP are also referred to as multiple personalities. Each personality configured is identified by a personality index. At a given point of time only one personality will be in use between AT and AN. The personality index in use is stored in session configuration token (SCT).
Each protocol/application can have two instances, InConfiguration and InUse instances. An InUse instance is the working instance of a protocol/application. At the time of power-up, EVDO session constitutes default set of Protocol and Application subtypes and also default values for attributes of these Protocols and Application subtypes. An InConfiguration instance of each protocol/application is created by SCP when the session negotiation is initiated. Once the session negotiation is complete, the configured values of the InConfiguration instances are stored by AT and AN at a given personality index. After configuring the multiple sessions, AN informs the AT about the session to be used using a configuration complete or soft configuration complete message (personality index

corresponding to the session to be used is encoded in session configuration token which is sent in configuration complete or soft configuration complete message).
Session configuration can be initiated by AT or AN.
A protocol revision defines a default set of protocol/application subtypes, which are used by AT until the session configuration. In the current EVDO system, only one default set of protocol/application subtype exists. At the time of Power Up, AT creates InUse Instances corresponding to this default set of protocol subtypes. AT's InUse instances are changed from the default to non-default subtypes only by session negotiation.
LIMITATIONS
■ In the current EVDO communication system only one default set of protocol/application subtypes exists. At power up the access terminal creates InUse instances corresponding to the default set of protocol/application subtypes. AT's InUse instances can be changed from default to non-default subtypes only by session negotiation.
■ In a multi-protocol revisions system, there is need to have multiple default sets of protocols. So that the new deployments can directly operate on a system specific to a protocol revision without having to support all previous

revisions of the system. Even AT's can be implemented only for some protocol revisions.
■ In the current system there are no defined procedures for interworking in a system in which AT is moving across the ANs supporting different protocol revisions of the system.
Therefore, there is a need in the art for techniques or mechanisms which will allow AT and AN to operate efficiently in a multi protocol revision system.
SUMMARY OF THE INVENTION
The current approach of configuring session in EVDO communication systems is modified such that in the systems with multiple protocol revisions, AT and AN can start their session negotiation with the subtypes corresponding to the highest protocol revision supported by AT and AN. In the special case of using default values for all the subtypes, session negotiation itself can be avoided. The invention also proposes a method to communicate between AT and AN about the protocol revisions supported by each.
Accordingly this invention explains a method for inter-working in a multi protocol revision based EVDO communication systems comprising the steps of:

performing a session configuration by access terminal (AT) and access network (AN);
maintaining a set by AT indicating all the protocol revisions said AT supports; and
AT and AN performing session negotiation with the subtypes corresponding to a maximum protocol revision supported by AT and AN,
wherein AT sends a Unicast Access Terminal Identifier (UATI) request message with protocol revisions using power up and idle handoff procedures.
Accordingly this invention explains a system for inter-working in a multi protocol revision based EVDO communication systems comprising :
access terminal (AT) and access network (AN) performing a session configuration; and
means for maintaining a set by AT indicating all the protocol revisions said AT supports and said AT and AN performing session negotiation by AT and AN with the subtypes corresponding to a maximum protocol revision supported by AT and AN,
wherein AT sends a Unicast Access Terminal Identifier (UATI) request message with protocol revisions using power up and idle handoff procedures.
Other objects, features, and advantages of the present invention will become more apparent from the ensuing detailed description of the invention, taken in

conjunction with the accompanying drawings, which depicts the flowchart of the various stages of the methods involved, eventually leading to audio externalization.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 depicts AT Power procedures in a multi protocol revision based systems.
Figure 2 depicts Idle Handoff procedures for scenario 1 in a multi protocol revision based systems.
Figure 3 depicts Idle Handoff procedures for scenario 2 in a multi protocol revision based systems.
Figure 4 depicts Idle Handoff procedures for scenario 3 in a multi protocol revision based systems.
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. However, it should be understood that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. Therefore the details disclosed herein are not to be

interpreted as limiting but merely as the basis for the claims and as a basis for teaching one skilled in the art how to make or use the invention.
In a system with multiple protocol revisions, the system defines different default sets of protocol/application subtypes corresponding to the each protocol revision that the system supports. This information can be used by AT and AN to perform an efficient session negotiation.
AN transmits the information about the protocol revisions supported by it in a broadcast message. After acquiring the system AT gets the information about the protocol revisions supported by AN from the broadcast message transmitted by AN.
When access terminal supports one or more protocol revisions of the system, it maintains a set indicating all the protocol revisions it supports. AT calculates the maximum protocol revision supported by AT and AN according to the following equation.
max_supported_prev = Maximum ({Set of protocol revisions supported by both AT
and AN})
Where,
{Set of protocol revisions supported by both AT and AN} =

{Protocol revisions supported by AT} (1 {Protocol revisions supported by AN}
Equation 1 Maximum Protocol Revision Supported -
AT also maintains a variable 'prev_in_use' which indicates the protocol revision which is being used by AT to communicate with the AN. During power up procedures AT sets 'prev_in_use' to 'max_supported_prev' and creates the InUse instances of the applications and protocol subtypes meant for the system corresponding to the prev_in_use. Then AT sends an UATI request message by including all the protocol revisions that it supports and the selected prev_in_use. Along with UATI request message AT also sends Session Configuration Token (SCT) being used by AT. SCT indicates whether AT is using a default or configured session. If AN has the knowledge about neighbour networks with different protocol revisions, AN can configure a separate personality for each protocol revision that both AT and AN supports as part of the session negotiation. This negotiation can be used by AT and AN during Handoff to neighbour networks.
When AT receives new SCT after session negotiation/personality switch, it has to update the prev_in_use to a protocol revision corresponding to the personality index received in SCT.
There are two scenarios in which AT sends the UATI request message with protocol revisions during 1. Power up

2. Idle handoff to a system with different protocol revision
Power Up Procedures-
AT Procedures: When AT powers up it performs the following operations
1. It sets the 'prev_in_use' to NONE (a predefined value ex., OxFFFF).
2. It sets the Session Configuration Token to NONE (a predefined value ex., OxFFFF)
3. Obtains the AN supported protocol revisions by monitoring broadcast messages
4. AT calculates the max_supported_prev and sets prev_in_use = max_supported_prev
5. AT creates InUse instances of the protocols corresponding to the default set for 'prev_in_use'
6. AT sends UATI request message by including AT supported protocol revisions and 'prev_in_use'. As part of UATI request message transmission, SCT and RATI also get transmitted in the MAC header.
AN Procedures:
1. When AN receives UATI request message, it checks the SCT and RATI.
a. RATI indicates that AT is not having any configured session.
b. SCT == NONE, indicates that AT is using default protocol set
corresponding to prev_in_use.

2. AN will initiate the session configuration.
a. AN can configure multiple personalities, corresponding to each
protocol revision supported by AT
b. AN sets SCT to the personality to be used.
Idle Handoff Procedures - When AT roams in a network, it performs idle handoffs across the cell boundaries and network boundaries. After idle handoff to a system/network with different protocol revision, AT obtains the protocol revisions supported by AN by monitoring broadcast messages and calculates the max_supported_prev by using Equation 1 above.
There are different scenarios for these procedures. Detailed procedure for each scenario is explained below.
Idle Handoff Scenario 1:
AT has an established session with the old AN and has moved to a new AN. prev_in_use is supported by new AN and prev_in_use is equal to max_supported_prev between AT and new AN.
AT Procedures:

1. Send UATI request message with AT supported protocol revisions and prev_in_use. As part of UATI request message transmission, SCT and UATI also get transmitted in the MAC header.
AN Procedures:
1. AN receives UATI request message and checks SCT
2. UATI received in MAC header indicates that AT is having a session
3. SCT!= NONE, indicates that AT is using a personality corresponding to the personality index indicated by SCT.
4. AN will get the AT's session information from old AN.
5. AN will store the session information received from old AN
6. As AT is already using the personality corresponding to 'Max_Supported_Prev\ there is no need to switch personality.
7. However, AN may do a session configuration
a. To change some parameters of InUse personality and/or
b. To create a new personality corresponding to a protocol revision
(supported by both AT and AN) which is not existing.
8. AN will send a session close and configure a new session if new AN is not
able to retrieve AT's session information from old AN
The detailed call flow is shown in Figure 2. Idle Handoff Scenario 2:

AT has an established session with old AN and has moved to a new AN. prev_in_use is supported by new AN and prev_in_use is not equal to max_supported_prev between AT and new AN. AT Procedures:
1. Send UATI request message with AT supported protocol revisions and prev_in_use. As part of UATI request message transmission, SCT and UATI also get transmitted in the MAC header. AN Procedures:
1. AN receives UATI request message and checks SCT.
2. UATI received in MAC header indicates that AT is having a session
3. SCT! = NONE indicates that AT is using a personality corresponding to the personality index indicated by SCT.
4. AN will get the AT's session information from old AN.
5. AN will store the session information received from old AN
6. At this stage, AN and AT continue to work with personality corresponding to prev_in_use
7. prev_in_use as received in UATI message indicates that AT is not using the personality corresponding to 'max_supported_prev'
8. If AT already has a personality corresponding to 'max_supported_prev'
a. AN will switch the AT's InUse personality to the personality corresponding to 'max_supported_prev'
9. If AT doesn't have a personality corresponding to 'max_supported_prev'

a. AN will create a personality corresponding to max_supported_prev and will switch AT to new personality corresponding to max_supported_prev 10. AN may also do a session configuration
a. To change some parameters of InUse personality and/or
b. To create a new personality corresponding to a protocol revision
(supported by both AT and AN) which is not existing.
1 LAN will send a session close and configure a new session if new AN is not able to retrieve AT's session information from old AN
Idle Handoff Scenario 2 (Alternate Procedure -1):
AT Procedures:
1. Set prev_in_use = max_supported_prev
2. Set SCT= NONE (i.e., OxFFFF)
3. Create the InUse Instances of the protocols corresponding to the default set of 'prev_in_use'
4. Send UATI request message with AT supported protocol revisions and 'prev_in_use'. As part of UATI request message transmission, SCT and UATI also get transmitted in the MAC header.
AN Procedures:

i. AN receives UATI request message and checks SCT.
2. UATI received in MAC header indicates that AT is having a session
3. SCT == NONE, 'prev_in_use' indicates that AT is using default set corresponding to 'prev_in_use'
4. AN will get the AT's session information from old AN.
5. AN will store the session information received from old AN
6. If AT already has a personality corresponding to 'max_supported_prev'
a. AN will switch the AT's InUse personality to the personality
corresponding to 'max_supported_prev'
7. If AT doesn't have a personality corresponding to 'max_supported_prev'
b. AN will create a personality corresponding to 'max_supported_prev'
and will switch AT to new personality corresponding to
'max_supported_prev'
8. AN may also do a session configuration
a. To change some parameters of InUse personality and/or
b. To create a new personality corresponding to a protocol revision
(supported by both AT and AN) which is not existing.
9. AN will send a session close and configure a new session if new AN is not
able to retrieve AT's session information from old AN
Idle Handoff Scenario 2 (Alternate Procedure -2):
This procedure can be done only if AT is having a personality configured by old
AN corresponding to 'max_supported_prev'

AT Procedures:
1. Set prev_in_use = max_supported_prev
2. Set SCT corresponding to the personality configured by old AN for this 'prev_in_use'
3. Create the InUse Instances of the protocols corresponding to the new 'prev_in_use'
4. Send UATI request message with AT supported protocol revisions and prev_in_use. As part of UATI request message transmission, SCT and UATI also get transmitted in the MAC header.
AN Procedures:
1. AN receives UATI request message and checks SCT.
2. UATI received in MAC header indicates that AT is having a session
3. SCT! = NONE indicates that AT is using a personality corresponding to the personality index indicated by SCT.
4. AN will get the AT's session information from old AN.
5. AN will store the session information received from old AN
6. As AT is already using the personality corresponding to 'max_supported_prev\ there is no need to switch personality
7. However, AN may do a session configuration
a. To change some parameters of InUse personality and/or

b. To create a new personality corresponding to a protocol revision (supported by both AT and AN) which is not existing. 8. AN will send a session close and configure a new session if new AN is not able to retrieve AT's session information from old AN
Idle Handoff Scenario 3:
AT has an established session with old AN and has moved to a new AN.
prev_in_use is not supported by new AN.
AT Procedures:
1. Set prev_in_use = max_supported_prev
2. Set SCT = NONE (i.e., OxFFFF)
3. Create the InUse Instances of the protocols corresponding to the default set of 'prev_in_use'
4. Send UATI request message with AT supported protocol revisions and 'prev_in_use'. As part of UATI request message transmission, SCT and UATI also get transmitted in the MAC header.
AN Procedures:
1. AN receives UATI request message and checks SCT.
2. UATI received in MAC header indicates that AT is having a session

3. SCT == NONE, prev_in_use indicates that AT is using default set corresponding to prev_in_use
4. AN will get the AT's session information from old AN.
5. AN will store the session information received from old AN
6. If AT already has a personality corresponding to 'max_supported_prev'
a. AN will switch the AT's InUse personality to the personality
corresponding to 'max_supported_prev'
7. If AT doesn't have a personality corresponding to 'max_supported_prev'
b. AN will create a personality corresponding to 'max_supported_prev'
and will switch AT to new personality corresponding to
'max_supported_prev'
8. AN may also do a session configuration
a. To change some parameters of InUse personality and/or
b. To create a new personality corresponding to a protocol revision
(supported by both AT and AN) which is not existing.
9. AN will send a session close and configure a new session if new AN is not
able to retrieve AT's session information from old AN
Idle Handoff Scenario 3 (Alternate Procedure -1):
This procedure can be done only if AT is having a personality configured by old
AN corresponding to 'max_supported_prev'
AT Procedures:
1. Set prev_in_use = max_supported_prev

2. Set SCT corresponding to the personality configured by old AN for this 'prev_in_use'
3. Create the InUse Instances of the protocols corresponding to the new 'prev_in_use'
4. Send UATI request message with AT supported protocol revisions and 'prev_in_use\ As part of UATI request message transmission, SCT and UATI also get transmitted in the MAC header.
AN Procedures:
1. AN receives UATI request message and checks SCT.
2. UATI received in MAC header indicates that AT is having a session
3. SCT! = NONE indicates that AT is using a personality corresponding to the personality index indicated by SCT.
4. AN will get the AT's session information from old AN.
5. AN will store the session information received from old AN
6. As AT is already using the personality corresponding to 'max_supported_prev', there is no need to switch personality.
7. However, AN may do a session configuration
a. To change some parameters of InUse personality and/or
b. To create a new personality corresponding to a protocol revision
(supported by both AT and AN) which is not existing
8. AN will send a session close and configure a new session if new AN is not
able to retrieve AT's session information from old AN

ADVANTAGES
The Proposed approach,
1. Facilitates creation of protocol subtypes corresponding to maximum protocol revision that is supported by both AT and AN without having to start negotiation with only one set of defined protocol subtypes.
2. Defines a mechanism for AN and AT to communicate the protocol revisions supported by each other
3. Facilitates usage of established session negotiation by both AT and AN during idle handoffs
4. Avoids/Reduces session negotiation, if required, after idle handoffs.
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.

GLOSSARY OF TERMS AND DEFINITIONS THEREOF
Access Network: The network equipment which provides data connectivity between a packet switched data network (typically the Internet) and the access terminals
Access Terminal: A device providing data connectivity to a user. An access terminal may be connected to a computing device such as a laptop personal computer or it may be a self-contained data device such as a personal digital assistant. An access terminal is equivalent to a mobile station.
EV-DO: CDMA2000 1x evolution-Data Optimized system.
MAC: Medium Access Control Protocol


WE CLAIM
1. A method for inter-working in a multl protocol revision based EVDO
communication systems comprising tlie steps of:
performing a session configuration by access terminal (AT) and access network (AN);
maintaining a set by AT indicating all the protocol revisions said AT supports; and
AT and AN performing session negotiation with the subtypes corresponding to a maximum protocol revision supported by AT and AN,
wherein AT sends a Unicast Access Terminal Identifier (UATI) request message with protocol revisions using power up and idle handoff procedures.
2. A method as claimed in claim 1 wherein AT calculates the maximum protocol
revision supported by AT and AN according to the equation:
max_supported_prev = Maximum ({Set of protocol revisions supported by both AT
and AN})
Where,
{Set of protocol revisions supported by both AT and AN} =
{Protocol revisions supported by AT} D {Protocol revisions supported by AN}.

3. A method as claimed in claim 1 wherein while sending UATI request message, AT sends session configuration token (SCT) and random AT identifier (RATI) where SCT indicates whether AT is using a default or configured session.
4. A method as claimed in claim 1 wherein In power up procedure, AT calculates the maximum protocol revision supported by AT and AN and then sends UATI request message along with SCT and RATI.
5. A method as claimed in claim 4 wherein AN checks for SCT and RATI arrival, where RATI indicates that AT is not having any configured session and SCT shows whether AT is using default protocol or otherwise.
6. A method as claimed in claim 5 wherein AN is adapted to configure multiple personalities corresponding to each protocol revision supported by AT and sets SCT to the personality in use.
7. A method as claimed in claim 1 wherein in the idle handoff procedure, AT moves from one network to another without the call getting disconnected.
8. A method as claimed in claim 7 wherein after idle handoff to a system or network with different protocol revision, AT gets the protocol revisions supported by AN by monitoring the broadcast messages and calculates the maximum protocol revision supported by AT and AN.

9. A system for inter-working in a multi protocol revision based EVDO
communication systems comprising :
access terminal (AT) and access network (AN) performing a session configuration; and
means for maintaining a set by AT indicating all the protocol revisions said AT supports and said AT and AN performing session negotiation by AT and AN with the subtypes corresponding to a maximum protocol revision supported by AT and AN,
wherein AT sends a Unicast Access Terminal Identifier (UATI) request message with protocol revisions using power up and idle handoff procedures.
10. A method for inter-working in a multi protocol revision based EVDO
communication systems comprising substantially described and explained with
reference to the drawings.


11. A system for inter-working in a multi protocol revision based EVDO communication systems comprising substantially described and explained with reference to the drawings.

Documents:

1345-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 08-08-2013.pdf

1345-CHE-2006 OTHERS 08-08-2013.pdf

1345-CHE-2006 POWER OF ATTORNEY 08-08-2013.pdf

1345-CHE-2006 AMENDED PAGES OF SPECIFICATION 08-08-2013.pdf

1345-CHE-2006 AMENDED CLAIMS 08-08-2013.pdf

1345-CHE-2006 FORM-1 08-08-2013.pdf

1345-CHE-2006 FORM-13 08-08-2013.pdf

1345-CHE-2006 FORM-3 08-08-2013.pdf

1345-CHE-2006 FORM-5 08-08-2013.pdf

1345-CHE-2006 OTHER PATENT DOCUMENT 08-08-2013.pdf

1345-CHE-2006 OTHER PATENT DOCUMENT 1 08-08-2013.pdf

1345-che-2006 abstract.pdf

1345-che-2006 claims.pdf

1345-CHE-2006 CORRESPONDENCE OTHERS.pdf

1345-che-2006 description (complete).pdf

1345-CHE-2006 FORM 1.pdf

1345-CHE-2006 FORM 18.pdf

1345-che-2006 form-5.pdf

1345-che-2006-correspondnece-others.pdf

1345-che-2006-description(provisional).pdf

1345-che-2006-drawings.pdf

1345-che-2006-form 1.pdf

1345-che-2006-form 26.pdf


Patent Number 257673
Indian Patent Application Number 1345/CHE/2006
PG Journal Number 43/2013
Publication Date 25-Oct-2013
Grant Date 24-Oct-2013
Date of Filing 31-Jul-2006
Name of Patentee SAMSUNG INDIA SOFTWARE OPERATIONS PRIVATE LIMITED
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 VADLAPUDI TIRUMALA SREE HARI VARA PRASAD Employed at Samsung India software Operations Pvt. Ltd., having its office at, Bagmane Lakeview, Block 'B', No. 66/1, Bagmane Tech park, C V Raman Nagar, Byrasandra, Bangalore-560093.
2 GODAVARTI SATYA VENKATA UMA KISHORE Employed at Samsung India software Operations Pvt. Ltd., having its office at, Bagmane Lakeview, Block 'B', No. 66/1, Bagmane Tech park, C V Raman Nagar, Byrasandra, Bangalore-560093.
3 ANIL AGIWAL Employed at Samsung India software Operations Pvt. Ltd., having its office at, Bagmane Lakeview, Block 'B', No. 66/1, Bagmane Tech park, C V Raman Nagar, Byrasandra, Bangalore-560 093.
PCT International Classification Number H04M07/00
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA