In a packet data communication system, a first communication device and a second communication device, connected to each other by an A8/a9 interface, exchange software version information informing of the version of software that is stored in, and executed by, each communication device. The software version information is included in independent, self-contained software version messages and software version acknowledgment messages that may be exchanged at any time between the first communication device and the second communication device, such as during call set up or in response to a disruptive event.
|
11. A communication device capable of operating in a wireless access network, the communication device comprising:
a memory that stores software;
a processor that assembles an a9 message intended for another communication device of the same access network, wherein the a9 message includes software version information that informs of a version of software stored in the memory; and
wherein the communication device transmits the a9 message to the another communication device over an A8/a9 interface.
6. A method for exchanging software information by a base station and a packet control function operating in a same access network over an A8/a9 interface in a packet data communication system comprising steps of:
receiving, by a first communication device, an a9 message comprising a first set of software version information informing of a version of software stored in a second communication device;
in response to receiving the a9 message comprising the first set of software version information, transmitting, by the first communication device, an a9 message comprising a second set of software version information informing of a version of software stored in the first communication device; and
wherein one communication device of the first and second communication devices is the base station and the other communication device of the first and second communication devices is the packet control function.
1. A method for exchanging software information by a base station and a packet control function operating in a same access network and over an A8/a9 interface comprising steps of:
transmitting, by a first communication device, an a9 message that is intended for a second communication device and that comprises a first set of software version information informing of a version of software stored in the first communication device;
in response to the transmission of the first set of software version information, receiving, by the first communication device, an a9 message comprising a second set of software version information informing of a version of software stored in a second communication device; and
wherein one communication device of the first and second communication devices is the base station and the other communication device of the first and second communication devices is the packet control function.
2. The method of
3. The method of
4. The method of
5. The method of
starting a timer; and
when the first communication device fails to receive the a9 message comprising the second set of software version information prior to the expiration of a predetermined time period, retransmitting, by the first communication device, the a9 message comprising the first set of software version information and restarting the timer.
7. The method of
8. The method of
9. The method of
10. The method of
12. The communication device of
13. The communication device of
14. The communication device of
15. The communication device of
16. The communication device of
|
This application is a continuation of application Ser. No. 10/192,956, entitled “METHOD AND APPARATUS FOR EXCHANGING SOFTWARE INFORMATION IN A PACKET DATA COMMUNICATION SYSTEM,” filed Jul. 9, 2002, and claims priority thereto.
The present invention relates generally to cellular communication systems, and, in particular, to data transmission protocols in a packet data communication system.
The TIA/EIA (Telecommunications Industry Association/Electronic Industries Association) IS-2001, or IOS (3GPP2 A.S0001 Inter Operability Specification), standard provides a compatability standard for cellular mobile telecommunications systems that operate as a cdma2000, 1XEV-DO, 1XEV-DV, or any other technology supported by an A.S0001/IS-2001 based Access Network. The standard ensures that a mobile station (MS) operating in a cdma2000 system can obtain communication services when operating in a cellular communication system or personal communication system (PCS) manufactured according to the standard. To ensure compatibility, radio system parameters and call processing procedures are specified by the standard, including call processing steps that are executed by an MS and a base station serving the MS in order to establish a call and digital control messages and analog signals that are exchanged between elements of an infrastructure that includes the base station.
A typical cdma2000 communication system infrastructure includes a base station in communication with a Packet Control Function (PCF). An interface between the base station and the PCF includes an A9 interface that provides a signaling interface between the base station and the PCF and an A8 interface that provides a bearer path between the base station and the PCF. These interfaces are collectively known in the IS-2001, or IOS, standard as the Aquinter reference point or A8/A9 interface.
The evolution of the IOS standard has resulted in the existence of multiple versions of the standard. As the standard has evolved, later versions of the standard support functions and provide signaling that is not included in earlier versions of the standard. A possible outcome of the co-existence of multiple versions of the standard is that a base station and a PCF that are communicating over the A8/A9 interface may each conform to a different version of the IOS standard. The entity running software conforming to the higher level version of the standard may then expect the entity running software conforming to the lower level version of the standard to support functions that the latter entity is not capable of supporting. The possible results include miscommunication between the two entities, wasted communication resources as one entity awaits responses that are not forthcoming or communicates with applications that are not supported by the other entity, and dropped telephone calls.
Furthermore, if a disruptive event occurs at either the base station or the PCF as a result of a hardware or a software failure, resulting in an entity reset, the resources allocated for supporting packet data communications remain allocated. For example, if a PCF resets, air interface traffic channel resources at base stations associated with the resetting PCF remain allocated by the base stations even though the communications supported by the packet data resources are terminated. Again this results in wasted communication resources.
Therefore a need exists for a method and an apparatus for allowing software version information to be exchanged between a base station and a PCF and for facilitating a release of communication resources in the event of a failure at either the base station or the PCF.
To address the need for a method and an apparatus for allowing software version information to be exchanged between a base station and a packet control function (PCF) and for facilitating a release of communication resources in the event of a failure at either the base station or the PCF, a packet data communication system includes a first communication device and a second communication device, connected to each other by an A8/A9 interface, that exchange software version information informing of the version of software that is stored in, and executed by, each communication device. The software version information is included in independent, self-contained software version messages and software version acknowledgment messages that may be exchanged at any time between the first communication device and the second communication device, such as during call set up or in response to a disruptive event.
Generally, an embodiment of the present invention encompasses a method for exchanging software information over an A8/A9 interface in a packet data communication system. The method includes steps of transmitting, by a first communication device, a first set of software version information informing of a version of software stored in the first communication device, and in response to the transmission of the first set of software version information, receiving, by the first communication device, a second set of software version information informing of a version of software stored in a second communication device.
Another embodiment of the present invention encompasses a method for exchanging software information over an A8/A9 interface in a packet data communication system. The method includes steps of receiving, by a first communication device, a first set of software version information informing of a version of software stored in a second communication device, and in response to receiving the first set of software version information, transmitting, by the first communication device, a second set of software version information informing of a version of software stored in the first communication device.
Still another embodiment of the present invention encompasses a communication device capable of operating in a packet data communication system. The communication device includes a memory that stores software and a processor that assembles a message that includes software version information, wherein the software version information informs of a version of software stored in the memory and wherein the communication device transmits the message over an A8/A9 interface.
The present invention may be more fully described with reference to
Communication system 100 comprises a wireless packet data communication system. In order for MS 102 to establish a packet data connection with an external network 118 connected to infrastructure 116, base station 104, PCF 106, and PDSN 108 operate in accordance with well-known wireless telecommunications protocols. By operating in accordance with well-known protocols, a user of MS 102 can be assured that MS 102 will be able to communicate with infrastructure 116 and establish a packet data communication link with external network 118 via the infrastructure. Preferably, communication system 100 operates in accordance with the 3GPP2 and TIA/EIA (Telecommunications Industry Association/Electronic Industries Association) A.S0001/IS-2001, or IOS (Inter Operability Specification), standard, which provides a compatability standard for IS-2000, that is, cdma2000 or 1xEV-DO, systems, and infrastructure 116 is an A.S0001/IS-2001 access network. The standard specifies wireless telecommunications system operating protocols, including radio system parameters and call processing procedures. However, those who are of ordinary skill in the art realize that communication system 100 may operate in accordance with any one of a variety of wireless packet data communication systems, such as a Global System for Mobile communication (GSM) communication system, a Time Division Multiple Access (TDMA) communication system, a Frequency Division Multiple Access (FDMA) communication system, or an Orthogonal Frequency Division Multiple Access (OFDM) communication system.
In communication system 100, each of base station 104 and PCF 106 informs the other of the version of software stored in, and/or executed by, the entity by an exchange of software version information via the A8/A9 interface. The software version information is included in independent, self-contained software version messages and software version acknowledgment messages that base station 104 and PCF 106 may exchange at any time, such as during call set up or in response to a disruptive event, such as a hardware or software failure in one of the entities that results in a reset or a shut down of the entity.
The first set of software version information is included in an independent, self-contained software version message (an A9 version information message) that can transmitted between base station 104 and PCF 106 at any time, such as during call set up or in response to a failure of the hardware or the software of the base station or the PCF. The first set of software version information informs of a version of software stored in and/or executed by sending communication device 104. When sending communication device 104 transmits the first set of software version information, the sending communication device, preferably processor 120 of the sending communication device, starts (206) a timer 126.
In response to receiving the first set of software version information, receiving communication device 106 transmits (208) a second set of software version information that informs of a version of software stored in and/or executed by the receiving communication device. In one embodiment of the present invention, the second set of software version information is included in an independent, self-contained software version acknowledgment message (an A9 version information acknowledgment message) that can be transmitted between base station 104 and PCF 106 at any time.
When sending communication device 104 receives the second set of software version information, the sending communication device 104 stops (210) timer 126. When the sending communication device 104 fails to receive the second set of software version information prior to the expiration of a predetermined amount of time, preferably anywhere in a range from zero seconds to five seconds, the sending communication device retransmits (212) the first set of software version information and resets the timer. Upon sending communication device 104 receiving the second set of software version information, the logic flow ends (214). When either sending communication device 104 or receiving communication device 106 receives a responsive set of software version information, such as a software version acknowledgment message, without having first transmit a first set of software version information, the communication device ignores the responsive set of software version information.
In another embodiment of the present invention, wherein the software version information is included in a software version message, base station 104 and PCF 106 inform each other of the version of software that they are executing in response to a failure of the hardware or the software of the base station or the PCF. The same exchange of signals is followed as is depicted in
For example, when base station 104 resets, the base station transmits a software version message to PCF 106. Included in the software version message is information, in the Cause data field, informing PCF 106 of the reset. In response to receiving the first set of software version information, PCF 106 releases any A8 resources (and may initiate release of A10 (PCF to PDSN bearer channel) and PPP (point-to-point) resources) previously allocated for packet communications via base station 104. By way of another example, when PCF 106 resets, the PCF transmits a software version message to base station 104, which message includes information in the Cause data field informing the base station of the reset. In response to receiving the software version message, base station 104 may release any over-the-air interfaces that were previously allocated for packet data calls supported by PCF 106.
Software Version Message Type data field 301 identifies message 300 as a software version message and preferably includes a one byte software version message identifier. Correlation data field 302 of message 300 is used to associate a software version message with the message's corresponding software version acknowledgment message. For example, a PCF may be coupled to multiple base stations. When the PCF, such as PCF 106, resets it sends out multiple software version messages. Inclusion of a Correlation data field, or element, in each of the software version message and the software version acknowledgment message allows PCF 106 to tie a subsequently received software version acknowledgment message to the corresponding software version message that was sent by the PCF. Preferably, Correlation data field 302 includes a one byte correlation identifier 306 that identifies data field, or element, 302 as a Correlation data field, a one byte correlation data field length value 308 that corresponds to a length, or size, of Correlation data field 302, and a unique four byte correlation value 310 that is used by the sending communication device to correlate, or associate, the sent software version message with a subsequently received software version acknowledgment message.
Cause data field 303 of message 300 identifies the reason for the sending of the software version message, such as a reset by the sending communication device, or an OAM&P (Operation, Administration, Maintenance, and Performance) intervention (i.e., a deliberate intervention, such as when an operator takes down an entity for a software upgrade). Cause data field 303 preferably includes a one byte cause identifier 312 that identifies data field, or element, 303 as a Cause data field, a one byte cause data field length value 314 that corresponds to a length, or size, of Cause data field 303, and a cause value 316 that identifies the reason for the sending of the software version message.
Software Version data field 304 of message 300 includes information concerning the version of the software running on the sending communication device and may further include manufacturer and carrier software-related information. For example, Section 4.2.0 of the 3GPP2 A.S0001 or EIA/TIA IS-2001-B specification describes information that may be included in this data field. Software Version data field 304 preferably includes a one byte Software Version data field identifier 318 that identifies data field 304 as a Software Version data field, a one byte data field length value 320 that corresponds to a length, or size, of Software Version data field 304, a software version identifier 322 identifying the software version stored in and/or executed by the sending communication device, and one or more data fields 324, 326 (two shown) that include manufacturer and carrier software information, such as miscellaneous information that the carrier may wish to exchanges between different system components. In a system, such as communication system 100, operating under the IOS, or IS-2001/A.S0001, standard, software version identifier 322 preferably includes a one byte identifier of the IOS major revision level, a one byte identifier of the IOS minor revision level, and a one byte identifier of the IOS point release level.
Software version acknowledgment message 400 is preferably sub-divided into three data fields, or elements, that is, a Software Version Message, or A9 Message, Type data field 401, a Correlation data field 402, and a Software Version data field 403. Software Version Message Type data field 401 of message 400 identifies message 400 as a software version acknowledgment message and preferably includes a one byte software version acknowledgment message identifier. Correlation data field, or element, 402 of message 400 is used to associate the software version acknowledgment message with a corresponding software version message. Preferably, Correlation data field 402 includes a one byte correlation identifier 406 that identifies data field, or element, 402 as a Correlation data field, a one byte correlation data field length value 408 that corresponds to a length, or size, of Correlation data field 402, and a unique four byte correlation value 410 that is used to associate the software version acknowledgment message with a corresponding software version message.
Software Version data field 403 of message 400 includes information concerning the version of the software running on the receiving communication device and manufacturer and carrier software-related information. Once again, Section 4.2.0 of the 3GPP2 A.S0001 or the EIA/TIA/IS-2001-B specification describes information that may be included in this data field. Software Version data field 403 preferably includes a one byte Software Version data field identifier 412 that identifies data field 403 as a Software Version data field, a one byte data field length value 414 that corresponds to a length, or size, of Software Version data field 403, a software version identifier 416 identifying the software version stored in and/or executed by the receiving communication device, and one or more data fields 418, 420 (two shown) that include manufacturer and carrier software information. In a system operating under the IOS, or A.S0001/IS-2001, standard, software version identifier 416 preferably includes a one byte identifier of the IOS major revision level, a one byte identifier of the IOS minor revision level, and a one byte identifier of the IOS point release level.
By exchanging software version information, base station 104 and PCF 106 are able to communicate to each other, via the A8/A9 interface, the version of software that is stored in, and executed by, each communication device. In one embodiment of the present invention, the software version information may be included in independent, self-contained software version messages and software version acknowledgment messages that may be exchanged at any time between base station 104 and PCF 106, such as during call set up or in response to a disruptive event, such as a shut down or a reset, involving either the base station or the PCF. By exchanging software version information, base station 104 and PCF 106 are able to avoid the miscommunications and resource allocation inefficiencies that may result from one of the two entities unknowingly executing a software version that is different from the version executed by the other entity. Furthermore, the exchange of software version messages and software version acknowledgment messages conserves system resources by facilitating a release of communication resources in the event of a failure at either the base station or the PCF.
While the present invention has been particularly shown and described with reference to particular embodiments thereof, it will be understood by those skilled in the art that various changes may be made and equivalents substituted for elements thereof without departing from the spirit and scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed herein, but that the invention will include all embodiments falling within the scope of the appended claims.
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
5408419, | Apr 14 1992 | Telefonaktiebolaget L M Ericsson | Cellular radiotelephone system signalling protocol |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Jul 13 2006 | Motorola, Inc. | (assignment on the face of the patent) | / | |||
Jul 31 2010 | Motorola, Inc | Motorola Mobility, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 025673 | /0558 | |
Jun 22 2012 | Motorola Mobility, Inc | Motorola Mobility LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 029216 | /0282 | |
Oct 28 2014 | Motorola Mobility LLC | Google Technology Holdings LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035379 | /0116 |
Date | Maintenance Fee Events |
Mar 18 2013 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Apr 13 2017 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
May 31 2021 | REM: Maintenance Fee Reminder Mailed. |
Nov 15 2021 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Oct 13 2012 | 4 years fee payment window open |
Apr 13 2013 | 6 months grace period start (w surcharge) |
Oct 13 2013 | patent expiry (for year 4) |
Oct 13 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
Oct 13 2016 | 8 years fee payment window open |
Apr 13 2017 | 6 months grace period start (w surcharge) |
Oct 13 2017 | patent expiry (for year 8) |
Oct 13 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
Oct 13 2020 | 12 years fee payment window open |
Apr 13 2021 | 6 months grace period start (w surcharge) |
Oct 13 2021 | patent expiry (for year 12) |
Oct 13 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |