Dynamic protocol negotiation system

Two intelligent nodes are provided with the capability of negotiating a protocol between them so that if the intelligent nodes operate at two different protocols then they can select a protocol appropriate for their communication. Furthermore, the intelligent nodes are provided with a locking shift capability so as to select between codesets that are available within a selected protocol.

BACKGROUND OF THE INVENTION 
The present invention is directed to a method and apparatus for selecting a 
communication protocol between nodes in a network. More specifically, the 
present invention is directed to method and apparatus for dynamically 
negotiating a protocol between two nodes where at least one of the nodes 
is capable of operating in at least two different protocols. 
It is known in a telecommunication network to provide a plurality of nodes 
that have varying degrees of intelligence. The nodes are useful in 
controlling the operation of the network. More specifically, in an 
environment such as a network for wireless communications, it is often 
necessary to transfer information about a subscriber and the subscriber's 
services between various intelligent nodes in the network. In addition, 
since in a wireless communication scheme a subscriber can roam outside of 
the subscriber's home network and into another region serviced by other 
providers, it is also necessary to be able to transfer information between 
nodes in the subscriber network and the other provider's network. 
FIG. 1 illustrates an example of a wireless communication network showing 
how various intelligent nodes need to communicate with one another to 
transfer information so as to provide service to a subscriber that has a 
mobile station. 
In the example of FIG. 1, a subscriber has a mobile station 10. The 
subscriber has a "home" service provider, in this example, AT&T Wireless 
Services (AWS). The subscriber's home region is Seattle. Therefore, a Home 
Location Register (HLR) 11 in Seattle stores subscriber information with 
respect to mobile station 10, for example, the services to which the 
subscriber has access, billing information, etc. The HLR 11 is coupled to 
a signaling transfer point (STP) 13. A mobile switching center (MSC) 12 
handles over-the-air communications with the subscriber when she is in her 
home region. 
The subscriber may take the mobile station out of the home region of 
Seattle and seek service in a number of alternative locations which may or 
may not be served by her service provider. 
For instance, the subscriber could travel to New York and seek service in 
the New York region. It may so happen that the subscriber's provider also 
provides service in the New York region. In that circumstance, the mobile 
station would communicate with an MSC 22 in New York. When the mobile 
station is turned on in New York, the MSC 22 then sends a query back 
through the network 20 to the home region, and more specifically to the 
HLR 11 associated with the mobile station 10. 
The intelligent nodes, e.g., 20 and 22 typically transfer information in 
accordance with a pre-selected protocol. One example of such a protocol is 
known as IS-41. However, while IS-41 may define generally the type of 
protocol between the MSCs 22 and HLR 11, it is possible that the system 
provider has begun to install upgrades of the IS-41 protocol (for example, 
revision A, revision B, or revision C) throughout that provider's network. 
Since it is not feasible to install upgrades in each facility 
simultaneously, there may exist periods in time where various nodes within 
the system provider's network are capable of operating at different levels 
of the protocol. For instance, the MSC in New York, 22, could be IS-41 
Rev. A, whereas the MSC in Seattle, 12, could have been upgraded to IS-41 
Rev. C. An example of the problem that may arise is illustrated in FIG. 2. 
FIG. 2 shows that for two different protocol versions the same message type 
is identified by a different message code, for example, in protocol 
version A, the message type "Registration Notification" (RegNot) might be 
identified by message code 1 while in protocol C, it might be identified 
by message code 75. Thus, if nothing is done to facilitate the 
communications between MSC 22 and MSC 12, it is possible that as they 
communicate message codes between the two nodes the information that is 
transferred from node 12 to node 22 would not be properly understood. 
Protocol differences can also arise, and thereby create problems, when the 
subscriber activates the mobile station in a region that is serviced by a 
service provider other than the provider with whom the mobile station 
subscribes. As shown more specifically in FIG. 1, the mobile station 10 is 
located in a region so that is serviced by another system operator. When 
the mobile station is activated an MSC 32 in that region receives the 
activation request from the mobile station and then creates a query 
through an interconnect communications network North American Cellular 
Network (NACN), 40. This query back to the HLR 11 is the same as that 
which occurred in the first example described above where the mobile 
station has moved out of its home region but is still being serviced by 
the same service provider. However, in this scenario it is more likely 
that the MSC 32 and HLR 11 will be operating with different protocols. In 
such a circumstance, there is again the possibility of information being 
lost or mishandled due to the differences in the protocols. 
In a different environment, the user to network interface environment, it 
is known that one terminal (user) can operate at one protocol while 
another terminal (user) operates at a second different protocol. This 
environment differs from the network to node environment described above 
in that no node to node protocol adjustment takes place; the initial 
network node adapts to the fixed protocol of the end user terminal, but 
the actual network protocol, i.e., node to node, remains unchanged. 
CCITT Volume VI FASCICLE V1.11 (published in 1988) describes that in this 
user to network interface environment every message will include a 
protocol discriminator or identifier. This will serve to identify the 
protocol with which the message is associated. However, there is no 
mechanism for negotiating a protocol for communications. In fact, if the 
receiver cannot communicate in the identified protocol the message is 
simply discarded. The receiver and transmitter do not attempt to find a 
mutually acceptable communication protocol and again there is the 
likelihood that communication will be quite limited. 
It is therefore desirable to provide a method by which these intelligent 
nodes operating at different protocols can communicate with one another 
while reducing the likelihood of losing data or creating some mishandling 
of information. 
SUMMARY OF THE INVENTION 
The present invention provides a method for dynamically negotiating a 
protocol between nodes. 
In accordance with an embodiment of the present invention, one establishes 
a selection of a communication protocol between first and second network 
nodes by; in a first step, receiving at the second network node, an 
indication of the operating communication protocol of the first network 
node; then, based on the indication, a selection is made as to a 
designated protocol from a plurality of communication protocols at which 
the second network node is capable of operating. Subsequently, an 
indication of the designated protocol is sent to the first network node. 
As a consequence, the two network nodes operate at the same protocol 
thereby avoiding losses of information and mishandling of information. 
In a further embodiment of the present invention, after a protocol has been 
established between the two network nodes, it is possible that within a 
selected protocol a plurality of codesets are available. The present 
invention provides for dynamic selection of a codeset within a selected 
protocol. In accordance with the selection, it is possible that one of the 
network nodes can signal to the other network node that it is switching 
codesets within the protocol and can designate whether it is switching 
codesets indefinitely or only for the next parameter. 
With regard to protocol selection, typically the common protocol level to 
be used is easily determined by nodes belonging to the same service 
provider. Typically, this is the lowest (earliest) protocol level. For 
nodes which belong to different service provider networks, the service 
providers must agree on how to define a common protocol, for instance it 
is possible that as between two different providers, if there are 
differences between protocols, a default or third protocol is selected as 
the appropriate one for communication between these two nodes.

DETAILED DESCRIPTION 
In accordance with an embodiment of the present invention, when two nodes 
begin to communicate with one another they transmit information to one 
another identifying a protocol level at which they normally operate. A 
negotiated protocol is selected for future communications. 
The present invention will be described in relation to a registration 
procedure, that is, the procedure that is undertaken when, for example, 
the mobile station is first activated in a given region. It should be 
understood, however, that the invention can be used whenever intelligent 
nodes must communicate either within a network (intra-network) or across 
two networks (inter-network). 
As an example, suppose that in FIG. 1 HLR 11, in a preferred node operates 
at IS-41 Rev. C but can operate at earlier revisions (e.g., A and B) and 
MSC 22, in a preferred node operates at IS-41 Rev. A. Furthermore, assume 
that mobile station 10 is in the New York region (not shown). When the 
mobile station registers with the MSC 22, that node sends information to 
HLR 11 in Seattle identifying that it operates at protocol version A. At 
that point since Rev. C is a later (or higher) version of the protocol, 
HLR 11 can either send a message back identifying the highest protocol 
version at which it can operate, or instead, to save registration time, it 
can simply select Rev. A as the appropriate protocol level since, being a 
lower protocol level it can be implemented by MSC 22. Having selected Rev. 
A, the HLR 11 notifies MSC 22 that this will be the protocol for 
communications. 
The nodes accomplish this protocol identification and negotiation sequence 
by using a parameter in a message transmission. An example of the message 
configuration is illustrated in FIG. 4. In that configuration, a message 
will include a message type identifier 41 and a plurality of parameters 
which each can consist of some number of octets (8 bit groups). In the 
example in FIG. 4, parameter 1 has X octets and parameter 2 has Y octets. 
In accordance with the present invention, one of the parameters associated 
with the message would be a protocol identifier parameter. 
FIG. 5A illustrates an embodiment for such a parameter. The parameter would 
include a protocol level identified by bits A to D of first octet of the 
parameter. The next 3 bits of the octet (E to G) correspond to the most 
significant bits that identify the service provider while bits A to D of 
the second octet identify the least significant bits of the service 
provider. The last bit H of the octets indicates whether that particular 
octet is the last octet in this information element. 
In accordance with an example of parameter values shown in FIG. 5B, the 
intelligent node could identify the protocol associated with that node and 
the service provider to whom the node belongs. For example, if the 
protocol identifier parameter includes "0010" bits D to A in the first 
octet, then the identified protocol is IS-41 Rev. A. Alternatively, if 
bits D to A are "0100" then this indicates that the protocol is IS-41 Rev. 
C. Also, in the example of FIG. 1, since both of the intelligent nodes, 
HLR 11 and MSC 22, are in the AT&T Wireless Services provider system they 
would have a service provider octet of "0000001" as shown in FIG. 5B. 
Alternatively, the registration procedure may be initiated when the 
subscriber is being serviced by another provider as shown in FIG. 1. Under 
those circumstances, the MSC 32 of the other cellular carrier would seek 
to establish communications with HLR 11 via NACN 40. Again, the HLR 11 
would look for a protocol identification parameter and select the 
appropriate protocol for communication. 
Once the protocol selection has been established the nodes can conduct 
further communications in this protocol. It is possible that each node 
could maintain a database that identifies the protocol associated with its 
communications with other nodes. In such a circumstance, the database 
would be updated whenever the node receives a protocol identification 
parameter from the other node. As an example, HLR 11 having been told that 
MSC 22 operates at Rev. A. could automatically select that protocol when 
it initiates communications to that MSC rather than go through a protocol 
negotiation. This might be particularly advantageous for inter-network 
communications where the service provider for the HLR may not want to 
advise the other cellular carrier of the available protocol version if it 
is not necessary to do so. 
The present invention can be adapted to permit an expansion of options 
within a selected protocol. Specifically, an additional parameter is 
optionally provided which permits the intelligent node to designate a new 
codeset for communication in a message transmission. In the current IS-41 
standard it is possible to assign up to 2.8.times.10.sup.48 parameter 
encoding values. There is adequate flexibility for different operators and 
vendors to implement proprietary parameters and signals. An example of the 
differences in codesets is shown in FIG. 3. There, in code set S, 
parameter ID refers to a calling number while in code set S' the same 
parameter ID refers to billing. It is therefore desirable to permit a 
dynamic designation of a codeset for use within the selected protocol. 
Therefore, the present invention can be modified to provide a Lock Shift 
procedure that makes the management of proprietary encoding dynamic. Once 
the sending node has determined the operator of the receiving node, then 
it can change to a different codeset either temporarily or permanently. 
To initiate a Lock Shift, the sending node sends an Escape for Extension 
parameter. The Escape for Extension is a reserved parameter. The Escape 
for Extension is followed by the locking shift information element. The 
locking shift information element defines the new codeset identification 
and includes a Lock Shift bit. This bit indicates if the new codeset is 
temporary or permanent. If the new codeset is temporary then the locking 
shift is in effect for the next parameter only. If the new codeset is 
permanent, then that new codeset remains in effect until the next locking 
shift takes place. This is analogous to the operation of a keyboard where 
a shift key can be operated to enable a given other key to have at least 
two possible outcomes if depressed. That is, for example, on a keyboard if 
the shift key is depressed and the key for number "1" is subsequently 
depressed then a symbol other than "1" will be produced. 
FIGS. 6A and 6B provide examples of the format of an Escape for Extension 
parameter and the value for the parameter. In the parameter of four 
octets: the first octet identifies the parameter as the escape for 
extension parameter; the second octet identifies the length of the 
information element contents; the third octet includes the information 
element identifier and, in particular, the locking shift information 
element to identify whether this is a temporary or permanent lock shift; 
and the fourth octet identifies the contents of the information element. 
This last octet includes new/temporary codeset identification information. 
As shown in FIG. 6B, the four bits D-A in the contents of the information 
element octet (the fourth octet) identify the new/temporary codeset. 
Furthermore, bit G of the octet that identifies the locking shift 
information element indicates whether the locking shift is temporary or 
permanent. 
By employing this locking shift capability, the present invention enables 
the selection between various available codesets to thereby enhance the 
capabilities of the selected protocol. 
The present invention provides a dynamic protocol negotiation capability 
and once the protocol is selected, it also permits a dynamic codeset 
selection. In view of this flexibility, the present invention facilitates 
the communication between intelligent nodes operating with various 
protocols and codesets.