A method for configuring a re-configurable radio terminal through a communication network operating according to a communication system, wherein the radio terminal is configured for exchanging information with at least one node of the communication network by using the communicating system. The method is characterized by the steps of associating with the one node of the communication network a server entity configured for using a protocol layer of the communication system and including a set of operating software modules for configuring the radio terminal with at least one set of elements of protocol stack suitable to reconfigure the radio terminal; associating with the radio terminal a client entity configured for using a respective protocol layer corresponding to the protocol layer of the server entity, establishing an over-the-air connection between the radio terminal and the server entity by using the protocol layer, and downloading at least one module of the set of operating software modules from the server to the radio terminal configuring at least in part the radio terminal.
|
12. A method for configuring at least one re-configurable radio terminal user equipment/mobile station belonging to a communication network being operative according to a communication system, said communication network including a radio resource protocol layer including first messages of a protocol stack corresponding to said communication system, wherein said at least one re-configurable radio terminal user equipment/mobile station is configured for exchanging information with at least one node of said communication network via a wireless over-the-air connection, said at least one re-configurable radio station user equipment/mobile station includes a client entity configured for using said respective radio resource protocol layer, and said first messages are used for managing said wireless over-the-air connection, said method comprising:
associating with said at least one node of said communication network a server entity configured for using said radio resource protocol layer and comprising a set of operating software modules for implementing at least one set of elements of said protocol stack, said at least one set of elements of said protocol stack being adapted to reconfigure said at least one re-configurable radio terminal user equipment/mobile station, wherein said set of operating software modules are suitable for reconfiguring at least in part said radio terminal user equipment/mobile station for a further communication system;
establishing an over-the-air packet download procedure at said radio resource protocol layer; and
downloading at least one module of said set of operating software modules from said server to said at least one re-configurable radio terminal user equipment/mobile station for configuring at least in part said radio terminal user equipment/mobile station for said further communication system by using said over-the-air packet download procedure according to said communication system,
wherein said establishing an over-the-air packet download procedure comprises a set of protocol steps comprising for each of said protocol steps exchanging of second protocol messages with said at least one re-configurable radio terminal user equipment/mobile station, said second protocol messages comprising modifications solely to said radio resource protocol layer of said communication system to allow the terminal to download the new operating software.
23. A re-configurable radio terminal user equipment/mobile station configurable by carrying out a method for configuring at least one re-configurable radio terminal user equipment/mobile station belonging to a communication network being operative according to a communication system, said communication network including a radio resource protocol layer including first messages of a protocol stack corresponding to said communication system, wherein said at least one re-configurable radio terminal user equipment/mobile station is configured for exchanging information with at least one node of said communication network via a wireless over-the-air connection, said at least one re-configurable radio station user equipment/mobile station includes a client entity configured for using said respective radio resource protocol layer, and said first messages are used for managing said wireless over-the-air connection, said method comprising:
associating with said at least one node of said communication network a server entity configured for using said radio resource protocol layer and comprising a set of operating software modules for implementing at least one set of elements of said protocol stack, said at least one set of elements of said protocol stack being adapted to reconfigure said at least one re-configurable radio terminal user equipment/mobile station, wherein said set of operating software modules are suitable for reconfiguring at least in part said radio terminal user equipment/mobile station for a further communication system;
establishing an over-the-air packet download procedure at said radio resource protocol layer; and
downloading at least one module of said set of operating software modules from said server to said at least one re-configurable radio terminal user equipment/mobile station for configuring at least in part said radio terminal user equipment/mobile station for said further communication system by using said over-the-air packet download procedure according to said communication system,
wherein said establishing an over-the-air packet download procedure comprises a set of protocol steps comprising for each of said protocol steps exchanging of second protocol messages with said at least one re-configurable radio terminal user equipment/mobile station, said second protocol messages comprising modifications solely to said radio resource protocol layer of said communication system to allow the terminal to download the new operating software.
25. A non-transitory computer-readable medium containing instructions that, when executed by a computer, perform a method for configuring at least one re-configurable radio terminal user equipment/mobile station belonging to a communication network being operative according to a communication system, said communication network including a radio resource protocol layer including first messages of a protocol stack corresponding to said communication system, wherein said at least one re-configurable radio terminal user equipment/mobile station is configured for exchanging information with at least one node of said communication network via a wireless over-the-air connection, said at least one re-configurable radio station user equipment/mobile station includes a client entity configured for using said respective radio resource protocol layer, and said first messages are used for managing said wireless over-the-air connection, said method comprising:
associating with said at least one node of said communication network a server entity configured for using said radio resource protocol layer and comprising a set of operating software modules for implementing at least one set of elements of said protocol stack, said at least one set of elements of said protocol stack being adapted to reconfigure said at least one re-configurable radio terminal user equipment/mobile station, wherein said set of operating software modules are suitable for reconfiguring at least in part said radio terminal user equipment/mobile station for a further communication system;
establishing an over-the-air packet download procedure at said radio resource protocol layer; and
downloading at least one module of said set of operating software modules from said server to said at least one re-configurable radio terminal user equipment/mobile station for configuring at least in part said radio terminal user equipment/mobile station for said further communication system by using said over-the-air packet download procedure according to said communication system,
wherein said establishing an over-the-air packet download procedure comprises a set of protocol steps comprising for each of said protocol steps exchanging of second protocol messages with said at least one re-configurable radio terminal user equipment/mobile station, said second protocol messages comprising modifications solely to said radio resource protocol layer of said communication system to allow the terminal to download the new operating software.
24. A network node comprising a server entity for configuring a re-configurable radio terminal user equipment/mobile station by carrying out a method for configuring at least one re-configurable radio terminal user equipment/mobile station belonging to a communication network being operative according to a communication system, said communication network including a radio resource protocol layer including first messages of a protocol stack corresponding to said communication system, wherein said at least one re-configurable radio terminal user equipment/mobile station is configured for exchanging information with at least one node of said communication network via a wireless over-the-air connection, said at least one re-configurable radio station user equipment/mobile station includes a client entity configured for using said respective radio resource protocol layer, and said first messages are used for managing said wireless over-the-air connection, said method comprising:
associating with said at least one node of said communication network a server entity configured for using said radio resource protocol layer and comprising a set of operating software modules for implementing at least one set of elements of said protocol stack, said at least one set of elements of said protocol stack being adapted to reconfigure said at least one re-configurable radio terminal user equipment/mobile station, wherein said set of operating software modules are suitable for reconfiguring at least in part said radio terminal user equipment/mobile station for a further communication system;
establishing an over-the-air packet download procedure at said radio resource protocol layer; and
downloading at least one module of said set of operating software modules from said server to said at least one re-configurable radio terminal user equipment/mobile station for configuring at least in part said radio terminal user equipment/mobile station for said further communication system by using said over-the-air packet download procedure according to said communication system,
wherein said establishing an over-the-air packet download procedure comprises a set of protocol steps comprising for each of said protocol steps exchanging of second protocol messages with said at least one re-configurable radio terminal user equipment/mobile station, said second protocol messages comprising modifications solely to said radio resource protocol layer of said communication system to allow the terminal to download the new operating software.
1. A communication network being operative according to a communication system, said communication network including a radio resource protocol layer including first messages of a protocol stack corresponding to said communication system, the network comprising
at least one re-configurable radio terminal user equipment/mobile station configured for managing exchange of information within said communication network by using said communications system; and
at least one node of said communication network configured for managing exchange of information with said at least one re-configurable radio terminal user equipment/mobile station via a wireless over-the-air connection, said first messages being used for managing said wireless over-the-air connection;
said at least one node comprising a server entity configured for using said radio resource protocol layer of said communication network and comprising a set of operating software modules configured for implementing at least one set of elements of said protocol stack, said set of elements being adapted to reconfigure said at least one re-configurable radio terminal user equipment/mobile station, wherein said set of operating software modules are suitable for reconfiguring at least in part said radio terminal user equipment/mobile station for a further communication system,
said at least one re-configurable radio terminal user equipment/mobile station comprising a client entity configured for using a respective radio resource protocol layer corresponding to said protocol layer of said server entity, and
said server and said client entities being provided with respective over the air software modules able to manage an over-the-air packet download procedure according to said communication system between said at least one re-configurable radio terminal user equipment/mobile station and said at least one node at said radio resource protocol layer in order to download at least one module of said set of operating software modules for configuring at least in part said at least one re-configurable radio terminal user equipment/mobile station for said further communication system,
wherein said server entity and said client entity each includes at least one set of second messages comprising modifications solely to said radio resource protocol layer of said communication system to allow the terminal to download the new operating software, and
wherein said set of second messages associated respectively with said server entity and with said client entity are configured for managing said over-the-air packet download procedure.
2. The network according to
a radio access network and a core network; and wherein
said radio resource protocol layer is a protocol layer of said core network.
3. The network according to
4. The network according to
5. The network according to
a radio access network and a core network; and wherein
said radio resource protocol layer is a protocol layer of said radio access network.
6. The network according to
said radio access network comprises a radio controller, and wherein said radio resource protocol layer is a protocol layer of said radio controller.
7. The network according to
8. The network according to
9. The network according to
10. The network according to
11. The network according to
said radio terminal user equipment/mobile station contains the protocol stack of said communication system and contains only physical layer functionalities of a protocol stack for a further communication system sufficient to perform power measurements.
13. The method according to
a set of the following fields:
a first field identifying the type of the message,
a second field identifying the radio terminal user equipment/mobile station to which the message refers; and
a third field containing data information.
14. The method according to
a) receiving a request for downloading said at least one operating software module;
b) authenticating said client;
c) checking the capability of said radio terminal user equipment/mobile station of accepting said at least one operating software module downloadable from said server;
d) providing information concerning the download options;
e) segmenting said at least one operating software module into blocks; and
f) transmitting said blocks from said server to said at least one radio terminal user equipment/mobile station.
15. The method according to
monitoring the structure of said blocks downloaded to said radio terminal user equipment/mobile station.
16. The method according to
managing a set of timers limiting the time allowed for performing the over-the-air connection.
17. The method according to
allocating for each protocol step at least a pair of timers, a first timer for monitoring the protocol steps performed by said radio terminal user equipment/mobile station and a second timer for monitoring the protocol steps performed by said server,
each of said timers being started when one protocol step is started and being stopped when said one protocol step has been performed.
18. The method according to
19. The method according to
20. The method according to
21. The method according to
22. The method according to
|
This application is a national phase application based on PCT/EP2004/012165, filed Oct. 28, 2004, the content of which is incorporated herein by reference.
The present invention relates in general to radio communication networks and to reconfigurable radio terminals using a radio communication network.
More particularly, the present invention concerns the reconfiguration of a radio terminal, said reconfiguration being carried out by installing in said radio terminal an operating software downloaded over the air (OTA) from the radio communication network.
It is known from the literature (J. Mitola, “The Software Radio Architecture”, IEEE Communications Magazine, May 1995 and E. Buracchini, “The Software Radio Concept”, IEEE Communications Magazine, September 2000) that reconfigurable systems like terminals, base stations and network nodes, are equipments whose operative working mode may be reconfigured. For instance, a reconfigurable radio terminal able to work with a second generation system (2G), like GSM/GPRS (Global System for Mobile Communication/General Packet Radio Service), can be reconfigured in order to become able to work with a third generation system (3G), like UMTS (Universal Mobile Telecommunication System) or CDMA 2000 (Code Division Multiple Access 2000), with DVB-T (Digital Video Broadcasting Terrestrial) or with WLAN (Wireless Local Area Network) systems and so on. According to present disclosure, the term “system” is intended as a plurality of elements coordinated between them according to predetermined criteria, that is coordinated according to a “Standard”, in order to perform a specific function which is for instance that of operating as a communication network.
In the present document, examples of systems are the GSM system, the GPRS system, the UMTS system, the WLAN system and so on, each of them complying with a corresponding Standard.
In order to carry out the reconfiguration of a terminal, it is necessary—according to the above mentioned literature—that the operative functions of the terminal are realised with a technology which is reconfigurable. Concerning this, the reconfigurable terminals or devices are provided with a reprogrammable hardware constituted, for example, by a plurality of FPGAs (Field Programmable Gate Arrays), DSPs (Digital Signal Processors) and microprocessors: the single functionalities of the device, even at the lowest level, are performed by a software code. As a consequence, for reconfiguring a reprogrammable device, it suffices to replace the operating software managing the hardware of the device itself.
By the term “operating software” it is meant, in present description, the software, organised in libraries, which defines both the radio interface (e.g. L1, L2, L3) and the upper layers (e.g. L4 up to L7) of the protocol stack of a considered system, like for instance GSM/GPRS, UMTS and so on.
As known, in the telecommunication domain, the most employed method for obtaining a functional grouping is the OSI model (Open System Interconnection). The functionalities are grouped in functional planes represented under the form of a stack.
Each layer of the protocol stack provides services to the immediately higher layer, said services being in turn improvements of the services provided by the immediately lower layer.
The lowest layer (layer 1) is generally intended for physically transmitting the information.
According to the OSI specification, the standard number of layers is 7: respectively physical, connection, network, transport, session, presentation and application layer.
Each system, e.g. GSM/GPRS, UMTS and so on, implements the necessary part of the OSI protocol stack.
When considering a radio terminal, the benefits provided when using a reconfigurable hardware are many, but one benefit is evidently immediate: the radio terminal can be reconfigured according to the system covering the area where the terminal is located (working area). Therefore, if the terminal is used in an area covered by a second generation system, like GSM/GPRS, the terminal can be reconfigured in order to be able to receive said system; likewise, in an area covered by a third generation system, like UMTS, the terminal can be configured accordingly.
It is known from the literature (AA.VV. “Software Radio: The Challenges for Reconfigurable Terminals”, Annals of telecommunications—July/August 2002, GET Hermes and E. Buracchini “The Software Radio Concept”) that a software code may be transferred or downloaded to a terminal at least in three different ways:
Concerning software downloading, the fundamental steps of a generic protocol allowing to manage the downloading of a software to a terminal have been defined in the framework of the Software Defined Radio Forum (SDR Forum) as reachable via the URL www.sdrforum.org.
The protocol as defined by SDRF is of the client-server type, per se known.
The downloading protocol steps are the following ones:
It is known from prior art, e.g. E. Buracchini, “The Software Radio Concept”, IEEE Communications Magazine, September 2000, that the software downloading via radio or OTA foresees the use by the terminal of a radio channel. It is known—according to the above mentioned literature—to download the software code in two different ways, depending on the typology of the radio channel:
An example of “out of band” software download is for instance described in the Japanese Patent Application No. 2001061186. This document describes a system and a method for downloading software content over-the-air. When a radio terminal is switched on, it seeks on an universal channel what the current system in the working area is and carries out the software download relative to the indicated system.
Considering the “out of band” mode, according to prior art, it is needed to implement a dedicated radio channel and therefore dedicated equipments in the network for its implementation.
An example of “in band” software download is for instance described in the US Patent Application No. 2003/0163551. This document describes a system and a method for downloading software over-the-air by using dedicated channels during the negotiation steps between server and terminal (capability exchange, authentication, billing and so on), and by using shared common channels during the download procedure in order to provide the download service to as many users as possible simultaneously, without imposing a handicap on the available radio resources.
When considering the “in band” download way, the documents AA.VV., “Architecture Of IP Based Network Elements Supporting Reconfigurable Terminals”, SCOUT Workshop, 16 Sep. 2003, and IST-2001-34091 SCOUT, D4.1.1 “Requirements on network and security architecture and traffic management schemes for download traffic based on IP principles in cellular and ad hoc networks” suggest to modify deeply some protocols and some network nodes, e.g. the radio access nodes and/or Core Networks nodes based on release 5 and followings of UMTS, wherein the Core Network is completely based on IP (Internet Protocol), in order to make it possible to manage the download of the operating software.
Such modifications imply a considerable effort for the equipment manufacturers and for the network operators and dramatically impact on the Standards of the existing cellular systems.
Therefore the known “in band” techniques exhibit the limit that, when it is desired to add to an already existing cellular network, like for instance GSM/GPRS or UMTS, the operating software download management for reconfigurable terminals, heavy modifications to the protocols and to the network nodes are necessary.
Applicant notes that known prior art both in case of “in band” way and “out of band” way provides for deeply modifying some protocols and some network nodes.
A further problem of the known prior art is the management of the inter-system hand-over, that according to the present Standard, is defined as:
According to the known standard the inter-system hand-over requires multimode terminals, i.e. terminals supporting the whole protocol stack of each cellular system by using ASIC (Application Specific Integrated Circuit) technology. See, for example,
The known solution has some disadvantages as high power consumption, big device size and high implementation costs.
In summary, Applicant notes that known prior art
It is therefore an object of the present invention a method and a communication network for the download of an operating software for configuring a radio terminal without a huge modification of the network nodes and related protocols.
Moreover, it is a further object of present invention a method and a communication network for enabling inter-system hand-over procedures by using configurable terminals.
The above objects are achieved through a method and a communication network as claimed in the hereby attached claims.
Moreover, the objects of the present invention are achieved through a computer program product or a set of computer program products, loadable in the memory of at least one computer and including software code portions for performing the steps of the method of the invention when the product is run on a computer as claimed. As used herein, reference to such a computer program product is intended to be equivalent to reference to a computer-readable medium containing instructions for controlling a computer system to coordinate the performance of the method of the invention. Reference to “at least one computer” is evidently intended to highlight the possibility for the present invention to be implemented in a distributed modular fashion.
In a preferred embodiment, the downloading of the operating software for reconfiguring the radio terminal is achieved by providing to modify, solely, one layer of the radio protocol stack in the terminal and in at least one node of the network with respect to the Standard, for example in a radio controller like a BSC (Base Station Controller) or a RNC (Radio Network Controller) of the network. According to the invention, the protocol in the modified layer is coherent with the recommendations provided by the SDR Forum.
According to a preferred embodiment of the invention, the Server, from which it is possible to download the operating software, resides in the radio controller, e.g. BSC or RNC, of the network.
Among the possible advantages of the invention:
Moreover, the invention provides for the use of reconfigurable terminals for managing inter system handover.
In fact, according to the preferred embodiment of the invention, it is sufficient that only the minimal functionalities for carrying out measurements on the supported systems are implemented at physical layer of the terminal.
For example, let us consider a terminal configured for operating with the GSM/GPRS system and ready to manage inter system handover to the UMTS system: according to the present invention, the terminal, configured with the whole protocol stack of the radio interface of the GSM/GPRS system, is provided with only the minimal physical layer functionalities in order to perform the power measurements on the UMTS system.
The inter-system handover is managed by downloading the full UMTS operating software via a GSM/GPRS radio channel into the terminal and by reconfiguring the terminal according to the UMTS system and by providing the minimal physical layer functionalities in order to perform the power measurements on the GSM/GPRS system.
The invention will be now disclosed hereinbelow with reference to the attached drawings of preferred but non limiting embodiments thereof, in which:
Throughout all the Figures the same references have been used to indicate components that are equal or implement substantially equivalent functions.
With reference to
The network further comprises, for example, core network nodes, such as Mobile switching Centres (MSC) and/or Serving GPRS Support Nodes (SGSN) and/or Gateway GPRS Support Nodes (GGSN), not evidenced in
The terminal MS is connected through a radio interface to the BTS node which is connected to the BSC node.
According to the preferred embodiment of the invention the terminal MS, comprises a first entity referenced as OTA-Client and a second entity, of known type, referenced as radio resource protocol RR; the OTA-Client is at the same protocol level or layer and co-operates with the radio resource protocol RR.
The RR entity works, for example, according to GSM/GPRS standard ETSI 04.18 and comprises functionalities, as will be disclosed later on, for communicating with the OTA-Client and a RR corresponding entity in the base station controller BSC. The OTA-Client comprises a software module able to completely manage the download procedure of the complete operating software or part of it from a OTA corresponding entity in the base station controller BSC referenced as OTA server.
The BSC comprises a first entity referenced as OTA-server and a second entity, of known type, referenced as radio resource protocol RR.
The OTA-server is at the same protocol level and co-operates with the radio resource protocol RR.
The RR entity works, for example, according to GSM/GPRS standard ETSI 04.18 and comprises functionalities, as will be disclosed later on, for communicating with the OTA-server and the RR corresponding entity in the mobile terminal MS.
The OTA-server comprises a software module able to completely manage the download procedure of the complete operating software or a part of it to the OTA-Client.
The OTA-server further comprises the operating software or is able to recover it. The architecture of the OTA-Server provides a context called Client-Context for each OTA-Client that has an active download session, as will be disclosed later on.
The terminal MS comprises upper and lower layers of the GSM/GPRS protocol. The lower layers are referenced as RAT (Radio Access Technology) GSM/GPRS and comprise the entities OTA client, the radio resource RR and the physical (L1) and DL (Data Link) (L2) according to the GSM/GPRS standard.
The terminal MS further comprises a physical layer (L1U) according to a further standard, e.g. the UMTS standard, including at least functionalities for executing layer 1 measurements compliant to the further standard.
The terminal MS as disclosed is able to be reconfigured by downloading the operating software of a further standard as will be disclosed later on.
The operating software, as considered in the preferred embodiment of the invention, comprises a set of operating software modules, preferably a plurality of software modules for configuring the terminal MS according to a predetermined communication system.
The invention provides for the downloading of all operating software modules constituting a protocol stack employed in order to configure the radio terminal MS in accordance, for example, to a further predetermined communication system.
As a skilled person could understand, it is also possible, according to further embodiments of present invention, to download software modules constituting solely a part of the protocol stack corresponding to the communication system in use or the further communication system.
Such further embodiments could be useful with the aim, for example, of inserting new functionalities, updates or fixing bugs in the terminal MS.
With reference to
The terms used for naming the states are purely indicative, as it is significant the corresponding behaviour as described.
According to a preferred embodiment of present invention, the states and the relative transitions of the OTA-Client, are the followings:
With reference to
As previously remarked, the terms used for naming the states are purely indicative, as it is significant the corresponding behaviour as described.
The states and the relative transitions of the Client-Context are the followings:
In the case of GSM/GPRS, in the preferred embodiment of the invention, the RR protocol is modified by introducing new protocol messages and related fields exchanged between the OTA-Server and the OTA-Client which will be now described in detail with reference to the
In case of different systems the radio resource protocol, for example the RRC (Radio Resource Control) in the UMTS system, are modified in a similar way, as could be understandable by a skilled person.
In the following, the terms used for naming the messages and related fields are purely indicative, as it is significant the corresponding definition as described. With reference to
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
With reference to the
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
With reference to
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
With reference to
With reference to
With reference to
With reference to
With reference to
Again with reference to
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
Again with reference to
Again with reference to
With reference to
Again with reference to
Again with reference to
With reference to
Again with reference to
Again with reference to
The operating software is transmitted from the OTA-Server to the OTA-Client by using, in the preferred embodiment, a window protocol of known type, based, for example, on two basic Protocols Data Units, or PDUs, called Block and Ack, as will be described later on.
With reference to
With reference to
The modifications to the RR protocol foreseen by the preferred embodiment of the invention, are based on the introduction of primitives between the OTA-Client and the radio resource RR on the terminal MS side and on the introduction of primitives between the OTA-Server and the radio resource RR at the base station controller BSC side.
The terms used for naming the primitives and related fields are purely indicative, as it is significant the corresponding definition as described.
First are described the primitives between the OTA-Client and the radio resource RR at the terminal MS side.
The primitive Download Request Ind is sent from the radio resource RR at the terminal MS side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Ack Ind is sent by the OTA-Client to the radio resource RR at the terminal MS side. The fields provided in this primitive are the following ones:
The primitive Download Nack Ind is sent from the OTA-Client to the radio resource RR at the terminal MS side. The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Authentication Req is sent from the radio resource RR at the terminal MS side to the OTA-Client.
The fields provided in this primitive are the following ones:
The primitive Authentication Rsp is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Capability Req is sent from the radio resource RR at the MS side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Capability Rsp is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Description Req is sent from the radio resource RR at the terminal MS side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Accept Cnf is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Accept Rej is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Req is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Rsp is sent from the radio resource RR at the terminal MS side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Cnf is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Rej is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Test Description Req is sent from the radio resource RR at the terminal MS side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Installation Cnf is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Installation Rej is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Data Ind is sent from the radio resource RR at the terminal MS side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Data Req is sent from the OTA-Client to the radio resource RR at the terminal MS side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitives exchanged between the OTA-Server and the radio resource RR at the base station controller BSC side are described in the following.
The primitive Download Initiation Ind is sent from the OTA-Client to the radio resource RR at the base controller station BSC side. The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Ack Ind is sent by the radio resource RR at the base controller station BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Nack Ind is sent from the radio resource RR at the base controller station BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Authentication Req is sent from the OTA-Client to the radio resource RR at the base controller station BSC side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Authentication Rsp is sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Capability Req is sent from the OTA-Client to the radio resource RR at the base station controller BSC side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Capability Rsp is sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Description Req is sent from the OTA-Client to the radio resource RR at the base station controller BSC side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Accept Cnf is sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Download Accept Rej is sent from the radio resource RR at the base controller station BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Req sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Rsp is sent by the OTA-Client to the radio resource RR at the base station controller BSC side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Cnf is sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive License Rej is sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Test Description Req is sent from the OTA-Server to the radio resource RR at the base station controller BSC side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Installation Cnf is sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Installation Rej is sent from the radio resource RR at the base station controller BSC side to the OTA-Client.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Data Req is sent from the OTA-Server to the radio resource RR at the base station controller BSC side.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
The primitive Data Ind is sent from the radio resource RR at the base station controller BSC side to the OTA-Server.
The fields provided, in the case of GSM/GPRS, are at least a set of the following ones:
With reference to
The behaviour of OTA-Client and the OTA-Server are independent from the system.
The primitives exchanged between OTA-Client or OTA-Server and the respective RR are dependent from the system, and according to present example are referenced to GSM/GPRS system.
In the following description the start/stop actions of the timers are not described, as they are linked to the states in which the entities are, as previously described.
With reference to
In general, if the field OTA-Client ID does not match with the identifier of the OTA-Client receiving a primitive, said primitive is ignored.
When the OTA-Client receives the primitive Download Request Ind:
When the OTA-Client receives the primitive Authentication Req:
When the OTA-Client receives the primitive Capability Req:
When the OTA-Client receives the primitive Download Description Req:
When the OTA-Client receives the primitive License Rsp:
When the OTA-Client receives the primitive Test Description Req:
With reference again to
In general, at each primitive received it is analysed the field OTA-Client ID and it is considered the OTA-Client-Context relative to said identifier; if no OTA-Client-Context is present for the received identifier, the primitive is ignored.
When the OTA-Server receives the primitive Download Ack Ind:
When the OTA-Client-Context receives the primitive Download Nack Ind:
When the OTA-Client-Context receives the primitive Authentication Rsp:
When the OTA-Client-Context receives the primitive Capability Rsp:
When the OTA-Client-Context receives the primitive Download Accept Cnf.
When the OTA-Client-Context receives the primitive Download Accept Rej:
When the OTA-Client-Context receives the primitive License Req:
When the OTA-Client-Context receives the primitive License Cnt.
When the OTA-Client-Context receives the primitive License Rej:
When the OTA-Client-Context receives the primitive Installation Cnf:
When the OTA-Client-Context receives the primitive Installation Rej:
The operation of the window protocol according to which the data are transferred from the OTA-Server to the OTA-Client is now described.
From the point of view of the OTA-Server, when the software download begins, the operating software is, for example, encrypted with a encrypt key and with an encryption algorithm of known type, e.g. AES algorithm.
The encrypted operating software is segmented into blocks having, for example, a limited size, e.g. 1-2 kBytes. It is allocated a bit mask BITMASK having a number of bits equal to the number of radio blocks into which the operating software has been segmented and for each bit the value “0” is set; each bit of the mask corresponds to the radio block, the number of which is equal to the bit position, that is the first bit corresponds to the first radio block, the second bit to the second radio block and so on. The first N radio blocks BLOCK constituting the operating software are sent. The timer T401 is started. At the reception of each message Ack:
From the point of view of the OTA-Client, when the software download begins, it is allocated a bit mask BITMASK equal to the number of radio blocks into which the software has been segmented and the value of each bit is set to “0”; each bit of the mask corresponds to the radio block, the number of which is equal to the bit position, that is the first bit corresponds to the first radio block, the second bit to the second radio block and so on. Then the timer T400 is started. When receiving each radio block BLOCK:
In summary, according to the example, the functional behaviour of OTA client and OTA server is as follows:
With reference to
With reference to
b. If the decryption operation is unsuccessful, the OTA-Client sends the primitive License_Rej to the radio resource RR, stops the timer T500 and returns to the state IDLE.
The procedure as disclosed in
The procedure may be inserted, as a skilled person could appreciate in the inter-system hand-over procedure from GSM to UMTS for a circuit call, as defined by the Standard.
In particular, the insertion may be done at RR layer, between the reception from the MSC of the HANDOVER COMMAND message of the Base Station Subsystem Application Part (BSSAP) protocol and the transmission to the MS of the INTERSYSTEM TO UTRAN HANDOVER COMMAND message of the RR protocol.
The invention can be generalised to all possible inter-system hand-over procedures specified by the current Standards.
For example, the procedure may be inserted, as a skilled person could appreciate, in the inter-system hand-over procedure from UMTS to GSM for a circuit call, as defined by the Standard. In particular, the insertion may be done at Radio Resource Control (RRC) layer, between the reception from the MSC of the RELOCATION COMMAND message of the Radio Access Network Application Part (RANAP) protocol and the transmission to the User Equipment (UE) of the HANDOVER FROM UTRAN COMMAND message of the Radio Resource Control (RRC) protocol.
The invention can, also, be generalised to inter-system handover procedures not yet standardized, as for example inter-system handover procedures between International Mobile Telecommunication 2000 (IMT 2000) and WLAN or IEEE 802.16 or IEEE 802.20 systems.
As apparent to a skilled person, the invention allows, in case of a voice call, in particular a circuit type call, to perform the download of the operating software without interrupting the call; this is possible, in the case for example of GSM/GPRS, by allocating one or more packet channels, e.g. PDTCH GPRS channels, in parallel to the circuit type channel, e.g. TCH (Traffic Channel) GSM channel, used for the circuit communication.
This feature can allow to manage the priority between voice, data and software download.
The invention has been disclosed by keeping as a reference a GSM/GPRS system and the use of the radio channels of the above system, but, as a skilled person could appreciate, the invention may be applied by using, for example, a “universal” channel.
A possible example of using a “universal” channel could be of using an “universal” channel, as defined by literature, for the operating software download procedure from the OTA Server to the OTA Client.
In case of inter-system handover, the implementation of using a “universal” channel could foresee to maintain the active connection over the radio channels of the active system e.g. GSM/GPRS system, while the operating software download procedure from the OTA Server to the OTA Client is exploited simultaneously over the aforesaid “universal” channel, adopting for example the procedure disclosed in
The “universal” channel may be used for the entire operating software download procedure or only a part of it, for example the transmission of the operating software from the OTA Server to the OTA Client.
In case a partial usage of the “universal” channel, the remaining part of the operating software download procedure may be implemented by using the radio channels of the active system.
The adoption of the “universal” channel allows to load in a more efficient way the radio resources related to active system, leaving them available to other users and to perform the operating software download procedure much more rapidly as the “universal” channel is a channel dedicated to this type of operation.
A further embodiment of the invention provides for the possibility of managing also a cell-reselection procedure, as known to a skilled person, when the terminal is, for example, in the IDLE state, between two systems, e.g. from GSM/GPRS to UMTS.
As previously remarked, the terms used for naming the primitives and related fields are purely indicative, as it is significant the corresponding definition as described.
This extension provides for the introduction of the following primitive between the OTA-Client and the radio resource RR at the terminal MS side:
The fields provided in this primitive, in the case of GSM/GPRS, are at least a set of the following ones:
OTA-Client ID: identifies the OTA-Client performing the request;
and of the following primitive between the OTA-Server and the radio resource RR at the base station controller BSC side:
The fields provided in the primitive, in the case of GSM/GPRS, are at least a set of the following ones:
OTA-Client ID: identifies the OTA-Client performing the request.
In the following it is indicated the behaviour of the context relative to the terminal MS of the OTA-Client-Context when receiving the primitive Request Download Initiation Ind:
With reference to
The procedure continues by performing the stages from the number 6 onwards of the procedure described with reference to the
The architecture and method described according to present invention has been disclosed by keeping as a reference the access network of the GSM/GPRS system.
The invention may be also applied to the access network of UMTS, UTRAN (UMTS Terrestrial Radio Access Network) or any other access networks, e.g. WLAN, IEEE 802.16, IEEE 802.20.
For example, in case of UTRAN, the invention may be implemented inserting the OTA Client and the OTA Server and related procedures, primitives and protocol messages, at the RRC layer of the UMTS system.
The invention has been disclosed by using the access network and the corresponding protocol layers both in the network side and in the terminal side
The invention may be also implemented by using the Core network and the corresponding protocol layers both in the network side and in the terminal side.
In this case, considering for example the Packet Switched Core Network of GSM/GPRS and UMTS systems, the invention may be implemented by inserting the OTA Client and the OTA Server and related procedures, primitives and protocol messages, at the GPRS Mobility Management (GMM) layer respectively of the terminal and of the Serving GPRS Support Node (SGSN) node of the Core Network.
More in particular, in the case of GSM/GPRS, the GPRS Mobility Management (GMM) layer is modified by introducing new protocol messages and related fields exchanged between the OTA-Server and the OTA-Client. The same approach could be applied for the UMTS system.
The invention has been disclosed by considering the downloading and activation of one operating software during an inter system handover procedure.
As could be apparent to a skilled person, the operating software may be downloaded and stored into the terminal, instead of being installed and run immediately.
According to this further embodiment, it is possible to install and run the operating software successively upon a request coming from the network or from the user. If the radio terminal UE/MS has enough memory and processing capability, the downloaded operating software can be stored and installed concurrently to the already existing and currently working system.
This option is useful for allowing a multi-mode working of the terminal UE/MS, in other words this option grants that the terminal is able to switch from one operating mode to another cone without the necessity to download the operating software.
In summary, thanks to the invention, it is possible to obtain at least the following advantages:
In particular, in the case of using the access network and the corresponding protocol layers both in the network side and in the terminal side, the network can fully control the software download procedure and the relative radio resources since the RR (Radio Resource) protocol has been integrated with some modifications that allow the terminal to download the new operating software, which may implement, for instance, a second generation cellular system, like GSM/GPRS, IS95, PDC (Phone Digital Cellular) or a third generation cellular system for instance belonging to the family IMT2000.
Buracchini, Enrico, Trogolo, Alessandro, Goria, Paolo
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
6463055, | Jun 01 1998 | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | Integrated radio telecommunications network and method of interworking an ANSI-41 network and the general packet radio service (GPRS) |
6577614, | May 27 1999 | Qwest Communications International Inc | System and method for OTA over CDMA data channel |
6751227, | Nov 02 1999 | Qualcomm Incorporated | Signalling method |
6799203, | Dec 29 2000 | Nokia Technologies Oy | WTA based over the air management (OTAM) method and apparatus |
7035932, | Oct 27 2000 | RPX Corporation | Federated multiprotocol communication |
20020012329, | |||
20020085568, | |||
20030035386, | |||
20030036387, | |||
20030084165, | |||
20030163551, | |||
20040049561, | |||
20040072563, | |||
20040073901, | |||
20040098715, | |||
20040120281, | |||
20040147262, | |||
20040176129, | |||
20050007988, | |||
20050027789, | |||
20050033829, | |||
20060020950, | |||
20060130053, | |||
WO2058421, | |||
WO3039175, | |||
WO2006045334, | |||
WO2006045335, | |||
WO2007057031, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Oct 28 2004 | Telecom Italia S.p.A. | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Date | Maintenance Schedule |
Nov 11 2017 | 4 years fee payment window open |
May 11 2018 | 6 months grace period start (w surcharge) |
Nov 11 2018 | patent expiry (for year 4) |
Nov 11 2020 | 2 years to revive unintentionally abandoned end. (for year 4) |
Nov 11 2021 | 8 years fee payment window open |
May 11 2022 | 6 months grace period start (w surcharge) |
Nov 11 2022 | patent expiry (for year 8) |
Nov 11 2024 | 2 years to revive unintentionally abandoned end. (for year 8) |
Nov 11 2025 | 12 years fee payment window open |
May 11 2026 | 6 months grace period start (w surcharge) |
Nov 11 2026 | patent expiry (for year 12) |
Nov 11 2028 | 2 years to revive unintentionally abandoned end. (for year 12) |