CA2227086C - Method and apparatus for dynamic negotiation of protocols - Google Patents
Method and apparatus for dynamic negotiation of protocols Download PDFInfo
- Publication number
- CA2227086C CA2227086C CA002227086A CA2227086A CA2227086C CA 2227086 C CA2227086 C CA 2227086C CA 002227086 A CA002227086 A CA 002227086A CA 2227086 A CA2227086 A CA 2227086A CA 2227086 C CA2227086 C CA 2227086C
- Authority
- CA
- Canada
- Prior art keywords
- protocol
- network node
- messaging
- codeset
- designated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
Abstract
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.
Description
CA 02227086 1998-01-1~
METHOD AND APPARATUS FOR DYNAMIC
NEGOTIATION OF PROTOCOLS
BAC~CGROUND OF THE INVENTION
The present invention is directe- to a method and apparatus fo~ selecting a communicat on pro~ocol between nodes in a r.etwork. More specifical_v, the present invention is directed to method and apparatus for dynamically negotiating a protocol b__ween two nodes where at least one of the nodes is capable of operating in at least two different protocols.
It is known in a telecommunicat- n network to provide a plurality of nodes that have varying degrees of :intelligence. The nodes are usefu in con~rolling the operation of the network. More specifically, in an env:ironment such as a network for wireless comrnunications, it is often necessary to transfer information about a subscriber and tre 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 subscriberls 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 servic provider.
For instance, the subscriber could travel to New York and seek service in the New York region. It may so happ~n 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 CA 02227086 1998-01-1~
upgrades of the IS-41 protocol (for example, revision A, revision B, or revisior. C) throughout that provider~s network. Since it is r.~t feasible to install upgrades in each facility simultaneously, there may exist periods in time where various r.~des 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 ~SC in Seattle, 12, couli have been upgradea to IS-41 Rev. C. An example of the problem that may arise is illustrated in FIG. 2.
FIG. 2 shows that or 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 ident-fied by message code 1 while in protocol C, it might be identified by message code 75.
Thus, if nothing is dore to facilitate the commlnications between .~SC 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 differenc_s can also arise, and thereby create problems, when t:-e subscriber activates the mobile station in a reg on that is serviced by a service provider other ~han 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 ac~ivated ar MSC 32 in that region receives the activation request rom the mobile station and then creates a query through an interconnect communications network North American Cellular Network (NACN), 40.
This query back to the ~LR 11 is the same as that which occurred in the first example described above where the mobile station has moveà 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
CA 02227086 1998-01-1~
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 protoc -.
In a different environment, .-.e user to network nterface environment, it is knowr. that one terminal ~user) can operate at one protoco while another terminal ~user) operates at a secor.d different protocol.
This environment differs from the network to node environment described above in tha~ no node to node protocol adjustment takes place; ~ initial network node adapts to the fixed protoco ~~ the end user terminal, but the actual network protocol, i.e., node to r.ode, remains unchanged.
CCITT Volume VI FASCICLE V1.11 (published in 1988) describes that in this user to network interface environment every message will ir.clude a protocol discriminator or identifier. This will serve to identify the protocol with which ~'-.e message is associated. However, there is no r.echanism for neaotiating a protocol for commurlications. In fact, ~f ,he receiver cannot communicate in _he identified prot~col the message is simply discarded. The receiver and transmitter do not attempt to _-nd a mutually acceptable communication protocol and again there is the 'ikelihood that communication will be quite limited.
It is therefore desirable to provide a method by which these intelligent nodes opera_ing at different protocols can communicate with one another while reducing the likelihood of losing data or creating some mishandling of information.
SU~nMARY 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 CA 02227086 1998-01-1~
communication protocol between first and second network nodes by; in a first step, receiving at the second netw~rk node, an indication of the operating communication protocol of the first netwcrk node; then, base~ on the indication, a selection is made as to a desi~nated protocol from a plurality of communication prot~cols at which the second network node is capable of oper~ting. 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 mish~ndling 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 pres~nt invention provides for dynamic selection of a codeaet within a selected protocol. In accordance with the selection, it is possible that one of the network nodea can signal to the other network noae that it is switching codesets within the protocol and can designate whether it is switching codesets indefinitely or only for h~ next parameter.
W-th regard to protocol selectio-., typically the common protocol level to be used is easily determined by noae, 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 commllnication between these two nodes.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates an example of a cellular CA 02227086 1998-01-1~
configuration in which the present invention can be employed.
FIG. 2 illustrates an example of differences between levels of the same communication protocol.
FIG. 3 illustrates an example of differences between parameters in different codesets w,thin a given protocol.
FIG. 4 provides a diagram representation of the contents of a message transferred from one node to another within the network shown in FIG. 1.
FIGS. 5A and 5B show an example of formats for information for identi ying a protocol as between ncdes and the meaning of the information within the identifier.
FIGS. 6A and 6B ill ustrate a format of informat-on to be used to select a codeset within a given protocol and the meaning of the nformation contained in that format.
DETAILED DESCRIPTION
In accordance with an embodiment of the presen~
invention, when two nodes begin to communicate with one another they transmit in ormation 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 rela-ion to a registration procedure, that is, the procedure _hat is undertaken when, for example, the mobile station s firct activated in a given region. It should be understood, however, that the invention can be used wherever intelligent nodes must communicate either within a network (intra-network) or across two netwcrks (inter-network).
As an example, suppose that in FIC. 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 CA 02227086 1998-01-1~
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 a~ protocol version A. At that point since Rev. ~ 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 configura~lon, a message will include a message type identifier 41 and a plurality of parameters which each can ccnsist of some number of octets (8 bit groups). In the example 'n FIG. 4, parameter 1 has X octets and parame.er ~ has Y oc t ets.
In accordance with the present invention, one of the parameters associated with the message would be a protocol identifier parameter.
FIG. -A illustrates an embodiment for such a parameter. The parameter would include a protocol level idertified by bits A to D of f rst 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 c' the second octet identify the least significanr 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 CA 02227086 1998-01-1~
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 prot~col 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 th s 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 woul~ see~ to establish communications with HLR 11 via NACN 40. Again, the HLR 11 would look for a protocol identification parameter and select the appropriate prot~col for communication.
Once the protocol selection has been established the nodes can conduct further communications in this prot~col. It is possible that each node could maintain a database that identifies the protocol associated with its commu-,ications 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 ll 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-netw~rk 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 CA 02227086 1998-01-1~
expansion of options within a selected pro~ocol.
Specifically, an additional parameter is optionally provided which permits the intelligent node to designate a new codeset for ommunication in a message transmission. In the current IS-41 standard it is possible to assign up to 2.8 x 10~ 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 Shirt 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 Extens on parameter. The Escape for Extension is a reserved parameter. The Escape for Ex~ension is fcllowed by the locking shi--t 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 codese_ is permanent, then that new codeset remains in effect ntil the next locking shift takes place. This is ana'ogous to the operation of a keyboard where a shift key can be operated to enable a given other key to have Gt 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 oc,et 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 ~he selected pro~ocol.
The presen- inventior provides a dynamic protocol negstiation 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 ope~ating wi~h various protocols and codesets.
METHOD AND APPARATUS FOR DYNAMIC
NEGOTIATION OF PROTOCOLS
BAC~CGROUND OF THE INVENTION
The present invention is directe- to a method and apparatus fo~ selecting a communicat on pro~ocol between nodes in a r.etwork. More specifical_v, the present invention is directed to method and apparatus for dynamically negotiating a protocol b__ween two nodes where at least one of the nodes is capable of operating in at least two different protocols.
It is known in a telecommunicat- n network to provide a plurality of nodes that have varying degrees of :intelligence. The nodes are usefu in con~rolling the operation of the network. More specifically, in an env:ironment such as a network for wireless comrnunications, it is often necessary to transfer information about a subscriber and tre 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 subscriberls 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 servic provider.
For instance, the subscriber could travel to New York and seek service in the New York region. It may so happ~n 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 CA 02227086 1998-01-1~
upgrades of the IS-41 protocol (for example, revision A, revision B, or revisior. C) throughout that provider~s network. Since it is r.~t feasible to install upgrades in each facility simultaneously, there may exist periods in time where various r.~des 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 ~SC in Seattle, 12, couli have been upgradea to IS-41 Rev. C. An example of the problem that may arise is illustrated in FIG. 2.
FIG. 2 shows that or 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 ident-fied by message code 1 while in protocol C, it might be identified by message code 75.
Thus, if nothing is dore to facilitate the commlnications between .~SC 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 differenc_s can also arise, and thereby create problems, when t:-e subscriber activates the mobile station in a reg on that is serviced by a service provider other ~han 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 ac~ivated ar MSC 32 in that region receives the activation request rom the mobile station and then creates a query through an interconnect communications network North American Cellular Network (NACN), 40.
This query back to the ~LR 11 is the same as that which occurred in the first example described above where the mobile station has moveà 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
CA 02227086 1998-01-1~
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 protoc -.
In a different environment, .-.e user to network nterface environment, it is knowr. that one terminal ~user) can operate at one protoco while another terminal ~user) operates at a secor.d different protocol.
This environment differs from the network to node environment described above in tha~ no node to node protocol adjustment takes place; ~ initial network node adapts to the fixed protoco ~~ the end user terminal, but the actual network protocol, i.e., node to r.ode, remains unchanged.
CCITT Volume VI FASCICLE V1.11 (published in 1988) describes that in this user to network interface environment every message will ir.clude a protocol discriminator or identifier. This will serve to identify the protocol with which ~'-.e message is associated. However, there is no r.echanism for neaotiating a protocol for commurlications. In fact, ~f ,he receiver cannot communicate in _he identified prot~col the message is simply discarded. The receiver and transmitter do not attempt to _-nd a mutually acceptable communication protocol and again there is the 'ikelihood that communication will be quite limited.
It is therefore desirable to provide a method by which these intelligent nodes opera_ing at different protocols can communicate with one another while reducing the likelihood of losing data or creating some mishandling of information.
SU~nMARY 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 CA 02227086 1998-01-1~
communication protocol between first and second network nodes by; in a first step, receiving at the second netw~rk node, an indication of the operating communication protocol of the first netwcrk node; then, base~ on the indication, a selection is made as to a desi~nated protocol from a plurality of communication prot~cols at which the second network node is capable of oper~ting. 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 mish~ndling 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 pres~nt invention provides for dynamic selection of a codeaet within a selected protocol. In accordance with the selection, it is possible that one of the network nodea can signal to the other network noae that it is switching codesets within the protocol and can designate whether it is switching codesets indefinitely or only for h~ next parameter.
W-th regard to protocol selectio-., typically the common protocol level to be used is easily determined by noae, 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 commllnication between these two nodes.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates an example of a cellular CA 02227086 1998-01-1~
configuration in which the present invention can be employed.
FIG. 2 illustrates an example of differences between levels of the same communication protocol.
FIG. 3 illustrates an example of differences between parameters in different codesets w,thin a given protocol.
FIG. 4 provides a diagram representation of the contents of a message transferred from one node to another within the network shown in FIG. 1.
FIGS. 5A and 5B show an example of formats for information for identi ying a protocol as between ncdes and the meaning of the information within the identifier.
FIGS. 6A and 6B ill ustrate a format of informat-on to be used to select a codeset within a given protocol and the meaning of the nformation contained in that format.
DETAILED DESCRIPTION
In accordance with an embodiment of the presen~
invention, when two nodes begin to communicate with one another they transmit in ormation 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 rela-ion to a registration procedure, that is, the procedure _hat is undertaken when, for example, the mobile station s firct activated in a given region. It should be understood, however, that the invention can be used wherever intelligent nodes must communicate either within a network (intra-network) or across two netwcrks (inter-network).
As an example, suppose that in FIC. 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 CA 02227086 1998-01-1~
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 a~ protocol version A. At that point since Rev. ~ 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 configura~lon, a message will include a message type identifier 41 and a plurality of parameters which each can ccnsist of some number of octets (8 bit groups). In the example 'n FIG. 4, parameter 1 has X octets and parame.er ~ has Y oc t ets.
In accordance with the present invention, one of the parameters associated with the message would be a protocol identifier parameter.
FIG. -A illustrates an embodiment for such a parameter. The parameter would include a protocol level idertified by bits A to D of f rst 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 c' the second octet identify the least significanr 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 CA 02227086 1998-01-1~
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 prot~col 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 th s 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 woul~ see~ to establish communications with HLR 11 via NACN 40. Again, the HLR 11 would look for a protocol identification parameter and select the appropriate prot~col for communication.
Once the protocol selection has been established the nodes can conduct further communications in this prot~col. It is possible that each node could maintain a database that identifies the protocol associated with its commu-,ications 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 ll 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-netw~rk 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 CA 02227086 1998-01-1~
expansion of options within a selected pro~ocol.
Specifically, an additional parameter is optionally provided which permits the intelligent node to designate a new codeset for ommunication in a message transmission. In the current IS-41 standard it is possible to assign up to 2.8 x 10~ 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 Shirt 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 Extens on parameter. The Escape for Extension is a reserved parameter. The Escape for Ex~ension is fcllowed by the locking shi--t 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 codese_ is permanent, then that new codeset remains in effect ntil the next locking shift takes place. This is ana'ogous to the operation of a keyboard where a shift key can be operated to enable a given other key to have Gt 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 oc,et 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 ~he selected pro~ocol.
The presen- inventior provides a dynamic protocol negstiation 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 ope~ating wi~h various protocols and codesets.
Claims (26)
1. A method for establishing a communication protocol between a first network node and a second network node wherein the second network node is capable of operating at any one of a plurality of communication protocols, the method comprising the steps of:
receiving, at the second network node, an indication of the operating communication protocol of the first network node;
based on said indication, selecting as a designated protocol a communication protocol from the plurality of communication protocols, wherein said plurality of communication protocols includes at least two protocols related to each other in that one of said protocols is of a later version than the other protocol;
storing an identification of the selected communication protocol in association with said first network node and when subsequently initiating communication from said second network node to said first network node referring to the stored identification to select a communication protocol; and sending an indication of said designated protocol to the first network node, wherein after the second network node sends an indication of said designated protocol to the first network node said second network node performing the steps of:
selecting a messaging codeset from a plurality of messaging codeset within said designated protocol; and indicating the selected messaging codeset to the first network node.
receiving, at the second network node, an indication of the operating communication protocol of the first network node;
based on said indication, selecting as a designated protocol a communication protocol from the plurality of communication protocols, wherein said plurality of communication protocols includes at least two protocols related to each other in that one of said protocols is of a later version than the other protocol;
storing an identification of the selected communication protocol in association with said first network node and when subsequently initiating communication from said second network node to said first network node referring to the stored identification to select a communication protocol; and sending an indication of said designated protocol to the first network node, wherein after the second network node sends an indication of said designated protocol to the first network node said second network node performing the steps of:
selecting a messaging codeset from a plurality of messaging codeset within said designated protocol; and indicating the selected messaging codeset to the first network node.
2. The method of claim 1 wherein said designated protocol corresponds too the indicated operating communication protocol of the first network node.
3. The method of claim 1 wherein said designated protocol corresponds tea the protocol of a later version.
4. The method of claim 1 wherein said designated protocol corresponds to a protocol of an earlier version.
5. The method of claim 1 wherein said second network, prior to receiving sand indication operates in a first protocol anal wherein raid designated protocol is a protocol other than said first protocol and the indicated operating communication protocol of the first network node.
6. The method of claim 1 further comprising the step of the second network node receiving, from the first network node, an indication of a selection of a messaging codeset within said designated protocol.
7. The method of claim 1 wherein after the second network node sends an indication of said designated protocol to the first network node, said network node performing the steps of:
receiving from the first network node, an indication of a selection of a messaging codeset within said designated protocol.
receiving from the first network node, an indication of a selection of a messaging codeset within said designated protocol.
8. The method of claim 1 wherein said after the second network node sends an indication of said designated protocol to the first network node, said second network node further performing the steps of:
switching to another messaging codeset from said plurality of messaging codeset within said designated protocol; and indicating the switched messaging codeset to the first network node.
switching to another messaging codeset from said plurality of messaging codeset within said designated protocol; and indicating the switched messaging codeset to the first network node.
9. The method of claim 8 further performing the step of:
designating said switched messaging codeset is permanent.
designating said switched messaging codeset is permanent.
10. The method of claim 8 further performing the step of:
designating said switched messaging codeset is for a next parameter.
designating said switched messaging codeset is for a next parameter.
11. A network node in a communication system comprising:
a receiver that receives an indication of an operating communication protocol from another network node;
a protocol selector that selects a designated protocol from a plurality of communication protocols wherein said plurality of communication protocols includes at least two protocol related to each other in that one of said protocol is of a later version than the other protocol;
a database for snoring an identification of the selected communication protocol in association with said first network node and when subsequently initiating communication from said second network node to said first network node referring to the stored identification to select a communication protocol;
means for sending an indication of said designated protocol to the first network node;
means for selecting one of a plurality of a messaging codesets within said designated protocol; and means for sending an indication of said selected messaging codeset to the first network node.
a receiver that receives an indication of an operating communication protocol from another network node;
a protocol selector that selects a designated protocol from a plurality of communication protocols wherein said plurality of communication protocols includes at least two protocol related to each other in that one of said protocol is of a later version than the other protocol;
a database for snoring an identification of the selected communication protocol in association with said first network node and when subsequently initiating communication from said second network node to said first network node referring to the stored identification to select a communication protocol;
means for sending an indication of said designated protocol to the first network node;
means for selecting one of a plurality of a messaging codesets within said designated protocol; and means for sending an indication of said selected messaging codeset to the first network node.
12. The network node of claim 11 wherein said designated protocol corresponds to the indicated operating communication protocol of the other network node.
13. The network node of claim 11 wherein said designated protocol is different from the indicated operating communication protocol of the other network node.
14. The network node of claim 11 wherein said node, prior to receiving the indication from the other network node is designated to operate with a first protocol.
15. The network node of claim 14 wherein said designated protocol corresponds of said first protocol.
16. The network node of claim 14 wherein said designated protocol is different from both said first protocol and the indicated protocol of the other network node.
17. The network node of claim 11 further comprising:
means for switching to another messaging codeset from said plurality of messaging codesets within said designated protocol; and means for indicating the switched messaging codeset to the first network node.
means for switching to another messaging codeset from said plurality of messaging codesets within said designated protocol; and means for indicating the switched messaging codeset to the first network node.
18. The network node of claim 17 further comprising:
means for designating said switched messaging codeset is permanent.
means for designating said switched messaging codeset is permanent.
19. The network node of claim 17 further comprising:
means for designating said switched messaging codeset is for a next parameter.
means for designating said switched messaging codeset is for a next parameter.
20. A method for negotiating a common communication protocol between a first network node operating in a preferred mode at a first protocol and second network node operating in a preferred mode at a second protocol, said method comprising the steps of:
said first network node transmitting an indication of said first protocol to said second network node;
said second network node comparing the indication of said first protocol to an identification of said second protocol, wherein said first protocol and said second protocol are related to each other in that said first protocol is of a later version than said second protocol;
based on said comparison said second network node selecting a communication protocol for communication between said first network node and said second network node;
storing an identification of the selected communication protocol in association with said first network node and when subsequently initiating communication from said second network node to said first network node referring to the stored identification to select a communication protocol;
sending an indication of the selected communication protocol from said second network node to said first network node;
communicating between said first and second network nodes using the selected communication protocol; and selecting a messaging codeset from a plurality of messaging codesets within the selected communication protocol and identifying the selected messaging codeset to the other one of said first and second network nodes.
said first network node transmitting an indication of said first protocol to said second network node;
said second network node comparing the indication of said first protocol to an identification of said second protocol, wherein said first protocol and said second protocol are related to each other in that said first protocol is of a later version than said second protocol;
based on said comparison said second network node selecting a communication protocol for communication between said first network node and said second network node;
storing an identification of the selected communication protocol in association with said first network node and when subsequently initiating communication from said second network node to said first network node referring to the stored identification to select a communication protocol;
sending an indication of the selected communication protocol from said second network node to said first network node;
communicating between said first and second network nodes using the selected communication protocol; and selecting a messaging codeset from a plurality of messaging codesets within the selected communication protocol and identifying the selected messaging codeset to the other one of said first and second network nodes.
21. The method of claim 20 wherein said selected communication protocol corresponds to said first protocol.
22. The method of claim 20 wherein said selected communication protocol corresponds to said second protocol.
23. The method of claim 20 wherein said selected communication protocol corresponds to a third protocol that differs from both said first and second protocols.
24. The method of claim 20 further performing the steps of:
switching to another messaging codeset from said plurality of messaging codeset within said selected communication protocol; and indicating the switched messaging codeset to the other one of said first and second network nodes.
switching to another messaging codeset from said plurality of messaging codeset within said selected communication protocol; and indicating the switched messaging codeset to the other one of said first and second network nodes.
25. The method of claim 24 further performing the step of:
designating said switched messaging codeset is permanent.
designating said switched messaging codeset is permanent.
26. The method of claim 241 further performing the step of:
designating said witched messaging codeset is for a next parameter.
designating said witched messaging codeset is for a next parameter.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/787,535 US6125122A (en) | 1997-01-21 | 1997-01-21 | Dynamic protocol negotiation system |
| US08/787,535 | 1997-01-21 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2227086A1 CA2227086A1 (en) | 1998-07-21 |
| CA2227086C true CA2227086C (en) | 2002-03-19 |
Family
ID=25141808
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002227086A Expired - Lifetime CA2227086C (en) | 1997-01-21 | 1998-01-15 | Method and apparatus for dynamic negotiation of protocols |
Country Status (4)
| Country | Link |
|---|---|
| US (3) | US6125122A (en) |
| BR (1) | BR9800328A (en) |
| CA (1) | CA2227086C (en) |
| TW (1) | TW439378B (en) |
Families Citing this family (67)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6125122A (en) * | 1997-01-21 | 2000-09-26 | At&T Wireless Svcs. Inc. | Dynamic protocol negotiation system |
| EP0859326A3 (en) * | 1997-02-14 | 1999-05-12 | Canon Kabushiki Kaisha | Data transmission apparatus, system and method, and image processing apparatus |
| DE69840972D1 (en) | 1997-02-14 | 2009-08-27 | Canon Kk | Apparatus, system and method for data transmission and apparatus for image processing |
| SG74611A1 (en) * | 1997-02-14 | 2000-08-22 | Canon Kk | Data communication apparatus and method |
| US6463078B1 (en) * | 1998-07-22 | 2002-10-08 | Microsoft Corporation | Method for switching protocols transparently in multi-user applications |
| US6356533B1 (en) * | 1998-08-07 | 2002-03-12 | At&T Corp | Apparatus and method for selecting communication modes |
| JP3621045B2 (en) * | 1998-09-25 | 2005-02-16 | 富士通株式会社 | Relay method of quality report information on ATM network |
| US6603774B1 (en) * | 1998-10-09 | 2003-08-05 | Cisco Technology, Inc. | Signaling and handling method for proxy transcoding of encoded voice packets in packet telephony applications |
| US7212543B1 (en) * | 1998-10-12 | 2007-05-01 | Teliasonera Ab | Method, system and device for establishing communication between different communication networks |
| FI105964B (en) * | 1998-12-16 | 2000-10-31 | Nokia Networks Oy | A method for managing mobile communications |
| US6697620B1 (en) * | 1999-06-24 | 2004-02-24 | Hewlett-Packard Development Company, L.P. | Method and system for providing telecommunication services across networks that use different protocols |
| US6674851B1 (en) * | 1999-08-11 | 2004-01-06 | At&T Corp. | System and method for using an intelligent peripheral to supply telephone service |
| US6590905B1 (en) * | 1999-12-22 | 2003-07-08 | Nokia Mobile Phones Ltd. | Changing XID/PDCP parameters during connection |
| US6654607B1 (en) * | 2000-02-14 | 2003-11-25 | Toshiba America Research, Inc. | Method and apparatus for enabling and monitoring mobile communication across platforms |
| US6839413B1 (en) * | 2000-02-22 | 2005-01-04 | Cisco Technology, Inc. | Method and system for data communication |
| EP1667406A1 (en) * | 2000-03-04 | 2006-06-07 | Alcatel | A method of setting up data communication with a communication device, a configuration server, and furthermore a computer software product therefor |
| US6668319B1 (en) * | 2000-04-04 | 2003-12-23 | Hewlett-Packard Development Company, L.P. | Method and mechanism for correlating and matching mutually supported protocol features of system devices |
| CA2408119A1 (en) * | 2000-05-04 | 2001-11-08 | Shwu-Yan Chang Scoggins | Method and apparatus for negotiating bearer control parameters using property sets |
| JP3936290B2 (en) * | 2000-08-14 | 2007-06-27 | ノキア コーポレイション | Communication system with mode selection procedure and method thereof |
| US7099333B2 (en) * | 2001-03-07 | 2006-08-29 | Lucent Technologies Inc. | Automatic protocol version detection and call processing reconfiguration in a communication system |
| US6963584B2 (en) * | 2001-03-26 | 2005-11-08 | Lucent Technologies Inc. | Enhanced private parameter capability in IS-41 messages |
| JP4029629B2 (en) * | 2001-03-27 | 2008-01-09 | セイコーエプソン株式会社 | COMMUNICATION DEVICE, COMMUNICATION METHOD, AND PROGRAM |
| EP1259037A1 (en) * | 2001-05-18 | 2002-11-20 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Method and devices for the interworking of nodes |
| US7543067B2 (en) * | 2001-08-01 | 2009-06-02 | Canon Kabushiki Kaisha | Flexible secure network data transfer and messaging |
| US7032045B2 (en) | 2001-09-18 | 2006-04-18 | Invensys Systems, Inc. | Multi-protocol bus device |
| DE10148873B4 (en) * | 2001-10-04 | 2006-02-16 | Siemens Ag | Method for realizing a connection setup between terminals connectable via a communication network |
| US7647389B2 (en) * | 2002-02-28 | 2010-01-12 | Alcatel-Lucent Usa Inc. | Method for configuration negotiation in a data communication system |
| US6958996B2 (en) * | 2002-04-05 | 2005-10-25 | Actiontec Electronics, Inc. | Router with automatic protocol configuration and methods of use |
| US6957086B2 (en) * | 2002-05-01 | 2005-10-18 | Microsoft Corporation | Method for wireless capability discovery and protocol negotiation, and wireless device including same |
| US7421471B2 (en) * | 2002-05-17 | 2008-09-02 | Sony Computer Entertainment America Inc. | Configuration switching: dynamically changing between network communication architectures |
| US8037196B2 (en) * | 2002-06-26 | 2011-10-11 | Alcatel Lucent | Method for maintaining communication between communication devices having inconsistent protocols |
| US7340508B1 (en) * | 2002-09-18 | 2008-03-04 | Open Invention Network, Llc | Exposing process flows and choreography controllers as web services |
| CN1266858C (en) * | 2002-11-18 | 2006-07-26 | 华为技术有限公司 | A method for implementing service rollback |
| US7171195B2 (en) * | 2002-12-09 | 2007-01-30 | Nokia Corporation | Method and apparatus for enabling a mobile station to adapt its revision level based on network protocol revision level |
| DE60233606D1 (en) * | 2002-12-11 | 2009-10-15 | Ericsson Telefon Ab L M | METHOD AND SYSTEM FOR POSITIONING IN A MOBILE COMMUNICATION NETWORK |
| US7949758B2 (en) * | 2003-02-20 | 2011-05-24 | Microsoft Corporation | Electronically negotiating application layer properties |
| US7526640B2 (en) * | 2003-06-30 | 2009-04-28 | Microsoft Corporation | System and method for automatic negotiation of a security protocol |
| US8254276B2 (en) * | 2003-08-05 | 2012-08-28 | Qualcomm Incorporated | Packet data services using version and capability information |
| US7243157B2 (en) * | 2004-02-20 | 2007-07-10 | Microsoft Corporation | Dynamic protocol construction |
| US7496649B2 (en) * | 2004-02-20 | 2009-02-24 | Microsoft Corporation | Policy application across multiple nodes |
| US7664828B2 (en) | 2004-02-20 | 2010-02-16 | Microsoft Corporation | Invalid policy detection |
| WO2005114953A1 (en) * | 2004-05-21 | 2005-12-01 | Computer Associates Think, Inc. | Method and apparatus for remote management |
| US8515424B2 (en) * | 2004-06-01 | 2013-08-20 | Qualcomm Incorporated | Connected-state radio session transfer in wireless communication systems |
| US7573901B2 (en) * | 2004-08-04 | 2009-08-11 | Sap Ag | Hub-based messaging system |
| ATE510442T1 (en) * | 2005-02-07 | 2011-06-15 | Ericsson Telefon Ab L M | FRAME FORMAT SELECTION IN A SINGLE USER LEVEL COMMUNICATIONS NETWORK |
| US8316129B2 (en) | 2005-05-25 | 2012-11-20 | Microsoft Corporation | Data communication coordination with sequence numbers |
| US9660808B2 (en) * | 2005-08-01 | 2017-05-23 | Schneider Electric It Corporation | Communication protocol and method for authenticating a system |
| US7796589B2 (en) * | 2005-08-01 | 2010-09-14 | American Power Conversion Corporation | Communication protocol |
| US20080086516A1 (en) * | 2006-10-04 | 2008-04-10 | Oracle International | Automatically changing a database system's redo transport mode to dynamically adapt to changing workload and network conditions |
| CN101304601B (en) * | 2007-05-08 | 2011-07-13 | 中兴通讯股份有限公司 | System for implementing roaming between networks as well as method for implementing roaming between networks using the same |
| US7668977B2 (en) * | 2007-09-12 | 2010-02-23 | Infineon Technologies Austria Ag | Method for exchanging information between devices connected via a communication link |
| WO2009039892A2 (en) * | 2007-09-28 | 2009-04-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, system and apparatus for protocol negotiation in a telecommunications network |
| US8549198B2 (en) * | 2009-03-27 | 2013-10-01 | Schneider Electric It Corporation | Communication protocol |
| US9094054B2 (en) * | 2009-11-30 | 2015-07-28 | Broadcom Corporation | IC controlled wireless power operation and applications thereof including control channel communication configuration |
| US8631277B2 (en) | 2010-12-10 | 2014-01-14 | Microsoft Corporation | Providing transparent failover in a file system |
| US8787372B2 (en) | 2011-04-19 | 2014-07-22 | Schneider Electric It Corporation | System and method for transferring data in a multi-drop network |
| US8700747B2 (en) | 2011-04-19 | 2014-04-15 | Schneider Electric It Corporation | System and method for automatically addressing devices in a multi-drop network |
| US9331955B2 (en) | 2011-06-29 | 2016-05-03 | Microsoft Technology Licensing, Llc | Transporting operations of arbitrary size over remote direct memory access |
| US8856582B2 (en) | 2011-06-30 | 2014-10-07 | Microsoft Corporation | Transparent failover |
| US8819170B2 (en) | 2011-07-14 | 2014-08-26 | Schneider Electric It Corporation | Communication protocols |
| US20130067095A1 (en) | 2011-09-09 | 2013-03-14 | Microsoft Corporation | Smb2 scaleout |
| US8788579B2 (en) | 2011-09-09 | 2014-07-22 | Microsoft Corporation | Clustered client failover |
| EP3072038B1 (en) | 2013-11-19 | 2019-09-18 | Wacom Co., Ltd. | Method and system for ink data generation, ink data rendering, ink data manipulation and ink data communication |
| US9621645B2 (en) * | 2013-12-30 | 2017-04-11 | Google Inc. | Device pairing via a cloud server |
| EP3243317B1 (en) * | 2015-01-05 | 2024-04-10 | Convida Wireless, LLC | Machine-to-machine protocol indication and negotiation |
| CN106161224B (en) * | 2015-04-02 | 2019-09-17 | 阿里巴巴集团控股有限公司 | Method for interchanging data, device and equipment |
| US11206191B2 (en) | 2020-05-22 | 2021-12-21 | Wipro Limited | Method and system for providing seamless data transfer between communication devices |
Family Cites Families (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2570524B1 (en) | 1984-09-19 | 1987-01-02 | Matra Communication | TELE-COMPUTER TERMINAL WITH EXTERNAL EXTENSIONS |
| US5818603A (en) * | 1996-03-29 | 1998-10-06 | Ricoh Company, Ltd. | Method and system for controlling and communicating with machines using multiple communication formats |
| US4941143A (en) * | 1987-11-10 | 1990-07-10 | Echelon Systems Corp. | Protocol for network having a plurality of intelligent cells |
| FR2631763B1 (en) | 1988-05-18 | 1990-08-10 | Telemecanique Electrique | METHOD FOR THE TRANSMISSION OF INFORMATION BETWEEN ENTITIES SUITABLE FOR TRANSMITTING AND / OR RECEIVING INFORMATION |
| US5420852A (en) | 1988-09-29 | 1995-05-30 | American Tel-A-Systems, Inc. | Digital switching system connecting buses with incompatible protocols and telephone answering system and private automatic branch exchange with integrated voice and textual message recording |
| JP2802088B2 (en) * | 1989-02-06 | 1998-09-21 | 株式会社日立製作所 | Protocol selection switching method |
| CA2017458C (en) | 1989-07-24 | 2000-10-10 | Jonathan R. Engdahl | Intelligent network interface circuit |
| GB2236454A (en) * | 1989-09-01 | 1991-04-03 | Philips Electronic Associated | Communications system for radio telephones |
| US5062108A (en) * | 1989-09-29 | 1991-10-29 | At&T Bell Laboratories | ISDN codeset conversion |
| CA2044022A1 (en) * | 1990-06-28 | 1991-12-29 | Miriam A. Nihart | Common agent computer management system and method |
| US5557745A (en) * | 1990-09-04 | 1996-09-17 | Digital Equipment Corporation | Method for supporting foreign protocols across backbone network by combining and transmitting list of destinations that support second protocol in first and second areas to the third area |
| US5278972A (en) | 1990-11-21 | 1994-01-11 | At&T Bell Laboratories | Communication system for converting ISDN signaling protocol between local and public network having first group of mandatory elements and second group of non-mandatory elements |
| US5297143A (en) * | 1990-12-03 | 1994-03-22 | Echelon Systems, Corp. | Network communication protocol including a reliable multicasting technique |
| US5309562A (en) | 1991-08-19 | 1994-05-03 | Multi-Tech Systems, Inc. | Method and apparatus for establishing protocol spoofing from a modem |
| US5231634B1 (en) * | 1991-12-18 | 1996-04-02 | Proxim Inc | Medium access protocol for wireless lans |
| US5826017A (en) * | 1992-02-10 | 1998-10-20 | Lucent Technologies | Apparatus and method for communicating data between elements of a distributed system using a general protocol |
| JPH05236138A (en) * | 1992-02-20 | 1993-09-10 | Nec Corp | Electronic exchange |
| DE4210401C1 (en) * | 1992-03-30 | 1993-09-30 | Siemens Ag | Number signaling method in a telecommunications network |
| US5339413A (en) | 1992-08-21 | 1994-08-16 | International Business Machines Corporation | Data stream protocol for multimedia data streaming data processing system |
| CA2099738C (en) * | 1992-09-25 | 1999-01-12 | William Keith Cline | Architecture for a wireless telecommunication system |
| US5586117A (en) * | 1992-11-02 | 1996-12-17 | National Semiconductor Corporation | Method and apparatus which allows devices with multiple protocol capabilities to configure to a common protocol configuration |
| GB9224076D0 (en) * | 1992-11-17 | 1993-01-06 | Ibm | Communication in a computer network |
| US5701120A (en) * | 1992-12-13 | 1997-12-23 | Siemens Business Communication Systems, Inc. | Partitioned point-to-point communications networks |
| GB2273850A (en) * | 1992-12-22 | 1994-06-29 | Ibm | ISDN Call processing |
| US5452287A (en) * | 1993-09-20 | 1995-09-19 | Motorola, Inc. | Method of negotiation of protocols, classes, and options in computer and communication networks providing mixed packet, frame, cell, and circuit services |
| US5680552A (en) * | 1994-09-20 | 1997-10-21 | Lucent Technologies Inc. | Gateway system for interconnecting different data communication networks |
| US5594721A (en) * | 1994-12-28 | 1997-01-14 | Lucent Technologies Inc. | Method and system for implementing an application protocol in a communication network |
| WO1997000570A1 (en) * | 1995-06-16 | 1997-01-03 | Harris Corporation | Dynamically negotiated application program interface method |
| US5742602A (en) * | 1995-07-12 | 1998-04-21 | Compaq Computer Corporation | Adaptive repeater system |
| JP2757832B2 (en) * | 1995-08-14 | 1998-05-25 | 日本電気株式会社 | Terminal device |
| US5826027A (en) * | 1995-10-11 | 1998-10-20 | Citrix Systems, Inc. | Method for supporting an extensible and dynamically bindable protocol stack in a distrubited process system |
| US5933784A (en) * | 1996-06-28 | 1999-08-03 | Synacom Technology, Inc. | Signaling gateway system and method |
| US5864559A (en) * | 1996-08-23 | 1999-01-26 | Ascend Communications, Inc. | ISDN modem capable of self-configuring to use one of a variety of pre-programmed ISDN protocols |
| US5841985A (en) * | 1996-09-18 | 1998-11-24 | Intel Corporation | Method and apparatus for supporting multiple protocols on a network |
| US6122503A (en) * | 1996-10-08 | 2000-09-19 | At&T Wireless Services Inc | Method and apparatus for over-the-air programming of telecommunication services |
| US6125122A (en) * | 1997-01-21 | 2000-09-26 | At&T Wireless Svcs. Inc. | Dynamic protocol negotiation system |
-
1997
- 1997-01-21 US US08/787,535 patent/US6125122A/en not_active Expired - Lifetime
-
1998
- 1998-01-15 BR BR9800328A patent/BR9800328A/en not_active Application Discontinuation
- 1998-01-15 CA CA002227086A patent/CA2227086C/en not_active Expired - Lifetime
- 1998-01-21 TW TW087100792A patent/TW439378B/en not_active IP Right Cessation
-
2000
- 2000-08-08 US US09/634,573 patent/US6445716B1/en not_active Expired - Lifetime
-
2002
- 2002-07-18 US US10/197,608 patent/US7054332B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20020176442A1 (en) | 2002-11-28 |
| US6125122A (en) | 2000-09-26 |
| US7054332B2 (en) | 2006-05-30 |
| BR9800328A (en) | 1999-06-29 |
| CA2227086A1 (en) | 1998-07-21 |
| TW439378B (en) | 2001-06-07 |
| US6445716B1 (en) | 2002-09-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2227086C (en) | Method and apparatus for dynamic negotiation of protocols | |
| RU2154358C2 (en) | Mobile telephone system and method of transmission of messages between mobile stations and servicing center for transmission of messages | |
| US8700044B2 (en) | Method and system for communicating data from wireline terminals to mobile terminals | |
| US6055424A (en) | Intelligent terminal application protocol | |
| AU8069594A (en) | A system and method for routing messages in radio communication systems | |
| JP4080471B2 (en) | Data push service system and method through heterogeneous network | |
| JPH11331957A (en) | Call processing method within exchange of communication system | |
| AU635357B2 (en) | Cordless telephone registration method | |
| JPH11515154A (en) | Mechanism and method related to network | |
| EP0640264B1 (en) | Method and apparatus for performing hand-off and inbound calling in a wireless communication system | |
| AU732466B2 (en) | Intelligent terminal application protocol | |
| EP0939561A2 (en) | Dynamic selection of interworking functions in a communication system | |
| JPH08506230A (en) | Method and system for providing supplementary services to mobile stations | |
| US6654598B1 (en) | Method for setting up call in wireless local loop system | |
| US6011842A (en) | Telecommunications network with heterogeneous operation codings | |
| JP2001148878A (en) | Paging system and paging method | |
| AU2004214571B2 (en) | Method and system for providing short message service in network interworking between wireless public network and wired/wireless private network | |
| US6487216B1 (en) | Management of a telecommunications system | |
| MXPA98000550A (en) | Method and apparatus for the dynamic negotiation of protoco | |
| KR101062136B1 (en) | Method and system of call connection using text in mobile communication network | |
| EP1095524B1 (en) | Signalling in a telecommunications network | |
| JP2001028773A (en) | Single direction message service system | |
| JPH11507199A (en) | Telecommunications system and cordless access subsystem | |
| MXPA00012965A (en) | Signalling in a telecommunications network | |
| JPH10313347A (en) | Terminal adapter |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20180115 |