Title of Invention

METHOD AND DEVICE FOR CONFIGURING MULTIPLE SESSION CONFIGURATIONS IN AN EVOLUTION DATA OPTIMIZED (EVDO) COMMUNICATION SYSTEMS

Abstract The invention relates to telecommunication systems, and more particularly to configuration and updation of multiple session configurations in Evolution-Data Optimized (EVDO) systems. Two encoding schemes are described in the invention for configuring and updating multiple session configurations. A personality type is defined as the configured session after session negotiation. In one encoding scheme, the protocol type in the personality being configured is hard linked to the corresponding protocol type in a personality that is already configured. This allows modification by accepting the new personality as is. In the second encoding scheme, the InConfiguration Instance is generated by taking the Subtype and attribute information of the protocol type encoded in Softlink subtype. If necessary, Configuration Request and Configuration Response messages are used to configure the attributes.
Full Text FIELD OF THE INVENTION
The present invention, in general, relates to EVDO and its evolved communication systems. It describes how the system uses session configuration protocol to configure multiple session configurations. More particularly, the invention is related to a system and method for efficiently configuring and updating the multiple sessions' parameters in EVDO and its evolved communication systems.
DESCRIPTION OF THE 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 protoco!7applications 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 AN and AT. 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).
In each personality negotiation, two steps are involved:
a. Subtype negotiation: This is done using the Configuration Request and Configuration Response message exchanges between the SCP at AN and AT. SCP at AN and AT negotiates the ProtocolTypes attribute defined in SCP. The ProtocolTypes attribute is defined in the Table 1. If HardLink subtype is negotiated for a protocol Type, then the protocol subtype and the attributes values of this protocol Type in the personality under consideration shall be the same as corresponding protocol subtype and the attributes of the corresponding protocol Type in the Main Personality or personality index zero and vice versa.

Request message with Protocol Types attribute to AN. AN sends Configuration Response message with the accepted values of Protocol Types attribute in reply to the Configuration Request message from the AT. InConfiguration instances of the protocols/applications of the new subtype negotiated are created by AT and AN. The InConfiguration instances of new subtype created will have default attribute values.
3. AT negotiates the attributes for the protocol/application subtypes negotiated in step 2. AT sends the Configuration Request message with the attributes to be negotiated to AN. AN sends Configuration Response message with the accepted values of attributes in reply to the Configuration Request message from the AT.
4. Upon completion of negotiation of all the intended attributes, AT sends configuration complete message to AN.
5. AT and AN enter into the AN initiated state in SCP.
6. AN negotiates the subtypes for various protocol and applications to be used using configuration request messages. In this step, AN may override the subtypes negotiated in step2 (by AT). AN sends the Configuration Request message with Protocol Types attribute to AT. AT sends Configuration Response message with the accepted values of Protocol
v Types attribute in reply to the Configuration Request message from the AN. InConfiguration instances of the protocols/applications of the new subtype negotiated are created by AT and AN. The InConfiguration instances of new subtype created will have default attribute values.
7. AN negotiates the attributes for the protocol/application subtypes negotiated in step 2 and 6. AN sends the Configuration Request message with the attributes to be negotiated to AT. AN sends Configuration Response message with the accepted values of attributes in reply to the Configuration Request message from the AN.
8. AN sends soft configuration complete message to AT.
a. The soft configuration complete message contains the personality index where the negotiated session configuration using steps 2 to 6 is to be stored.
b. The soft configuration complete message contains a field 'continue' which tells if AN want to configure more personalities. If the AN does not want to configure more personalities it will set 'continue' field to zero else it will set 'continue' field to one. If the continue field is set to one, steps 2 to 8 are repeated again.
c. The soft configuration field contains a field 'commit'. If AN has updated the personality in use or if it wants a different personality to become in use, it will set the 'commit' field to one else it will set the 'commit' field to zero. If the commit field is set to T AN will provide the session configuration token containing the new personality index to be used in soft configuration complete message.
The steps 1 to 8 are illustrated in more detail for various scenarios in figures 1 to 4. Figurel illustrates the various steps involved in configuring the two personalities. Personality index 0 is the in use personality after the multiple personality configurations. Figure2 illustrates the steps involved in configuring the two personalities. Personality index 1 is the in use personality after the multiple personality configurations. Figure3 illustrates the steps involved in updating the personality (personality index 0) configured in Figure2 and configuring a new personality with personality index 3. Personality index zero which is being updated is not in use. Figure4 illustrates the steps involved in updating the personality (personality index 1) configured in Figure2 and configuring a new personality with personality index 3. Personality index one which is being updated is in use.
LIMITATIONS
There are three potential problems with the current approach of negotiating and configuring the multiple personalities.
1. Configuration of two personalities which are very similar (not exactly same)
a. There is no way of reusing the configured data partially from the already configured personality or personalities while configuring/creating a personality.
b. This results in Configuration Request /Response message exchange for each personality separately to configure all attributes
Consider for example that two personalities need to be configured. The details of two personalities are as follows:
Personality 1:
Forward Traffic Channel MAC Protocol with subtypel Control Channel MAC Protocol with subtype 1 Reverse Traffic Channel MAC Protocol with subtype 3 Packet application: Default Packet application
Personality 1 Configuration Steps:
1. Subtype negotiation for Forward Traffic Channel MAC Protocol, Control Channel MAC Protocol, Reverse Traffic Channel MAC Protocol and Packet application
2. Attribute negotiation for Forward Traffic Channel MAC Protocol
3. Attribute negotiation for Control Channel MAC Protocol
4. Attribute negotiation for Reverse Traffic Channel MAC Protocol
5. Attribute negotiation for Packet application.
6. Personality Configuration completed and stored at personality index 'V
Personality 2:
Forward Traffic Channel MAC Protocol with subtypel Control Channel MAC Protocol with subtype 1 Reverse Traffic Channel MAC Protocol with subtype 3 Packet application: Multi Row Packet application
Personality 2 Configuration Steps:
1. Subtype negotiation for Forward Traffic Channel MAC Protocol, Control Channel MAC Protocol, Reverse Traffic Channel MAC Protocol and Packet application
2. Attribute negotiation for Forward Traffic Channel MAC Protocol
3. Attribute negotiation for Control Channel MAC Protocol
4. Attribute negotiation for Reverse Traffic Channel MAC Protocol
5. Attribute negotiation for Multi Flow Packet application
6. Personality Configuration completed and stored at personality index '2'
In the above two personalities except the packet application everything is same. The steps 1 to 6 in the personality configuration for the two personalities are same. But in the current approach Configuration Request and Configuration Response messages needs to be exchanged for each personality separately.
2. Updating the session configuration parameters of the personality which is not in use
a) During session negotiation InConfiguration instances are created by loading the information (Subtypes and attributes) from the current InUse instances
■ This has a problem of not inheriting any of the information from the personality that we want to update
b) This results in configuring the entire personality again
■ Configuration Request/Response message exchanges are needed even for all attributes that will remain same even after updation
Consider for example two personalities with personality indexes '1' and '2' are configured. Personality with personality index '1' is in use. Personality with personality index '2' details is as follows
Personality 2:
Forward Traffic Channel MAC Protocol with subtypel Control Channel MAC Protocol with subtype 1 Reverse Traffic Channel MAC Protocol with subtype 3 Packet application: Multi Flow Packet application
Personality 2 Configuration Steps:
1. Session negotiation is initiated
2. Creation of the InConfiguration instances of the protocols/applications with same subtype as InUse instance.
3. Subtype negotiation for Forward Traffic Channel MAC Protocol, Control Channel MAC Protocol, Reverse Traffic Channel MAC Protocol and Packet application
4. Creation of the InConfiguration instances of the protocols/applications with new subtypes negotiated in step 3. InConfiguration instances are created with default attribute values.
5. Attribute negotiation for Forward Traffic Channel MAC Protocol
6. Attribute negotiation for Control Channel MAC Protocol
7. Attribute negotiation for Reverse Traffic Channel MAC Protocol
8. Attribute negotiation for Multi Flow Packet application
9. Personality Configuration completed and stored at personality index '2'
Now suppose some attribute values for Forward Traffic Channel MAC
Protocol in personality '2' needs to be changed. This can be achieved by
following steps which are same as creating the personality again:
Personality 2 Updating Steps:
1. Session negotiation is initiated
2. Creation of the InConfiguration instances of the protocols/applications with same subtype as InUse instance.
3. Subtype negotiation for Forward Traffic Channel MAC Protocol, Control Channel MAC Protocol, Reverse Traffic Channel MAC Protocol and Packet application
4. Creation of the InConfiguration instances of the protocols/applications with new subtypes negotiated in step 3. InConfiguration instances are created with default attribute values.
5. Attribute negotiation for Forward Traffic Channel MAC Protocol
6. Attribute negotiation for Control Channel MAC Protocol
7. Attribute negotiation for Reverse Traffic Channel MAC Protocol
8. Attribute negotiation for Multi Flow Packet application
9. Personality Configuration completed and stored at personality index '2'
3. Hard Linking of protocol subtypes to personality other than Main Personality
is not possible.
Therefore there is need in the art for techniques or mechanisms for efficiently configuring and updating the multiple sessions' parameters in EVDO communication systems.
SUMMARY OF THE INVENTION
1. New SoftLink Subtype values are added for the ProtocolTypes attribute to facilitate creation of InConfiguration instances of the protocols/applications corresponding to the subtypes of a particular personality index.
2. New HardLink Subtype values are defined to facilitate hard linking of a protocol type in the personality being configured to the corresponding protocol type in a personality already configured.
3. The current approach of configuring and updating the multiple sessions' parameters in EVDO communication systems is modified using the such that InConfiguration instances of the protocols/applications can be created corresponding to the subtypes of a particular personality index. The InConfiguration instances of the protocols/applications created will be initialized with the attribute values corresponding to the particular personality index.
4. New messages, for example ConfigurationCopyRequest, ConfigurationCopyAccept and ConfigurationCopyReject, are added in the Generic Configuration Protocol to facilitate configuration copy (i.e., copy the values of all the attributes of a given protocol) from one personality to another personality.
Accordingly this invention explains a method for Configuring and Updating the Multiple Session Configurations in EVDO and its evolved Communication Systems comprising the steps of:
a. creating InConfiguration instances of protocols/applications corresponding to the subtypes of a particular personality index;
b. negotiating personality index for each protocol to load the attribute values;
c. negotiating individual attribute values; and
d. storing the negotiated personality.
Accordingly this invention explains a system for Configuring and Updating the Multiple Session Configurations in EVDO and its evolved Communication Systems comprising: means for creating InConfiguration instances of protocols/applications
corresponding to the subtypes of a particular personality index and negotiating
personality index for each protocol to load the attribute values; and
means for negotiating individual attribute values and storing the negotiated
personality.
These and other objects, features and advantages of the present invention will become more readily apparent from the detailed description taken in conjunction with the drawings and the claims.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 depicts Multiple Personality Configuration with Personality Zero Configured for Use
Figure 2 depicts Multiple Personality Configuration with Personality One Configured for Use
Figure 3 depicts Non Inuse Personality Updation Figure 4 depicts Inuse Personality Updation
Figure 5 depicts Configuration of Two Similar Personalities using Current and New Approach
Figure 6 depicts Updating a Personality using Current and New Approach
Figure 7 depicts Protocol Types Attribute Value Encoding
Figure 8 depicts Configuration of Two Similar Personalities Using Current and New Approach (Alternative-2)
Figure 9 depicts Updating a Personality Using Current and New Approach (Alternative-2)
DEATILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are 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 problems in the current approach of configuring and updating the multiple sessions' parameters can be rectified if the InConfiguration instances of the protocol/applications can reuse/copy the attribute values from the already configured personality. The InConfiguration instances of the protocol/applications of the personality being created/configured can reuse the attribute values from the already configured personality by copying the attribute values from the desired personality at the time of creation of InConfiguration instances. The InConfiguration instances of the protocol/applications of the personality being created/configured can reuse the attribute values from the already configured personality by copying the attribute values from the desired personality at any time during the session negotiation.
To describe the invention two alternatives are considered for detailed explanation, alternative -1 and alternative -2.
ALTERNATIVE -1
The problems in the current approach of configuring and updating the multiple sessions' parameters can be rectified if the InConfiguration instances of the protocol/applications of the personality being created/configured can be created with the values of the corresponding protocol/application of an already configured personality.
New SoftLink Subtype values are added for the ProtocolTypes attribute to facilitate creation of InConfiguration instances of the protocols/applications corresponding to the subtypes of a particular personality index.
New HardLink Subtype values are defined to facilitate hard linking of a protocol type in the personality being configured to the corresponding protocol type in a personality already configured.
In the new approach ProtocolTypes attribute values can be encoded in several ways to indicate the soft and hard linking:
Encoding scheme-1:
■ OxFFEF to FFFE: HardLink Protocol Subtypes
■ OxFFDF to OxFFEE: SoftLink Protocol Subtypes
■ 0x0000 - OxFFDE and OxFFFF: Protocol Subtypes
HardLink Subtypes: Reception of HardLink Protocol Subtype for a Protocol Type during subtype negotiation of a personality means that
■ The protocol type is hard linked to the personality index encoded in HardLink subtype
■ Hard linked protocol type will use the subtype and attribute information of the corresponding protocol type, from the personality to which it is hard linked
■ And hence there is no need for Configuration of attributes for the hard linked protocol type
If the ProtocolTypes attribute value corresponding to a protocol/application js
between OxFFEF to OxFFFE, it means that the protocol type is hard linked to the personality index given by PersonalitylndexHardunk, where Personality!ndexnartfunk = (OxFFFE - (the value of ProtocolTypes attribute for this protocol)).
SoftLink Subtypes: Reception of SoftLink Protocol Subtype for a Protocol type during subtype negotiation of a personality means that
■ InConfiguration Instance of the protocol type is created by loading the information (Subtype and attribute) corresponding to the protocol type from the personality index encoded in SoftLink subtype
■ Then Configuration Request and Configuration Response messages are used to configure the attributes if required
■ Unlike HardLink, the change in the values of one protocol type will not effect the attribute values in the SoftLinked Protocol Type
If the ProtocolTypes attribute value corresponding to a protocol/application is between OxFFDF to OxFFEE, it means that AT or AN shall create the InConfiguration instance for that protocol with the subtype corresponding to this protocol in the personality index given by Personalitylndexsoftunk, where Personalitylndexsoftunk = ((value of ProtocolTypes attribute for this protocol) - (OxFFDF))
At the time of creation of InConfiguration Instance the attribute values will be initialised with the negotiated attribute values corresponding to this protocol in personality index given by Personalitylndexsoftunk.
Protocol Subtypes: If the ProtocolTypes attribute value corresponding to a protocol/application is between 0x0000 - OxFFDE or OxFFFF, it means that AT or AN shall create the InConfiguration instance for that protocol, with the subtype value same as the value of ProtocolTypes attribute value.
The change mentioned above will facilitate the creation of the InConfiguration instances of the protocols/applications with the subtypes and attribute values corresponding to the desired personality index. This will also enable the protocol


8. AN sends configuration request message to AT to negotiate attributes for forward traffic channel mac protocol after receiving the configuration response message corresponding to configuration request message for control channel mac protocol.
9. AN sends configuration request message to AT to negotiate attributes for reverse traffic channel mac protocol after receiving the configuration response message corresponding to configuration request message for forward traffic channel mac protocol.
10. AN sends configuration request message to AT to negotiate attributes for physical layer protocol after receiving the configuration response message corresponding to configuration request message for reverse traffic channel mac protocol.
11. AN sends soft configuration complete message with 'continue' field set to one, 'p_idx' field set to 3 to AT after receiving configuration response message corresponding to configuration request message for physical layer protocol.
12. AN and AT store the configured information at personality index 3.
13. AT and AN enter the AT initiated state in SCP and creates the InConfiguration instances of the protocols/applications with same subtype as inUse instance.
14. AT sends the configuration complete message to AN as it does not want to negotiate anything.
15. AT and AN enter the AN initiated state in SCP
16. AT sends the configuration complete message to AN as it does not want to negotiate anything.
17. AT and AN enter the AN initiated state in SCP.
18. AN initiates subtype negotiation. AN sends configuration request message to AT with protocol types attribute values set to 0xFFE2 for all protocols/application except broadcast protocol suite. The protocol types attribute values corresponding to broadcast protocol suite is set to one.
19. AN and AT create the InConfiguration instances of all the protocols/applications except broadcast protocol suite with the subtypes corresponding to protocols/applications in personality index 0xFFE2 - OxFFDF = 3. In the InConfiguration Instance of all the protocols/applications except broadcast protocol suite, the attribute values will be initialised with the negotiated attribute values corresponding to the protocols/applications in personality index 0xFFE2 - OxFFDF = 3. AN and AT creates the InConfiguration instances of broadcast protocol suite with subtype 1.
20. AN sends soft configuration complete message with 'continue' field set to zero, 'p_idx' field set to 4, 'commit' field to zero to AT.
21. AN and AT store the configured information at personality index 4.
From the steps mentioned above it is clear that configuration request and configuration response messages for negotiating the attribute values for personality index 4 are avoided. The above steps are also illustrated in the Figures.
Example 2: Updating a Personality Index
Suppose AN wants to update a personality stored at personality index 3. This personality is not in use by AT and AN. The details of the personality are mentioned in the Table 3. AN wants to update some attributes in forward traffic

protocols/application except broadcast protocol suite. The protocol types attribute values corresponding to broadcast protocol suite is set to zero.
6. AN and AT create the InConfiguration instances of all the protocols/applications except broadcast protocol suite with the subtypes corresponding to protocols/applications in personality index 0xFFE2 - OxFFDF = 3. In the InConfiguration Instance of ail the protocols/applications except broadcast protocol suite, the attribute values will be initialised with the negotiated attribute values corresponding to the protocols/applications in personality index 0xFFE2 - OxFFDF = 3. AN and AT creates the InConfiguration instances of broadcast protocol suite with subtype 0.
7. AN sends configuration request message to AT to negotiate attributes for forward traffic channel mac protocol.
8. AN sends soft configuration complete message with 'continue' field set to zero, lp_idx' field set to 3, 'commit' field to zero to AT after receiving the configuration response message corresponding to configuration request message for forward traffic channel mac protocol.
9. AN and AT store the configured information at personality index 3.
From the steps mentioned above and the Figure6 it is clear that in the new approach configuration request and configuration response message needs to be exchanged only for the attributes to be updated unlike the current approach where the entire personality needs to be negotiated again.
Example 3: Hardlinkinq to any personality index
Suppose ANs wants to hard link forward traffic channel mac protocol while configuring a personality to a personality index 4 which is already configured. This can be achieved by setting the protocol attribute value corresponding to forward traffic channel mac protocol to OxFFFA. OxFFFA is one of the hard link protocol subtypes. The personality index to which hard linking is done is = OxFFFE - OxFFFA = 4.
Encoding Scheme-2:
The ProtocolTypes attribute values can also be encoded as shown in Figure7
If the hard link bit is set to 'V and soft link bit is set to '0' in ProtocolTypes attribute value then it means that the protocol type is hard linked to the personality index given by the 14LSBs of ProtocolTypes attribute value.
If the soft link bit is set to T and the hard link bit is set to '0' in ProtocolTypes attribute value , it means that AT or AN shall create the InConfiguration instance for that protocol with the subtype corresponding to this protocol in the personality index given by 14LSBs of ProtocolTypes attribute value. At the time of creation of InConfiguration Instance the attribute values will be initialised with the negotiated attribute values corresponding to this protocol in personality index given by the 14LSBs of ProtocolTypes attribute value.
If the soft link bit is set to '0' and the hard link bit is set to '0' in ProtocolTypes attribute value, it means that AT or AN shall create the InConfiguration instance for that protocol, with the subtype value given by the 14LSBs of ProtocolTypes attribute value.
The soft link bit and hard link bit are not set to '1' simultaneously.
The change mentioned above will facilitate the creation of the InConfiguration
instances of the protocols/applications with the subtypes and attribute values
corresponding to the desired personality index. This will also enable the protocol
type in a personality to be hard linked to any personality index.
Personality Deletion
In the new approach during the personality deletion, If a protocol type in a personality index say 'P2' is hard linked to a personality index 'PV and if 'P1' is
>
being deleted, then the subtype and attributes values corresponding to the protocol type should be copied from personality index 'P1' to 'P2ALTERNATIVE -2
The problems in the current approach of configuring and updating the multiple sessions' parameters can be rectified if the InConfiguration instances of the protocol/applications of the personality being created/configured can copy all the attribute values of the corresponding protocol/application of an already configured personality.
New HardLink Subtype values are defined to facilitate hard linking of a protocol type, if required, in the personality being configured to the corresponding protocol type in a personality already configured.
HardLink Subtypes: Reception of HardLink Protocol Subtype for a Protocol Type during subtype negotiation of a personality means that
■ The protocol type is hard linked to the personality index encoded in HardLink subtype
■ Hard linked protocol type will use the subtype and attribute information of the corresponding protocol type, from the personality to which it is hard linked
■ And hence there is no need for Configuration of attributes for the hard linked protocol type
If the ProtocolTypes attribute value corresponding to a protocol/application is between OxFFEF to OxFFFE, it means that the protocol type is hard linked to the personality index given by PersonalitylndexHardLink, where Personalitylndexnartunk = (OxFFFE - (the value of ProtocolTypes attribute for this protocol)).
Protocol Subtypes: If the ProtocolTypes attribute value corresponding to a protocol/application is between 0x0000 - OxFFEE or OxFFFF, it means that AT or
AN shall create the InConfiguration instance for that protocol, with the subtype value same as the value of ProtocolTypes attribute value.
This will enable the protocol type in a personality to be hard linked to any personality index.
New messages, for example ConfigurationCopyRequest message, ConfigurationCopyAccept message and ConfigurationCopyReject message, are added in the Generic Configuration Protocol to facilitate configuration copy (i.e., copy the values of all the attributes of a given protocol) from one personality to another personality.
The new message names as given in the example above are used for ease of understanding in the detailed description below.
The above messages are used to copy the attribute values of a protocol from one personality into another personality as explained below.
The initiator uses ConfigurationCopyRequest message to provide the responder with a proposed personality index from where the attribute values for all the attributes in this protocol to be taken from the corresponding protocol. The subtype for this protocol shall be same as the protocol subtype in the proposed personality index from where configuration copy is requested. The responder uses the ConfigurationCopyAccept or ConfigurationCopyReject message to accept or reject the proposed configuration copy.
After sending a ConfigurationCopyRequest message, the sender shall set the value of all the attributes of the protocol to NULL.
After receiving a ConfigurationCopyRequest message, the responder shall respond with either ConfigurationCopyAccept or ConfigurationCopyReject within a specified time unless specified otherwise.
• If the responder accepts the proposed configuration copy, the responder shall perform the following
- The responder shall send ConfigurationCopyAccept message.
- The responder shall copy all the attribute values from the corresponding protocol in the given personality index.
• If the responder does not accept the proposed configuration copy, the responder shall perform the following
- The responder shall send ConfigurationCopyReject message.
- The responder shall set all the attributes of this protocol to their corresponding fall-back values.
After receiving a ConfigurationCopyAccept message or ConfigurationCopyReject message, the initiator shall pair the received message with the associated ConfigurationCopyRequest message using the TransactionID field of the messages.
• If the initiator receives a ConfigurationCopyAccept message, the initiator shall perform the following
- The initiator shall copy all the attribute values from the corresponding protocol in the personality index as given in the associated ConfigurationCopyRequest message.
• If the initiator receives a ConfigurationCopyReject message, the initiator shall perform the following
- The initiator shall set all the attribute of this protocol to their corresponding fall-back values.
Message formats:
ConfigurationCopyRequest
The ConfigurationCopyRequest message format is as follows:



5. AN initiates subtype negotiation. AN sends configuration request message to AT with protocol types attribute values set to desired values corresponding to personality 3 as mentioned in Table 5
6. AN and AT create the InConfiguration instances of the protocols/applications with new subtypes negotiated in step 5.
7. AN sends configuration request message to AT to negotiate attributes for Control channel mac protocol.
8. AN sends configuration request message to AT to negotiate attributes for forward traffic channel mac protocol after receiving the configuration response message corresponding to configuration request message for control channel mac protocol.
9. AN sends configuration request message to AT to negotiate attributes for reverse traffic channel mac protocol after receiving the configuration response message corresponding to configuration request message for forward traffic channel mac protocol.
10. AN sends configuration request message to AT to negotiate attributes for physical layer protocol after receiving the configuration response message corresponding to configuration request message for reverse traffic channel mac protocol.
11. AN sends soft configuration complete message with 'continue' field set to one, 'pjdx' field set to 3 to AT after receiving configuration response message corresponding to configuration request message for physical layer protocol.
12. AN and AT store the configured information at personality index 3.
13. AT and AN enter the AT initiated state in SCP and creates the InConfiguration instances of the protocols/applications with same subtype as InUse instance.
14. AT sends the configuration complete message to AN as it does not want to negotiate anything.
15. AT and AN enter the AN initiated state in SCP
16. AT sends the configuration complete message to AN as it does not want to negotiate anything.
17. AT and AN enter the AN initiated state in SCP.
18. AN initiates subtype negotiation. AN sends configuration request message to AT with protocol types attribute values set to corresponding subtype values for all protocols/application as given in Table 6.
19. AT sends configuration response message with accepted value IDs.
20. AN and AT create the InConfiguration instances of all the protocols/applications with the subtypes corresponding to protocols/applications in configuration request message.
21. AN sends ConfigurationCopyRequest messages with personality index set to 3 for protocols FTCMP, CCMP, RTCMP and PHYP.
22. AT sends ConfigurationCopyAccept message to accept the configuration copy.
23. AN and AT load the InConfiguration instances of FTCMP, CCMP, RTCMP and PHYP with the corresponding values in personality index 3.

1. AN sends configuration start message to AT to initiate session negotiation.
2. AT and AN enter the AT initiated state in SCP and creates the InConfiguration instances of the protocols/applications with same subtype ' as InUse instance.
3. AT sends the configuration complete message to AN as it does not want to negotiate anything.
4. AT and AN enter the AN initiated state in SCP
5. AN initiates subtype negotiation. AN sends configuration request message to AT with protocol types attribute values set to corresponding subtype values for all protocols/application as given in Table 7.
6. AT sends configuration response message with accepted value IDs.
7. AN and AT create the InConfiguration instances of ail the protocols/applications with the subtypes corresponding to protocols/applications in configuration request message.
8. AN sends ConfigurationCopyRequest messages with personality index set to 3 for protocols FTCMP, CCMP, RTCMP and PHYP.
9. AT sends ConfigurationCopyAccept message to accept the configuration copy.
10. AN and AT load the InConfiguration instances of FTCMP, CCMP, RTCMP and PHYP with the corresponding values in personality index 3.
11. AN sends soft configuration complete message with 'continue' field set to zero, 'pjdx' field set to 3, 'commit' field to zero to AT.
12. AN and AT store the configured information at personality index 3.
From the steps mentioned above and the Figure9 it is clear that in the new approach configuration request and configuration response message needs to be exchanged only for the attributes to be updated unlike the current approach where the entire personality needs to be negotiated again.
Example 3: Hardlinkina to any personality index
Suppose ANs wants to hard link forward traffic channel mac protocol while configuring a personality to a personality index 4 which is already configured. This can be achieved by setting the protocol attribute value corresponding to forward traffic channel mac protocol to OxFFFA. OxFFFA is one of the hard link protocol subtypes. The personality index to which hard linking is done is = OxFFFE-OxFFFA = 4. Personality Deletion
Jn the new approach during the personality deletion, If a protocol type in a personality index say 'P2' is hard linked to a personality index 'P1' and if 'P1' is being deleted, then the subtype and attributes values corresponding to the protocol type should be copied from personality index 'P1' to 'P2ADVANTAGES OF THE INVENTION
1. Allows usage of one personality configured data while configuring another personality.
2. While configuring a personality, several personality configured data can be reused.
3. Allows updating a configured personality without re-negotiating the whole personality again.
4. The problems in current approach are rectified with minimal changes.
While the foregoing description assumed a particular architecture it will be appreciated that the present invention may be used in numerous architectures and in numerous other examples. The major advantages of the invented method over the existing art are that it allows usage of configured personality data while configuring and updating a personality.
The foregoing description of illustrated embodiments of the present invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed herein. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the present invention, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the present invention in light of the foregoing description of illustrated embodiments of the present invention and are to be included within the spirit and scope of the present invention.
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 ATs
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 1 x evolution-Data Optimized system.




We Claim:
1. A method for Configuring and Updating the Multiple Session
Configurations in EVDO and its evolved Communication Systems comprising the
steps of:
a. creating InConfiguration instances of protocols/applications corresponding to the subtypes of a particular personality index;
b. negotiating personality index for each protocol to load the attribute values;
c. negotiating individual attribute values; and
d. storing the negotiated personality.
2. The method of claim 1 wherein the personality index to which a protocol type is soft-linked is negotiated during the subtype negotiation phase between AT and AN.
3. The method of claim 1 wherein the personality index to which a protocol type is hard-linked is negotiated during the subtype negotiation phase between AT and AN.
4. The method of claim 2 and 3 wherein the personality index to which a protocol type is hard or soft-linked is encoded in the ProtocolTypes Attribute without disturbing backward compatibility with existing EVDO Rel-O/A/B.
5. The method of claim 2 and 3, Soft-linking and hard-linking procedures are used for both Subtype and Protocol Parameter negotiation.
6. The method of claim 3, wherein any personality can be deleted even if a protocol from another personality is hardlinked to a protocol in the personality being deleted.
7. The method of claim 6, wherein the attributes values are copied from the
protocol in personality being deleted to protocol in other personalities to which this protocol is hardlinked.
8. The method of claim 1 wherein AT & AN exchange messages, for copying the attribute values of the attributes of an InConfiguration instance of the protocol/application subtype from the already configured personality
9. The method of claim 4 wherein initiator uses a ConfigurationCopyRequest message to provide the responder with a proposed personality index from where the attribute values for all the attributes in this protocol are copied from the corresponding protocol
10. The method of claim 4 wherein the responder uses a ConfigurationCopyAccept message to accept the proposed configuration copy received in the message sent by the initiator.
11. The method of claim 4 wherein the responder uses a ConfigurationCopyReject message to reject the proposed configuration copy received in the message sent by the initiator.
12. The method of claim 4 wherein the initiator and responder copy all the attribute values from the corresponding protocol in the personality index as given in the associated messages if the proposed configuration copy is accepted.
13. The method of claim 4 wherein the initiator and responder set all the attribute of this protocol to their corresponding fall-back values if the proposed configuration copy is rejected.
14. The method of claim 4 wherein the personality index to which a protocol type is hardlinked is negotiated during the subtype negotiation phase between AT and AN.
15. A system for Configuring and Updating the Multiple Session Configurations in EVDO and its evolved Communication Systems comprising:
means for creating InConfiguration instances of protocols/applications corresponding to the subtypes of a particular personality index and negotiating personality index for each protocol to load the attribute values; and
means for negotiating individual attribute values and storing the negotiated personality.
16. A method for Configuring and Updating the Multiple Session Configurations in EVDO and its evolved Communication Systems substantially described particularly with reference to the accompanying drawings.
17. A system for Configuring and Updating the Multiple Session Configurations in EVDO and its evolved Communication Systems substantially described particularly with reference to the accompanying drawings.

Documents:

1259-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 05-03-2013.pdf

1259-CHE-2006 POWER OF ATTORNEY 05-03-2013.pdf

1259-CHE-2006 ABSTRACT.pdf

1259-CHE-2006 AMENDED PAGES OF SPECIFICATION 05-03-2013.pdf

1259-CHE-2006 AMENDED CLAIMS 05-03-2013.pdf

1259-CHE-2006 CLAIMS.pdf

1259-CHE-2006 CORRESPONDENCE OTHERS.pdf

1259-CHE-2006 DESCRIPTION (COMPLETE).pdf

1259-CHE-2006 DRAWINGS.pdf

1259-CHE-2006 FORM-1 05-03-2013.pdf

1259-CHE-2006 FORM-1.pdf

1259-CHE-2006 FORM-13 05-03-2013.pdf

1259-CHE-2006 FORM-18.pdf

1259-CHE-2006 FORM-5.pdf

1259-CHE-2006 OTHER PATENT DOCUMENT 05-03-2013.pdf

1259-che-2006-correspondence-others.pdf

1259-che-2006-description-provisional.pdf

1259-che-2006-drawings.pdf

1259-che-2006-form 1.pdf

1259-che-2006-form 26.pdf


Patent Number 255691
Indian Patent Application Number 1259/CHE/2006
PG Journal Number 12/2013
Publication Date 22-Mar-2013
Grant Date 15-Mar-2013
Date of Filing 21-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-560093.
Inventors:
# Inventor's Name Inventor's Address
1 VADLAPUDI TIRUMALA SREE HARI VARA PRASAD SAMSUNG INDIA SOFTWARE OPERATIONS PVT. LTD., 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-560093.
PCT International Classification Number H04Q 7/00
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA