JP5420604B2 - WIRELESS COMMUNICATION NETWORK AND RELATED NETWORK AND METHOD FOR SETTING A WIRELESS TERMINAL THROUGH COMPUTER PROGRAM - Google Patents

Description

  The present invention generally relates to wireless communication networks and reconfigurable wireless terminals using wireless communication networks.

  More specifically, the present invention focuses on reconfiguration of a wireless terminal, and the reconfiguration is performed by installing basic software downloaded from a wireless communication network via terrestrial (OTA) on the wireless terminal. The

  Literature (J. Mitola, “Software Radio Architecture”, IEEE Communications Society, May 1995, and E. Buraccini, “Software Radio Concepts”, IEEE Communications Society, September 2000) Thus, it is known that a reconfigurable system such as a terminal, a base station, and a network node is a facility whose basic operation mode can be reset. For example, a reconfigurable wireless terminal capable of operating in a second generation system (2G) such as GSM / GPRS (Global System for Mobile Communications / General Packet Radio Service) is UMTS (Universal Mobile Telecommunications System) or CDMA2000 (Code Division) It can be reconfigured to be operable in third generation systems (3G) such as multiple access 2000), DVB-T (digital video terrestrial broadcast), or WLAN (wireless local area network) systems. is there.

  In this disclosure, the term “system” is intended to mean a plurality of elements that are coordinated with each other according to predetermined criteria, ie, coordinated according to a certain “standard”, for example, to perform a particular function operating as a communication network. Yes.

  In this specification, examples of the system include a GSM system, a GPRS system, a UMTS system, and a WLAN system, each of which conforms to a corresponding standard.

  In order to perform terminal reconfiguration, according to the above-mentioned document, it is necessary to realize the operation function of the terminal by a reconfigurable technique. Noting this, reconfigurable terminals or devices include, for example, reprogrammable hardware comprised of multiple FPGAs (Field Programmable Gate Arrays), DSPs (Digital Signal Processors) and microprocessors. And the individual functions of the device are performed by software code, even at the lowest level. As a result, to reconfigure a reprogrammable device, it is sufficient to replace the basic software that manages the hardware of the device itself. The term “basic software” as used herein means software organized as a library, for example the radio interface of the protocol stack of the system under consideration such as GSM / GPRS, UMTS etc. (eg L1, L2, L3 ) And upper layers (for example, L4 to L7).

  As is well known, in the telecommunications field, the most commonly used method for grouping functional groups is the OSI model (Open System Interconnection). Function groups are grouped into function planes represented in the form of stacks.

  Each layer of the protocol stack provides a service to the layer immediately above, where the service is an improvement of the service provided by the layer immediately below.

  The lowest layer (layer 1) is generally intended for physical transmission of information.

  According to the OSI specification, the standard number of layers is 7, each physical, connection, network, transport, session, presentation and application layer.

  For example, each system such as GSM / GPRS and UMTS implements the necessary part of the OSI protocol stack.

  When considering wireless terminals, there are many advantages to using reconfigurable hardware, but one advantage is clearly immediate. That is, the wireless terminal can be reset by a system that covers an area (operation area) where the terminal is located. Therefore, when a terminal is used in an area covered by a second generation system such as GSM / GPRS, the terminal can be reconfigured so that the system can be received. Similarly, terminals can be set as appropriate within an area covered by a third generation system such as UMTS.

According to the literature (AA.VV. “Software Radio: Reconfigurable Terminal Issues”, Telecommunications Annual Report July / August 2002, HER Hermes, E. Buracchini “Software Radio Concept”) It is known that software code can be transferred or downloaded to a terminal in at least three different ways as described below.
A method via a smart card by using a SIM (Subscriber Identity Module) embedded in a wireless mobile terminal.
-Via an external connection using a link with a personal computer via eg an infrared / serial / USB (Universal Serial Bus) port.
-Via radio or terrestrial (OTA) by using a specific radio channel.
With respect to software downloads, the basic steps of a general protocol that allows management of software downloads to a terminal are www. sdrform. defined in the framework of the Software Defined Radio Forum (SDR Forum) available via the URL org.

  The protocol defined by SDRF is a known client-server system.

The download protocol steps are as follows:
Download start: a step in which the terminal communicates with the server on which the software to be downloaded resides with the intention of starting the download of the software.
-Mutual authentication: The terminal and server must authenticate each other.
-Mutual notification of capability: The server notifies capability information regarding the software to be downloaded, and the terminal verifies whether the software can be loaded into the terminal memory, installed and executed.
Download acceptance: The server communicates download, installation and billing options with the terminal. The terminal determines whether or not the instruction provided from the server is acceptable.
-Download and integrity test: The received code must be tested while downloading the software. The terminal requests retransmission of the radio block received incorrectly.
Installation: During the installation step, software billing and license terms are provided from the server.
-Field tests: Before starting to run the software, the terminal performs some tests with the help of the test vectors downloaded with the software code.
Non-repudiation mutual notification: Once the software code has been installed and tested, the terminal confirms with the server that the installation was successful and starts the billing procedure.

Prior art techniques such as E.I. It is known from Buracchini, "Software Radio Concept", IEEE Communications Society Journal, September 2000) that software download via radio or OTA assumes use by radio channel terminals. . According to the above-described literature, it is known that software codes are downloaded in two different methods according to the type of radio channel.
-"Out-of-band" method: When a terminal is switched on by a "universal" channel independent of the current system, it automatically tunes to that channel and provides basic software for systems operating in the operating area. Run the download.
-"In-band" scheme: using radio channels of second and third generation standard cellular systems, such as GSM / GPRS and UMTS, respectively, and terminals already operating on these channels are currently used Receive basic software for a different system than the one you are using. For example, a reconfigurable terminal operating with a second generation system such as GSM / GPRS may download a third generation system such as UMTS using a second generation radio channel on which it is operating. it can.

  An example of downloading “out-of-band” software is described, for example, in Japanese Patent Application No. 2001061186. This document describes a system and method for downloading software content via terrestrial waves. When the wireless terminal is switched on, it queries the universal channel what the current system in the operating area is and downloads software for the indicated system.

  Considering the “out-of-band” mode, the prior art requires the implementation of a dedicated radio channel, and therefore requires dedicated equipment in the network for its implementation.

  An example of downloading “in-band” software is described, for example, in US Patent Application Publication No. 2003/0163551. This document uses a dedicated channel during the negotiation steps (mutual notification, authentication, billing, etc.) between the server and the terminal, and for as many users as possible without placing a burden on available radio resources. At the same time, a system and method for downloading software via terrestrial using a shared common channel between downloads and procedures to provide a download service is described.

  In considering the “in-band” download scheme, documents AA. VV. "Network Element Architecture Based on IP Usage for Reconfigurable Terminals", SCOUT Workshop, September 16, 2003, and IST-2001-34091 SCOUT, D4.1.1, "IP in Cellular and Ad Hoc Networks "Network and security architecture requirements and traffic management schemes for download traffic based on principles" propose to make significant changes to certain protocols and certain network nodes. Example: Radio access node and / or core network node based on UMTS release 5 or later, where the core network is fully IP (Internet Protocol) compliant to allow management of basic software downloads.

  Such changes require considerable effort from equipment manufacturers and network operators and can dramatically affect existing cellular system standards.

  Thus, when the known “in-band” technology requires the addition of basic software download management of a terminal that can be reconfigured to an existing cellular network such as GSM / GPRS or UMTS, the protocol and network Indicates a restriction that requires significant changes to the node.

  Applicants note that the prior art known in the case of both “in-band” and “out-of-band” schemes makes significant changes to certain protocols and certain network nodes.

A further problem in the known prior art is the management of intersystem handover according to current standards.
-Handover from GSM / GPR system to UMTS system-Handover from UMTS system to CDMA2000 system-Handover from UMTS system to GSM / GPR system-Handover from CDMA2000 system to UMTS system

  According to known standards, intersystem handover requires multi-mode terminals, ie terminals that support the entire protocol stack of each cellular system using ASIC (application specific integrated circuit) technology.

  For example, referring to FIG. 1, an overall radio protocol stack of a GSM / GPRS system called RAT-GSM / GPRS, an overall radio protocol stack of a UMTS system called RAT-UMTS, and called RAT-CDMA2000 Figure 2 illustrates a multimode terminal including the overall wireless protocol stack of a CDMA2000 system.

Known solutions have several disadvantages, such as high power consumption, large device size, and high implementation costs.
Japanese Patent Application No. 2001061186 US Patent Application Publication No. 2003/0163551 J. et al. Mitola, “Software Radio Architecture”, IEEE Communications Journal, May 1995. E. Buraccini, “Software Radio Concept”, IEEE Communications Society, September 2000 AA. VV. “Software Radio: Challenges of Reconfigurable Terminals”, Telecommunications Annual Report July / August 2002, GET Hermes, E. Buraccini "Software Radio Concept"

In summary, the applicant pays attention to the following points regarding the known prior art.
-Download software without significant changes to network nodes that lead to inefficient use of radio resources, such as the addition of new nodes and interfaces, and changes to data signaling and transport protocols defined by the standard The problem is not solved.
-A reconfigurable terminal cannot be used for inter-system handover management.

  Accordingly, it is an object of the present invention to provide a method and communication network for downloading basic software for configuring a wireless terminal without significantly changing the network nodes and associated protocols.

  It is a further object of the present invention to provide a method and a communication network that enable inter-system handover procedures using configurable terminals.

  The above objective is accomplished by a method and communication network as set forth in the appended claims.

  Furthermore, the object of the invention is achieved by a computer program product or a set of computer program products, which products can be loaded into the memory of at least one computer, It includes software code portions that, when executed on a computer, perform the steps of the method of the present invention. As used below, a reference to such a computer program product is equivalent to a reference to a computer-readable medium containing instructions that control the computer system to coordinate the execution of the method of the present invention. The expression “at least one computer” is clearly intended to emphasize the possibility that the method of the invention may be implemented in a distributed modular fashion.

  In a preferred embodiment, the download of the basic software to reconfigure the wireless terminal is within the terminal with respect to the standard and within the network, eg the network BSC (base station controller) or RNC (radio network controller) radio controller. This is accomplished by changing only a single layer of the radio protocol stack in at least one node.

  In accordance with the present invention, the modified layer protocol is consistent with the recommendations provided by SDR-Forum.

  According to a preferred embodiment of the present invention, the server from which the basic software can be downloaded resides in a wireless controller of the network, such as a BSC or RNC.

The advantages provided by the present invention include the following.
-The software download service is transparent and visible to the network as any other signaling and traffic data flow.
-The full use of all the features of existing and future standards allows for efficient and flexible use of radio resources.
It is possible to establish a packet connection, for example during a line call, in order to download the basic software without interrupting the call.
It is possible to distinguish between different data flows and manage their priorities (eg voice, data and software downloads). For example, when the priority of the voice call is higher than the priority of the software download, the software download itself can be temporarily interrupted and the download can be resumed sequentially.

  Furthermore, the present invention enables management of inter-system handover using a reconfigurable terminal.

  Indeed, according to the preferred embodiment of the present invention, it is sufficient that only the minimum functionality for performing measurements on the supported system is implemented in the physical layer of the terminal.

  For example, consider a terminal that is configured to operate with a GSM / GPRS system and is ready to manage a system handover to a UMTS system. In accordance with the present invention, the terminal set up by the overall protocol stack of the GSM / GPRS system's radio interface has only minimal physical layer functionality to perform UMTS system capability measurements.

  Inter-system handover is the minimum for downloading the entire UMTS basic software into the terminal via the GSM / GPRS radio channel, reconfiguring the terminal according to the UMTS system, and performing capability measurements on the GSM / GPRS system It is managed by providing physical layer functions.

  The present invention is disclosed below with reference to the accompanying drawings of preferred but non-limiting embodiments thereof.

  Throughout the drawings, the same reference numerals are used to denote components that implement equivalent or substantially equivalent functionality.

  Referring to FIG. 2, the network architecture of a GSM / GPRS system including a reconfigurable terminal or mobile station MS, a base transceiver station BTS or BTS node, and a base station controller BSC or BSC node is shown.

  The network further includes core network nodes such as, for example, a mobile switching center (MSC) and / or serving GPRS support node (SGSN) and / or gateway GPRS support node (GGSN) not shown in FIG. It is out.

  The terminal MS is connected to a BTS node connected to the BSC node via a wireless interface.

  According to a preferred embodiment of the present invention, the terminal MS includes a first entity called an OTA client and a known type of second entity called a radio resource protocol RR. The OTA client is at the same protocol level or layer as the radio resource protocol RR and cooperates therewith.

  The RR entity operates, for example, according to the GSM / GPRS standard ETSI 04.18 and includes functionality for communicating with OTA clients and RR capable entities within the base station controller BSC, as disclosed below.

  The OTA client includes a software module capable of fully managing the procedure of downloading all or part of the basic software from an OTA-enabled entity in the base station controller BSC called the OTA server.

  The BSC includes a first entity called an OTA server and a known type of second entity called a radio resource protocol RR.

  The OTA server is at the same protocol level and works with the radio resource protocol RR.

  The RR entity operates, for example, according to the GSM / GPRS standard ETSI 04.18 and includes functions for communicating with the OTA server and the RR capable entity in the mobile terminal MS as disclosed below.

  The OTA server includes a software module that can completely manage the procedure of downloading all or part of the basic software to the OTA client.

  The OTA server can also contain or repair basic software.

  The OTA server architecture provides a context called client context for each OTA client that has an active download session, as disclosed below.

  FIG. 3 shows a terminal MS configured according to the present invention.

  The terminal MS includes an upper layer and a lower layer of the GSM / GPRS protocol.

  The lower layer is called RAT (Radio Access Technology) GSM / GPRS and contains OTA client, radio resource RR, physical (L1) and DL (data link) (L2) entities according to the GSM / GPRS standard.

  The terminal MS includes a physical layer (L1U) according to a further standard, for example a UMTS standard, and further includes a function for performing layer 1 measurements in accordance with at least the further standard.

  The disclosed terminal MS can be reconfigured by downloading further standard basic software as disclosed below.

  As envisaged in the preferred embodiment of the present invention, the basic software includes a set of basic software modules, preferably a plurality of software modules that configure the terminal MS according to a predetermined communication system.

  The present invention further enables the download of all basic software modules that make up the protocol stack used, for example, to set up the wireless terminal MS according to a predetermined communication system.

  As will be appreciated by those skilled in the art, according to a further embodiment of the invention, a software module consisting only of a part of the protocol stack corresponding to the communication system in use or another communication system is downloaded. It is also possible to do.

  Such further embodiments may be useful, for example, for the purpose of adding new functions, updates or bug fixes to the terminal MS.

  Referring to FIG. 4, a state transition diagram of the OTA client in the terminal MS is shown.

The terminology used to name the state is merely an indication, and the corresponding action is important as described.
According to the preferred embodiment of the present invention, the state of the OTA client and the transitions between them are as follows.
“Idle” state: If there is no active software download procedure, the OTA client is in this state. The OTA client returns to this state if the procedure is successfully completed or if a failure occurs.
“Download start” state: When the network requests the start of the basic software download procedure, the OTA client enters this state and starts timer T100. When the state transition occurs, the timer T100 is stopped. If the time of timer T100 has passed before the state transition, the OTA client returns to the “idle” state.
-"Mutual authentication" state: In this state, the OTA client performs mutual authentication with the OTA server. If an authentication request is received from the OTA server, the OTA client enters this state. The OTA client starts timer T200. Timer T200 is stopped when a state transition occurs. If the set time limit of the timer T200 has passed before the state transition or the authentication fails, the OTA client returns to the “idle” state.
“Capability Request” state: In this state, the OTA client presents its capabilities to the OTA server. An OTA client enters this state when the OTA server requests its capabilities. The OTA client starts timer T300. The timer T300 is stopped when a state transition occurs. If the timer T300 deadline has passed before the state transition, the OTA client returns to the “idle” state.
-"Download acceptance" state: In this state, the OTA client determines whether to continue downloading according to the information received by the OTA server. The OTA client enters this state when it receives a download profile to be executed from the OTA server. If the received profile is rejected, the OTA client returns to the “idle” state.
-"Software download" state: In this state, the OTA client performs a software download. If the download profile is accepted, the OTA client enters this state. The OTA client starts timer T400. Timer T400 is reset and restarted with each software block received from the OTA server. Timer T400 is stopped when a state transition occurs. If the set time limit of the timer T400 has passed before the state transition, or the download has failed, or the downloaded software does not comply with the capabilities, the OTA client returns to the “idle” state.
“Installed” state: In this state, the OTA client sends a license request to the OTA server to install the basic software. The OTA client enters this state at the end of the download. The OTA client starts timer T500. When the state change occurs, the timer T500 is stopped. If the timer T500 has expired before the state change or the license has not been accepted, the OTA client returns to the “idle” state.
-"Field Test" state: In this state, the OTA client performs some tests on the downloaded software using some test vectors received by the OTA server. If the basic software is installed, the OTA client enters this state. Once the test is complete, the OTA client returns to the “idle” state.

  Referring to FIG. 5, a state transition diagram of a client context managed by the OTA server is shown.

  As mentioned earlier, the terminology used to name the state is merely for instructional purposes, and the corresponding action is important as described.

The client context states and relative transitions are as follows:
“Idle” state: If there is no active software download procedure, the OTA client context managed by the OTA server is in this state. The OTA client context returns to this state if the procedure is completed successfully or if a failure occurs.
“Start Download” state: In this state, the OTA client context instructs the OTA client to perform the download. If it is necessary to perform a basic software download, the OTA client context enters this state and starts timer T100. Before the state transition, the timer T100 is stopped. If the time of timer T100 passes before the state transition, the OTA client context returns to the “idle” state.
-"Mutual authentication" state: In this state, the OTA client context authenticates itself and requests the OTA client to authenticate itself. If a download confirmation is received from the OTA client, the OTA client context enters this state. The OTA client context starts timer T201. The timer T201 is stopped when a state transition occurs. If the set time limit of timer T201 has passed before the state transition or authentication fails, the OTA client context returns to the “idle” state.
“Capability Request” state: In this state, the OTA client context requests the OTA client to present its capabilities. The OTA client context enters this state once authentication is complete. The OTA client context starts timer T301. The timer T301 is stopped when a state transition occurs. If the set time limit of timer T301 has passed before the state transition or if download is not possible due to capability, the OTA client returns to the “idle” state.
“Download Accepted” state: In this state, the OTA client context notifies the OTA client of the download profile. The OTA client context receives the terminal capability and enters this state if the capability is accepted. The OTA client context starts timer T302. The timer T302 is stopped when a state transition occurs. If the set time limit of timer T302 has passed before the state transition or the OTA client rejects the proposed download, the OTA client context returns to the “idle” state.
“Software Download” state: In this state, the OTA client context performs a software download to the OTA client. If the download profile is accepted by the OTA client, the OTA client context enters this state. The OTA client context starts timer T401. Timer T401 is reset and restarted with each acknowledgment signal Ack received from the client. When the state transition occurs, the timer T401 is stopped. If the set time limit of timer T401 has passed before the state transition or the download has failed, the OTA client context returns to the “idle” state.
“Installed” state: In this state, the OTA client context waits to notify the OTA client of license terms until the OTA client performs installation and testing of the downloaded software. Once the download is complete, the OTA client context enters this state. The OTA client context starts timer T501. If the state transition occurs, the timer T501 is stopped. If the set time limit of timer T501 has passed before the state transition or the license has not been accepted by the OTA client, the OTA client context returns to the “idle” state. If the OTA client context receives an acknowledgment signal regarding the successful installation by the OTA client, it returns to the “idle” state.

  In the case of GSM / GPRS, in the preferred embodiment of the present invention, the RR protocol is modified by introducing a new protocol message, as described in detail below with reference to FIGS. Are exchanged between the OTA server and the OTA client.

  For different systems, as will be appreciated by those skilled in the art, radio resource protocols such as RRC (Radio Resource Control) in UMTS systems are modified in a similar manner.

  In the following, the terms used to name the message and related fields are merely for instructional purposes, and the corresponding definitions are important as described.

  Referring to FIG. 6, the structure of a “packet download request” message is described. This message is transmitted from the radio resource RR on the base station controller BSC side to the radio resource RR on the terminal MS side.

  The OTA server uses this message to instruct the OTA client to start a download session.

In the case of GSM / GPRS, the fields provided are at least one of the following:
Message type: identifies the type of message sent (packet download request).
-OTA client ID: identifies the OTA client for which the request is to be executed.
PDCH (Packet Data Channel): Specifies the channel allocated by the network where the software download is performed.
-RRBP (relative reserved block period): As already defined in the standard GPRS, the radio block to which the radio resource RR on the terminal MS side responds is specified.
Requested download: This element contains a description string and a numeric identifier of the requested download by the network.

  Referring to FIG. 7, the structure of the “packet download Ack” message is described. This message is transmitted from the OTA client to the OTA server.

  The OTA client uses this message to notify the OTA server of confirmation of the start of the download session.

In the case of GSM / GPRS, the fields provided are at least one of the following:
Message type: identifies the type of message sent (packet download Ack).
-OTA client ID: identifies the OTA client sending the message.
-OTA client challenge number: a random number that the OTA server encrypts with its own key and an appropriate encryption algorithm, eg AES algorithm (Advanced Encryption Standard), to perform the first step of mutual authentication .

  Referring to FIG. 8, the structure of the “packet download Nack” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client notifies the OTA server that the download session cannot be started.

In the case of GSM / GPRS, the fields provided are at least one of the following:
Message type: identifies the type of message sent (packet download Nack).
-OTA client ID: identifies the OTA client sending the message.

Referring to FIG. 9, the structure of a “packet authentication request” message is described. This message is transmitted from the OTA server to the OTA client. Using this message, the OTA server notifies the OTA client of its proof and requests the OTA client to confirm it. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: The type of the transmitted message (packet authentication request) is identified.
-OTA client ID: identifies the OTA client sending the message.
-OTA server response number: A number that is encrypted by the OTA server using its own key and a suitable encryption algorithm, such as an AES algorithm, to complete the first step of mutual authentication.
OTA server challenge number: a random number that the OTA client encrypts with its key and an appropriate encryption algorithm, eg AES algorithm, to perform the second step of mutual authentication.
-RRBP: As already defined in the standard GPRS, the radio block to which the radio resource RR on the terminal MS side responds is specified.

Referring to FIG. 10, the structure of a “packet authentication response” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client notifies the OTA server of its own proof in a state where the OTA server has already been authenticated. The fields provided in the case of GSM / GPRS are at least one of the following:
-Message type: identifies the type of the transmitted message (packet authentication response).
-OTA client ID: identifies the OTA client sending the message.
-OTA client response number: Identifies the number that is encrypted by the OTA client using its own key and a suitable encryption algorithm, such as the AES algorithm, to complete the second and final steps of mutual authentication.

Referring to FIG. 11, the structure of the “packet capability request” message is described. This message is transmitted from the OTA server to the OTA client. Using this message, the OTA server requests the reconfigurability option from the OTA client. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: Identifies the type (packet capability request) of the transmitted message.
-OTA client ID: identifies the OTA client that is the destination of the message.
-RRBP: As already defined in the standard GPRS, the radio block to which the radio resource RR on the terminal MS side responds is specified.

Referring to FIG. 12, the structure of a “packet capability response” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client informs the OTA server of its reconfigurability options. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: identifies the type of the transmitted message (packet capability response).
-OTA client ID: identifies the OTA client sending the message.
-OTA client capability: describes terminal reconfigurability options.

Referring to FIG. 13, the structure of the “packet download description” message is described. This message is transmitted from the OTA server to the OTA client. Using this message, the OTA server reports data related to the download to the OTA client. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: identifies the type of the transmitted message (packet download description).
-OTA client ID: identifies the OTA client that is the destination of the message.
Download list: Contains one element selected by the OTA client for each download. The field includes the following fields.
Download block number: The number of radio blocks into which the basic software is divided before being sent to the OTA client.
-Billing criteria: A criterion for possible download billing.
-Installation criteria: Standards related to software installation.
-RRBP: As already defined in the standard GPRS, the radio block to which the radio resource RR on the terminal MS side responds is specified.

  Referring again to FIG. 8, the structure of the “accept packet download” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client confirms the download.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
Message type: identifies the type of message sent (packet download acceptance).
-OTA client ID: identifies the OTA client sending the message.

Referring again to FIG. 8, the structure of the “packet download reject” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client rejects the download. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: Identifies the type of sent message (packet download rejection).
-OTA client ID: identifies the OTA client sending the message.

Referring again to FIG. 8, the structure of the “packet license request” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client requests the key for decrypting and installing the downloaded basic software from the OTA server. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: Identifies the type of sent message (packet / license request).
-OTA client ID: identifies the OTA client sending the message.

Referring to FIG. 14, the structure of a “packet license response” message is described. This message is transmitted from the OTA server to the OTA client. Using this message, the OTA server notifies the OTA client of a key for decrypting and installing the downloaded basic software. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: The type of the transmitted message (packet / license response) is identified.
-OTA client ID: identifies the OTA client that is the destination of the message.
-Decryption key: a key used to decrypt the basic software.

Referring again to FIG. 8, the structure of the “Packet License Accept” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client notifies the OTA server that the downloaded basic software has been correctly decrypted. In the case of GSM / GPRS, the provided fields are at least one set of the following.
Message type: identifies the type of message sent (packet license acceptance).
-OTA client ID: identifies the OTA client sending the message.

Referring again to FIG. 8, the structure of the “packet license failure” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client notifies the OTA server that the downloaded basic software has not been correctly decrypted. In the case of GSM / GPRS, the provided fields are at least one set of the following.
Message type: identifies the type of message sent (packet / license failure).
-OTA client ID: identifies the OTA client sending the message.

Referring to FIG. 15, the structure of the “packet test description” message is described. This message is transmitted from the OTA server to the OTA client. Using this message, the OTA server instructs the OTA client what tests to perform before starting the downloaded basic software. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: identifies the type (packet test description) of the transmitted message.
-OTA client ID: identifies the OTA client that is the destination of the message.
Test list: contains one element for each test to be run, which further includes the following fields:
Test vector: contains a description of the test.

Referring again to FIG. 8, the structure of the “packet installation success” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client notifies the OTA server that the downloaded basic software has been successfully tested. In the case of GSM / GPRS, the provided fields are at least one set of the following.
Message type: identifies the type of message sent (packet installation successful).
-OTA client ID: identifies the OTA client sending the message.

Referring again to FIG. 8, the structure of the “packet installation failure” message is described. This message is transmitted from the OTA client to the OTA server. Using this message, the OTA client notifies the OTA server that the downloaded basic software test was not successful. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: Identifies the type of message sent (packet installation failure).
-OTA client ID: identifies the OTA client sending the message.

  The basic software is in the preferred embodiment, for example, from the OTA server by using a known type of window protocol based on two basic protocol data units or PDUs, referred to below as Block and Ack. Sent to the OTA client.

Referring to FIG. 16, a structure of a radio block Block into which basic software is divided is described. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: identifies the block type.
Block number: identifies the sequence number of the radio block. The OTA client uses this sequence number to reconfigure the entire basic software.
Data: a field containing several parts of the entire basic software.

Referring to FIG. 17, the structure of message Ack used to indicate the reception status of the terminal is described. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-Message type: identifies the type (Ack) of the transmitted message.
-Ack bitmap: a bit mask having a size equal to the total number of radio blocks into which the basic software was divided. For each radio block, it is set to “1” if the block was successfully received, and set to “0” if the block was received but was damaged or not received at all.

  The change to the RR protocol assumed by the preferred embodiment of the present invention introduces a primitive between the OTA client and the radio resource RR on the terminal MS side, and between the OTA server and the radio resource RR on the base station controller BSC side. Based on introducing primitives in between.

  The terminology used to name primitives and related fields is merely for instructional purposes, and the corresponding definition is important as described.

  First, a primitive between the OTA client and the radio resource RR on the terminal MS side is described.

  The primitive “download request Ind” is transmitted from the radio resource RR on the terminal MS side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client that is the subject of the request.
Requested download: This element contains a description string and a numeric identifier of the download requested by the network.

The primitive “download AckInd” is transmitted by the OTA client to the radio resource RR on the terminal MS side. The fields provided by this primitive include:
-OTA client ID: identifies the OTA client associated with the primitive.
OTA client challenge number: a random number that the OTA server encrypts with its key and an appropriate encryption algorithm, eg AES algorithm, to perform the first step of mutual authentication.

The primitive “Download NackInd” is transmitted from the OTA client to the radio resource RR on the terminal MS side. In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “authentication Req” is transmitted from the radio resource RR on the terminal MS side to the OTA client.

The fields provided by this primitive include:
-OTA client ID: identifies the OTA client associated with the primitive.
-OTA server response number: A number that is encrypted by the OTA server using its own key and a suitable encryption algorithm, such as an AES algorithm, to complete the first step of mutual authentication.
OTA server challenge number: a random number that the client encrypts with its key and an appropriate encryption algorithm, eg AES algorithm, to perform the second step of mutual authentication.

The primitive “authentication Rsp” is transmitted from the OTA client to the radio resource RR on the terminal MS side.
In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-OTA client response number: Identifies the number that is encrypted by the OTA client using its own key and a suitable encryption algorithm, such as the AES algorithm, to complete the second and final steps of mutual authentication.

  The primitive “capability Req” is transmitted from the radio resource RR on the MS side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “capability Rsp” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client sending the message.
-OTA client capability: describes terminal reconfigurability options.

  The primitive “download description Req” is transmitted from the radio resource RR on the terminal MS side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
Download list: Contains one element selected by the OTA client for each download. The field includes the following fields.
Download block number: The number of radio blocks into which the basic software is divided before being sent to the OTA client.
-Billing criteria: A criterion for possible download billing.
-Installation criteria: Standards related to software installation.

  The primitive “download acceptance Cnf” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “download acceptance Rej” is transmitted to the radio resource RR on the OTA terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “license Req” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “license Rsp” is transmitted from the radio resource RR on the terminal MS side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-Decryption key: a key used to decrypt the basic software.

  The primitive “license Cnf” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “license Rej” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “test description Req” is transmitted from the radio resource RR on the terminal MS side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
Test list: contains one element for each test to be run, which further includes the following fields:
Test vector: contains a description of the test.

  The primitive “install Cnf” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
The primitive “installation Rej” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “data Ind” is transmitted from the radio resource RR on the terminal MS side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-One of the radio blocks into which the basic software is divided.

  The primitive “data Req” is transmitted from the OTA client to the radio resource RR on the terminal MS side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-Ack radio block.

  The following describes primitives exchanged between the OTA server and the radio resource RR on the base station controller BSC side.

The primitive “download start Ind” is transmitted from the OTA client to the radio resource RR on the base station controller mechanism BSC side.
In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client that is the subject of the request.
Requested download: This element contains a description string and a numeric identifier of the download requested by the network.

  The primitive “download AckInd” is transmitted to the OTA client by the radio resource RR on the base station controller mechanism BSC side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
OTA client challenge number: a random number that the OTA server encrypts with its key and an appropriate encryption algorithm, eg AES algorithm, to perform the first step of mutual authentication.

  The primitive “download NackInd” is transmitted from the radio resource RR on the base station controller mechanism BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “authentication Req” is transmitted from the OTA client to the radio resource RR on the base station controller mechanism BSC side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-OTA server response number: A number that is encrypted by the OTA server using its own key and a suitable encryption algorithm, such as an AES algorithm, to complete the first step of mutual authentication.
OTA server challenge number: a random number that the client encrypts with its key and an appropriate encryption algorithm, eg AES algorithm, to perform the second step of mutual authentication.

  The primitive “authentication Rsp” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-OTA client response number: Identifies the number that is encrypted by the OTA client using its own key and a suitable encryption algorithm, such as the AES algorithm, to complete the second and final steps of mutual authentication.

  The primitive “capability Req” is transmitted from the OTA client to the radio resource RR on the base station controller BSC side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “capability Rsp” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client sending the message.
-OTA client capability: describes terminal reconfigurability options.

  The primitive “download description Req” is transmitted from the OTA client to the radio resource RR on the base station controller BSC side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
Download list: Contains one element selected by the OTA client for each download. The field includes the following fields.
Download block number: The number of radio blocks into which the basic software is divided before being sent to the OTA client.
-Billing criteria: A criterion for possible download billing.
-Installation criteria: Standards related to software installation.

  The primitive “download acceptance Cnf” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “download acceptance Rej” is transmitted from the radio resource RR on the base station controller mechanism BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “license Req” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “license Rsp” is transmitted by the OTA client to the radio resource RR on the base station controller BSC side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-Decryption key: a key used to decrypt the basic software.

  The primitive “license Cnf” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “license Rej” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “test description Req” is transmitted from the OTA server to the radio resource RR on the base station controller BSC side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
Test list: contains one element for each test to be run, which further includes the following fields:
Test vector: contains a description of the test.

  The primitive “install Cnf” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “installation Rej” is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.

  The primitive “data Req” is transmitted from the OTA server to the radio resource RR on the base station controller BSC side.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-One of the radio blocks into which the basic software is divided.

  The primitive “data Ind” is transmitted from the radio resource RR on the base station controller BSC side to the OTA server.

In the case of GSM / GPRS, the provided fields are at least one set of the following.
-OTA client ID: identifies the OTA client associated with the primitive.
-Ack radio block.

  4 and 5, procedural interaction between the OTA client and the OTA server shows the relative behavior according to the state of the OTA client or client context for each primitive received by each RR. It is described by.

  The behavior of the OTA client and OTA server is independent of the system.

  The primitives exchanged between the OTA client or OTA server and each RR is system dependent and refers to the GSM / GPRS system according to this example.

  In the following description, the timer start / stop operation is not described. The reason is that, as mentioned above, these are associated with the state of the entity.

  Referring now to FIG. 4, the behavior of the OTA client is described.

  In general, if the OTA client ID field does not match the identifier of the OTA client receiving the primitive, the primitive is ignored.

When the OTA client receives the primitive “Download Request Ind”,
-If it is in the "idle" state, the OTA client proceeds to "start download".
-If it is not in "Start Download" state, the primitive is ignored and the procedure is not continued.
-If the terminal can perform the download,
A random number RNUM is extracted and stored.
-A primitive "Download AckInd" is sent containing the value of the number RNUM extracted in the OTA Client Challenge Number field.
If the terminal is not able to perform the download, the primitive “Download NackInd” is sent and the OTA client returns to the “idle” state.

When the OTA client receives the primitive “Authentication Req”,
-If it is not in "Start Download" state, the primitive is ignored and the procedure is not continued.
-If the stored random number RNUM is not valid, the procedure is not continued.
-The OTA client proceeds to state "Mutual authentication".
The value of the stored random number RNUM is encrypted with the internal key CIK using a selected encryption algorithm, for example the AES algorithm.
If the previously encrypted value does not match the value in the OTA server response number field, the OTA client goes to the “idle” state and the procedure is not continued.
The value of the OTA server challenge number field is encrypted with an internal key CIK (client identification key) using a selected encryption algorithm, eg AES algorithm.
The primitive “Authentication Rsp” is sent with the previously encrypted value in the OTA Client Response Number field.

When the OTA client receives the primitive “Capability Req”,
-If it is not in "Mutual Authentication" state, the primitive is ignored and the procedure is not continued.
-The OTA client goes to the "capability request" state.
-A primitive "capability response" is sent.

When the OTA client receives the primitive “download description Req”,
-If it is not in the “capability request” state, the primitive is ignored and the procedure is not continued.
-The OTA client goes to "Download Accept" state.
-If the terminal can install the software,
-The primitive "Download Accept Cnf" is sent.
-If the terminal is not capable of installing software,
-The primitive "Download Accept Rej" is sent.
-The OTA client goes to the "idle" state.

When the OTA client receives the primitive “License Rsp”,
-If it is not in "Install" state, the primitive is ignored and the procedure is not continued.
-The downloaded software is decrypted using the key indicated in the decryption key field.
-If decryption is successful,
-The primitive "License Cnf" is transmitted.
-The downloaded basic software is saved.
-If decryption is not successful,
-The primitive "License Rej" is sent.
-The procedure proceeds to the "idle" state.

When the OTA client receives the primitive “test description Req”,
-If it is not in "Install" state, the primitive is ignored and the procedure is not continued.
-The OTA client goes to the "field test" state.
-The received test is executed against the previously stored basic software.
-If all tests are successful,
-The primitive "Install Cnf" is sent.
-New basic software is installed and started.
-If at least one test is unsuccessful,
-Install Rej primitive is sent.
-The downloaded basic software is deleted from the memory.
-The OTA client goes to the "idle" state.

  Referring again to FIG. 5, the OTA server response is now described.

  In general, the OTA client ID field is analyzed for each received primitive and considered to be the OTA client context for the identifier. If there is no OTA client context for the received identifier, the primitive is ignored.

When the OTA server receives the primitive “Download AckInd”,
-If the OTA client context is not in the "start download" state, the primitive is ignored and the procedure is not continued.
-The OTA client context goes to the "Mutual Authentication" state.
-Random numbers are extracted and stored.
The value of the OTA client challenge number field is encrypted with an internal key SIK (Server Identification Key) using a selected encryption algorithm, eg AES algorithm.
The primitive “Authentication Req” is sent to the OTA client with the encrypted value in the OTA server response number field in the previous step and with the extracted number value in the OTA server challenge number field.

If the OTA client context receives the primitive "Download NackInd"
-If the OTA client context is not in the "start download" state, the primitive is ignored and the procedure is not continued.
-The OTA client context goes to the "idle" state.

If the OTA client context receives the primitive “authentication Rsp”:
-If the OTA client context is not in the "Mutual Authentication" state, the primitive is ignored and the procedure is not continued.
The value of the stored random number is encrypted with the internal key SIK using the selected encryption algorithm, for example the AES algorithm.
If the previously encrypted value does not match the value in the OTA client response number field, the OTA client context goes to the “idle” state and is not continued.
-The OTA server goes to the "Capability Request" state.
-The primitive "Capability Req" is sent.

If the OTA client context receives the primitive “capability Rsp”:
-If the OTA client context is not in the "capability request" state, the primitive is ignored and the procedure is not continued.
If the capabilities included in the primitive are not compatible with the downloaded software, the OTA client context goes to the “idle” state.
If the capabilities contained in the primitive are compatible with the downloaded software, the OTA client context goes to the “Download Accept” state and the primitive “Download Description Req” is sent.

If the OTA client context receives the primitive “Download Accept Cnf”,
-If the OTA client context is not in "Download Accept" state, the primitive is ignored and the procedure is not continued.
-The OTA client context goes to the "software download" state.
-Software download is started.

If the OTA client context receives the primitive "Download Accept Rej"
-If the OTA client context is not in "Download Accept" state, the primitive is ignored and the procedure is not continued.
-The OTA client context goes to the "idle" state.

If the OTA client context receives the primitive “License Req”,
-If the OTA client context is not in "software download" state, the primitive is ignored and the procedure is not continued.
-The procedure proceeds to the "Install" state.
-The protocol primitive "License Rsp" is sent, including the decryption key.

If the OTA client context receives the primitive “License Cnf”:
-If the OTA client context is not in "install" state, the primitive is ignored and the procedure is not continued
-The primitive "Test description Req" is transmitted.

If the OTA client context receives the primitive “License Rej”:
-If the OTA client context is not in "install" state, the primitive is ignored and the procedure is not continued
-The OTA client context goes to the "idle" state.

If the OTA client context receives the primitive “Install Cnf”,
-If the OTA client context is not in "install" state, the primitive is ignored and the procedure is not continued
-The OTA client context goes to the "idle" state.

If the OTA client context receives the primitive "Install Rej"
-If the OTA client context is not in "install" state, the primitive is ignored and the procedure is not continued
-The OTA client context goes to the "idle" state.

  The operation of the window protocol in which data is transferred from the OTA server to the OTA client is described below.

  From the point of view of the OTA server, when software download is started, the basic software is encrypted with a known type of encryption algorithm, such as an encryption key and an AES algorithm, for example.

The encrypted basic software is divided into blocks having a limited size such as 1 to 2 kBytes. A bit mask BITMASK having a number of bits equal to the number of radio blocks into which the basic software is divided is assigned, and a value “0” is set to each bit. Each bit of the mask corresponds to a radio block and its number is equal to the bit position. That is, the first bit corresponds to the first radio block, the second bit corresponds to the second radio block, and so on. The first N radio blocks BLOCK constituting the basic software are transmitted. Timer T401 is started. If each message Ack is received, the following is performed.
-Timer T401 is restarted.
-For each value "1" present in the bitmap of the message Ack, the value of the mask BITMASK assigned to the corresponding position is set to "1".
-Considering untransmitted blocks first, at most the first N radio block blocks corresponding to the value "0" in the mask BITMASK are transmitted.
The download ends when all bits of the mask BITMASK are equal to “1”.

From the viewpoint of the OTA client, when software download is started, a bit mask BITMASK equal to the number of radio blocks into which the software is divided is assigned, and a value “0” is set for each bit. Each bit of the mask corresponds to a radio block and the number is equal to the bit position. That is, the first bit corresponds to the first radio block, the second bit corresponds to the second radio block, and so on. Next, the timer T400 is started. If each radio block BLOCK is received:
-Timer T400 is restarted.
-The bit of the mask BITMASK corresponding to the block number of the received radio block is set to "1".
-A message Ack is sent with a bitmap corresponding to the mask BITMASK.
The download ends when all bits of the mask BITMASK are equal to “1”.

In summary, according to the above example, the functional behavior of the OTA client and OTA server is as follows.
The download procedure is started, for example, when a protocol message “handover command” sent by the MSC (Mobile Switching Center) to the base station controller BSC is received.
-Mutual authentication between the OTA client and the OTA server occurs, for example, according to a "challenge response" scheme.
-The basic software to be downloaded is sent to a traffic channel, eg a GPR traffic channel.
-The basic software to be downloaded is divided into blocks of smaller size (eg 1 or 2 kilobytes) on the OTA server.
-Basic software transfers are managed by a simple window protocol, where the size window matches the number of blocks into which the basic software was divided.
The downloaded basic software can be encrypted, in which case a key is required for decryption and installation.
-Before starting the basic software, the OTA client verifies this, for example by an appropriate test proposed by the OTA server.

  Referring to FIG. 18, there is shown an applicable example of an inter-system handover procedure from GSM to UMTS for a circuit call as defined in the standard, in which the terminal MS can be reconfigured Software downloads and procedures are guided.

Referring to FIG. 19, the manner in which the software download procedure operates will be described while indicating the interaction between different entities existing in the network.
1. The OTA client context, and the OTA client context that exists on the OTA server and for the assumed OTA client, is in the “idle” state.
2. When the protocol message “handover command” is received from the mobile switching center (MSC), the OTA client context transitions from the “idle” state to the “download start” state, starts timer T101 and is requested In addition to indicating download, the primitive “download start Ind” is transmitted to the radio resource RR.
3. The radio resource RR receives the primitive “download start Ind”. The radio resource RR requests the radio resource management RRM for downlink resources necessary to enable software download.
a. When the resource is available, the radio resource RR transmits a protocol message “packet download request” to the radio resource RR of the terminal MS via the control channel FACCH (high-speed associated control channel), and the channel on which the terminal executes the download Indicates PDCH, relative reserved block period RRBP, and requested download.
b. If the resource is not available, the radio resource RR sends the primitive “Download NackInd” to the OTA client context.
4). The radio resource RR of the terminal MS receives the protocol message “packet download request”, sets the channel PDCH, and transmits the primitive “download request Ind”.
5. The OTA client receives the primitive “download request Ind”. If the terminal can be used to execute the download, the OTA client transitions from the “idle” state to the “start download” state, starts timer T100, sends the primitive “download AckInd”, and sends its own resource to radio resource RR. Specify an identifier. The radio resource RR stores the identifier of the OTA client locally.
6). The radio resource RR receives the primitive “download AckInd” and transmits a protocol message “packet message” to the radio resource RR of the base station controller BSC via the PACCH (packet-associated control channel) at the time specified by the relative reservation block period RRBP. “Download Ack” is transmitted to indicate the identifier of the OTA client.
7). The radio resource RR of the base station controller BSC receives the protocol message “packet download Ack”, sends the primitive “download AckInd” to the OTA client context, and specifies the identifier of the OTA client.
8). The OTA client context receives the primitive “Download AckInd”. The OTA client context stops timer T101 and transitions from the “download start” state to the “mutual authentication” state, while starting timer T201. The primitive “authentication Req” is transmitted to the radio resource RR.
9. The radio resource RR receives the primitive “authentication Req”, transmits the protocol message “packet authentication request” via the control channel PACCH to the radio resource RR of the terminal MS, and indicates the RRBP.
10. The radio resource RR of the terminal MS receives the protocol message “packet authentication request” and transmits the primitive “authentication Req” to the OTA client.
11. The OTA client receives the primitive “authentication Req”, stops timer T100, starts timer T200 and proceeds to the “mutual authentication” state. At this stage, authentication of the OTA server is executed.
a. If the OTA server is not authenticated, the OTA client stops timer T200 and returns to the “idle” state.
b. If the OTA server is authenticated, the OTA client sends the primitive “authentication Rsp” to the radio resource RR.
12 The radio resource RR receives the primitive “authentication Rsp”, and transmits the protocol message “packet authentication response” to the radio resource RR of the base station controller BSC via the PACCH at the time specified by the relative reservation block period RRBP. To do.
13. The radio resource RR of the base station controller BSC receives the protocol message “packet authentication response” and sends the primitive “authentication Rsp” to the OTA client context.
14 The OTA client context receives the primitive “authentication Rsp” and confirms the authentication of the OTA client.
a. If the OTA client is not authenticated, timer T201 is suspended and the OTA client context returns to the “idle” state.
b. If the OTA client is authenticated, timer T201 is interrupted and the OTA client context starts timer T301 and proceeds to the “capability request” state. The OTA client context sends the primitive “capability Req” to the radio resource RR.
15. The radio resource RR receives the primitive “capability Req” and transmits a protocol message “packet capability Req” in which RRBP is specified to the radio resource RR of the terminal MS via the control channel PACCH.
16. The radio resource RR of the terminal MS receives the protocol message “packet capability Req” and transmits the primitive “capability Req” to the OTA client.
17. The OTA client receives the primitive “capability rReq”, stops timer T200, starts timer T300, and proceeds to the “capability request” state. The OTA client sends the primitive “capability Rsp” to the radio resource RR. .
18. The radio resource RR receives the primitive “capability Rsp”, and transmits the protocol message “packet capability response” to the radio resource RR of the base station controller BSC via the PACCH at the time specified by the RRBP.
19. The radio resource RR of the base station controller BSC receives the protocol message “packet capability response” and sends the primitive “capability Rsp” to the OTA client context.
20. The OTA client context receives the primitive “capability Rsp” and verifies the terminal capability.
a. If the capability is not compatible with software download, timer T301 is interrupted and the OTA client context returns to the “idle” state.
b. If the capability is compatible with software download, timer T301 is interrupted and the OTA client context starts timer T302 and information about the download operation (number of radio blocks to download, billing, installation) Etc.) is transmitted to the radio resource RR, and the process proceeds to the “download acceptance” state.
21. The radio resource RR receives the primitive “download description Req” and transmits a protocol message “packet download description” in which RRBP is specified to the radio resource RR of the terminal MS via the control channel PACCH.
22. The radio resource RR of the terminal MS receives the protocol message “packet download description” and transmits the primitive “download description Req” to the OTA client.
23. The OTA client receives the primitive “download description Req”, stops the timer T300, and proceeds to the “download acceptance” state. The OTA client verifies the received information.
a. If the download is not accepted, the OTA client sends the primitive “Download Accept Rej” to the radio resource RR and returns to the “idle” state.
b. If the download is accepted, the OTA client starts timer T400 and sends the primitive “Download Accept Cnf” to the radio resource RR and proceeds to the “Software Download” state.
24. The radio resource RR receives the primitive “download acceptance Cnf”, and transmits the protocol message “packet download acceptance” to the radio resource RR of the base station controller BSC via the PACCH at the time point specified by the RRBP.
25. The radio resource RR of the base station controller BSC receives the protocol message “Packet Download Accept” and sends the primitive “Download Accept Cnf” to the OTA client context.
26. The OTA client context receives the primitive “Download Accept Cnf” and stops timer T302, the OTA client context starts timer T400 and proceeds to the “Software Download” state. The OTA client-context initiates the download and transmission of the various blocks of software to be downloaded by sending the primitive “Data Req” to the radio resource RR. The transfer of the radio block occurs by a conventional window protocol. The radio block is transmitted via the channel PDTCH (packet data transfer channel).
27. The OTA client receives each radio block through reception of the primitive “Data Ind” from the radio resource RR. In each receiving block, timer T400 is restarted. The OTA client transmits an acknowledgment signal Ack to the OTA client context by periodically transmitting the primitive “data Req” to the radio resource RR. The radio resource RR transmits Ack via the associated control channel PACCH. When the OTA client sends an Ack for the last radio block to be downloaded, it stops timer T400, starts timer T500 and proceeds to the “install” state. The primitive “License Req” is transmitted to the radio resource RR.
28. The OTA client context receives various messages Ack through reception of the primitive “data Ind” from the radio resource RR. Timer T401 is restarted at each received Ack. When the OTA client context receives an Ack for the last radio block, it stops timer T401, starts timer T501 and proceeds to the “install” state.
29. The radio resource RR receives the primitive “license Req” and sends a protocol message “packet license request” to the radio resource RR of the base station controller BSC via the associated control channel PACCH.
30. The radio resource RR of the base station controller BSC receives the protocol message “packet license request” and sends the primitive “license Req” to the OTA client context.
31. The OTA client context receives the primitive “license Req” and sends the primitive “license Rsp” indicating the key for performing software decryption to the radio resource RR.
32. The radio resource RR receives the primitive “license Rsp” and sends a protocol message “packet license response” to the radio resource RR of the terminal MS via the associated control channel PACCH.
33. The radio resource RR of the terminal MS receives the protocol message “packet license response” and sends the primitive “license Rsp” to the OTA client.
34. The OTA client receives the primitive “license Rsp” and decrypts the software using the received key.
a. If the decryption operation is successful, the OTA client sends the primitive “license Cnf” to the radio resource RR.
b. If the decryption operation is unsuccessful, the OTA client sends a primitive “license Rej” to the radio resource RR, stops the timer T500, and returns to the “idle” state.
35. The radio resource RR receives the primitive “license Cnf” and sends a protocol message “accept packet license” to the radio resource RR of the base station controller BSC via the associated control channel PACCH.
36. The radio resource RR of the base station controller BSC receives the protocol message “packet license acceptance” and sends the primitive “license Cnf” to the OTA client context.
37. The OTA client context receives the primitive “license Cnf” and sends a primitive “test description Req” indicating information about the test to be performed to the radio resource RR.
38. The radio resource RR receives the primitive “test description Req” and sends the protocol message “packet test description” to the radio resource RR of the terminal MS via the associated control channel PACCH.
39. The radio resource RR of the terminal MS receives the protocol message “packet test description” and transmits the primitive “test description Req” to the OTA client.
40. The OTA client receives the primitive “test description Req”, stops timer T500 and proceeds to the “field test” state. The OTA client performs tests on the downloaded software as directed by the OTA client context.
a. If the test is unsuccessful, the OTA client sends the primitive “Install Rej” to the radio resource RR and returns to the “idle” state.
b. If the test is successful, the OTA client sends the primitive “Install Cnf” to the radio resource RR, launches the new software and returns to the “idle” state.
41. The radio resource RR receives the primitive “install Cnf” and sends a protocol message “accept packet install” to the radio resource RR of the base station controller BSC via the associated control channel PACCH to Reconfigure the wireless interface.
42. The radio resource RR of the base station controller BSC receives the protocol message “Packet Install Accept”, sends the primitive “Install Cnf” to the OTA client context and initiates the procedure to release the resources defined in the standard When the procedure is completed, the handover procedure defined in the standard is continued.
43. The OTA client context receives the primitive “Install Cnf” and returns to the “idle” state.

  The procedure disclosed in FIG. 19 shows the basic software download / procedure.

  As will be appreciated by those skilled in the art, this procedure may be incorporated into a standard defined GSM to UMTS intersystem handover procedure for circuit calls.

  In particular, the embedded system receives a “handover command” message of the base station subsystem application part (BSSAP) protocol from the MSC and then the “handover command from system to UTRAN” message of the RR protocol to the MS. Can be performed in the RR layer during transmission.

  The present invention can be generalized to all possible intersystem handover procedures defined by current standards.

  For example, as will be appreciated by those skilled in the art, this procedure can be incorporated into an intersystem handover procedure from UMTS to GSM for circuit calls as defined in the standard. In particular, the embedded system receives the “Relocation Command” message of the Radio Access Network Application Part (RANAP) protocol from the MSC and then sends the “Hand from UTRAN” of the Radio Resource Control (RRC) protocol to the user equipment (UE). This can be done at the radio resource control (RRC) layer before sending the “over command” message.

  The present invention can also be generalized as inter-system handover procedures that have not yet been standardized, for example, inter-system handover procedures between International Mobile Communications 2000 (IMT 2000) and WLAN or IEEE 802.16 or IEEE 802.20 systems. .

  As will be apparent to those skilled in the art, the present invention allows the execution of basic software downloads without interruption of the call, especially in the case of voice calls, in the case of line-based calls. This is because, for example, by assigning one or more packet channels, for example PDTCH GPRS channels, in parallel with circuit-based channels used for line communication, for example TCH (traffic channel) GSM channels, GSM / GPRS Is possible in case.

  This feature allows to manage prioritization between voice, data and software downloads.

  Although the present invention has been disclosed by referring to the GSM / GPRS system by using the radio channel of the system described above, as will be appreciated by those skilled in the art, the present invention uses, for example, a “generic” channel. May be applied.

  An example of where a “generic” channel can be used is the use of a “generic” channel for downloading basic software from an OTA server to an OTA client, as described in the literature.

  In the case of inter-system handover, the procedure disclosed in FIG. 18, for example, is adopted according to the implementation method using the “generic” channel, and the procedure for downloading the basic software from the OTA server to the OTA client is changed to the above-mentioned “generic” channel. It is foreseeable to maintain an active connection over the radio channel of an active system, such as a GSM / GPRS system, for example, while simultaneously using the network.

  The “generic” channel can be used only for the whole or part of the basic software download procedure, for example the transmission of the basic software from the OTA server to the OTA client.

  If the “generic” channel is partially used, the rest of the basic software download procedure can be implemented using the active system radio channel.

  By adopting a “generic” channel, the radio resources associated with the active system are more efficiently loaded and made available to other users, making the basic software download procedure much faster It becomes possible. This is because the “generic” channel is dedicated to this type of operation.

  As a further embodiment of the present invention, as known to those skilled in the art, a cell reselection procedure between two systems, eg, from GSM / GPRS to UMTS, when the terminal is in an “idle” state, is performed. It is also possible to manage.

  As mentioned earlier, the terms used to name primitives and related fields are merely for instructional purposes, and the corresponding definitions are important as described.

This extension introduces the following primitives between the OTA client and the radio resource RR on the terminal MS side.
-Download start Req: This message is transmitted from the OTA client to the radio resource RR on the terminal MS side.

For GSM / GPRS, the fields provided for this primitive are at least:
OTA client ID: One of the following primitive sets between identifying the OTA client executing the request and between the OTA server and the radio resource RR on the base station controller BSC side.
Request download start Ind: This message is transmitted from the radio resource RR on the base station controller BSC side to the OTA client.

For GSM / GPRS, the fields provided for the primitive are at least one of the following:
OTA client ID: identifies the OTA client executing the request.

A context response regarding the terminal MS of the OTA client context when the primitive “request download start Ind” is received is shown below.
If the OTA client context is not in the “idle” state, the primitive is ignored and the procedure is not continued.
-The OTA client context proceeds to the "download start" state.
The primitive “Start Download Ind” indicates various possible downloads and is sent to the OTA client.

Referring to FIG. 19, the operation of the basic software download procedure in the case of cell reselection is shown, pointing out the interaction between different entities present in the network. Since the rest of the procedure itself is the same as the description of FIG. 18, the operation of the first phase of the procedure will be described in detail below.
I. The OTA client context for the OTA client and the OTA client under consideration is in the “idle” state.
II. If the cell reselection command arrived from the physical layer is received, the OTA client proceeds from the “idle” state to the “download start” state, starts a timer T100, and designates a primitive “download start Req” specifying its own identifier. Is transmitted to the radio resource RR. The radio resource RR stores the identifier of the OTA client locally.
III. The radio resource RR receives the primitive “download start Req”. The radio resource RR sends a protocol message “packet channel request” defined by the standard via the packet random access channel PRACH to specify the basic software download request by the user and the identifier of the OTA channel. . If the GPRS configuration installed by the operator does not provide a master channel configured by the packet / broadcast control channel PBCCH and the packet common control channel PCCCH, the above procedure will replace the first two messages of the procedure itself with the above described message. It continues to be effective by mapping to the GSM random access channel RACH and access grant channel AGCH rather than the packet random access channel PRACH and packet access grant channel PAGCH.
IV. The radio resource RR of the base station controller BSC receives the protocol message “packet channel request”. Since this is regarded as a software download request, a primitive “request / download start Ind” specifying the identifier of the OTA client read by the received message is transmitted to the OTA client context.
V. The OTA server receives and verifies the primitive “request / download start Ind”, and the OTA client context regarding the OTA client indicated in the state behaves as follows.
a. If the state is “idle”, the OTA client context goes to the “download start” state and starts timer T101 to indicate the requested download and sends the primitive “download start ind” to the radio resource RR. .
b. If the state is not “idle”, the message is ignored.
VI. The radio resource RR receives the primitive “download start Ind”. The radio resource RR requests the radio resource management RRM for downlink resources necessary to enable downloading of the software.
a. If the resource is available, the radio resource RR sends the protocol message “packet download request” to the radio resource RR of the terminal MS via the control channel PAGCH, and the channel PDCH, RRBP, And indicates the requested download.
b. If the resource is not available, the radio resource RR sends the primitive “Download NackInd” to the OTA client context.
VII. The radio resource RR of the terminal MS receives the protocol message “packet download request”, sets the channel PDCH, and transmits the primitive “download request Ind”.
VIII. The OTA client receives the primitive “download request Ind”. If the terminal can execute the download, the OTA client transmits a primitive “download AckInd” that specifies its own identifier. The radio resource RR stores the identifier of the OTA client locally.

  This procedure is continued by executing the sixth and subsequent steps of the procedure described with respect to FIG.

  The architecture and method described in accordance with the present invention has been disclosed with reference to the access network of a GSM / GPRS system.

  The present invention can also be applied to UMTS, UTRAN (UMTS Terrestrial Radio Access Network) or any other access network, for example, an access network such as WLAN, IEEE 802.16, IEEE 802.20.

  For example, in the case of UTRAN, the present invention can be implemented by incorporating an OTA client and OTA server and associated procedures, primitives and protocol messages into the RRC layer of the UMTS system.

  The present invention has been disclosed using an access network and a corresponding protocol layer on both the network side and the terminal side. The present invention can also be implemented using a core network and corresponding protocol layers on both the network side and the terminal side. In this case, considering for example packet switch core networks of GSM / GPRS and UMTS systems, the present invention provides OTA clients and OTA servers and related procedures, primitives and protocol messages to the core network terminals and services. It can be implemented by incorporating into the GPRS mobility management (GMM) layer of each GPRS support node (SGSN) node.

  More specifically, in the case of GSM / GPRS, the GPRS mobility management (GMM) layer is modified by introducing new protocol messages and exchanging related fields between the OTA server and the OTA client. The same scheme can also be applied to UMTS systems.

  The present invention has been disclosed by considering the download and activation of a piece of basic software during the execution of an intersystem handover procedure.

  As will be apparent to those skilled in the art, the basic software may be downloaded and stored in the terminal rather than being installed and immediately operated.

  According to this further embodiment, it is possible to install and continue to execute the basic software if requested by the network or user. If the radio terminal UE / MS has sufficient memory and processing capability, the downloaded basic software can be stored and installed in parallel with the existing system currently in operation.

  This option is useful for enabling multi-mode operation of the terminal UE / MS. That is, this option allows the terminal to switch from one operating mode to another without having to download basic software.

In summary, the present invention provides at least the following advantages.
-Since no nodes or physical interfaces are added to the existing ones, the impact on the protocols and nodes present in the second and third generation networks is minimized.
-The procedural signaling phase uses the same signaling channel as defined in the standard, while the data channel is allocated only for the software download procedure application, thus minimizing radio resource occupancy.
-Since the present invention utilizes existing second and third generation networks, there is no need to wait for future release of IP-based UMTS as mentioned in the prior art.

  Especially when using the access network and the corresponding protocol layer on both the network side and the terminal side, the RR (Radio Resource) protocol is integrated with some changes that allow the terminal to download new basic software. The network has full control over the software download procedure and associated radio resources, so that, for example, GSM / GPRS, IS95, PDC (Digital Cellular Telephone), or for example the first belonging to the family IMT2000 A second generation cellular method such as a three generation cellular method can be implemented.

1 is a diagram illustrating a multi-mode terminal according to the prior art. FIG. FIG. 2 illustrates a network architecture of a GSM / GPR system according to an embodiment of the present invention. It is a figure showing the terminal which can reset the architecture of FIG. It is a state transition diagram of the protocol steps executed by the client on the wireless terminal side. Is a state transition diagram of the protocol steps executed by the server on the base station controller side; It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the structure of the protocol message exchanged between a server and a client. It is a figure which shows the intersystem handover procedure from GSM to UMTS for a circuit call. It is a figure which shows the detail of the download procedure of the software which resets a radio | wireless terminal. It is a figure which shows the download procedure of the basic software in the case of cell reselection.

Claims (28)

A communication network that operates according to a first communication system and a second communication system different from the first communication system, the communication network comprising:
A wireless terminal, the wireless terminal being
A client entity that uses a radio resource protocol layer of the radio terminal, wherein the radio resource protocol layer of the radio terminal is related to the first communication system, the radio terminal via a radio terrestrial connection; In the wireless terrestrial connection, a communication system related to the radio resource / protocol layer of the radio terminal is used, and by changing the radio resource / protocol layer of the radio terminal, The wireless terminal capable of resetting a communication system used in the wireless terrestrial connection;
A node, the node
A server entity that uses the radio resource protocol layer of the node;
A software the wireless terminal adapted to reconfigure the communication system for use in the wireless terrestrial connection, when the software is installed in the wireless terminal, the radio resource protocol layer of the wireless terminal the first And the software to be changed to a radio resource protocol layer related to the communication system of 2, wherein the radio resource protocol layer of the node is related to the first communication system, Exchanging information in the communication network via a connection, and in the wireless terrestrial connection, a communication system related to the radio resource protocol layer of the node is used, and the node,
The radio resource protocol layer related to the first communication system is:
A first message for managing a wireless terrestrial connection using the first communication system;
Download the software from the node to the wireless terminal so that the wireless terminal is reconfigured to exchange information within the communication network via a wireless terrestrial connection using the second communication system Including additional messages to manage the series of terrestrial download processes to be installed,
The client entity and the server entity exchange the additional message via a wireless terrestrial connection using the first communication system and perform the series of terrestrial download processes.
Communication network. Including radio access network and core network,
The network of claim 1, wherein the radio resource protocol layer is a protocol layer of the core network. Including radio access network and core network,
The network of claim 1, wherein the radio resource protocol layer is a protocol layer of the radio access network. The radio access network includes a radio controller;
The network of claim 3, wherein the radio resource protocol layer is a protocol layer of the radio controller.   The network of claim 2, wherein the radio access network operates according to a second generation network.   The network of claim 2, wherein the radio access network operates according to a third generation network.   The network of claim 1, wherein the wireless terrestrial connection is established over a universal channel of the communication network.   The network of claim 1, wherein the wireless terrestrial connection is established over a wireless channel of the communication network.   2. The software of claim 1, wherein the software includes at least one module and the communication system is configured to manage priorities between voice calls, data transmissions, and downloading of the at least one module. Network.   The software includes at least one module, and the client entity and the server entity comprise a terrestrial software module, the terrestrial software module comprising the at least one module during a voice call. The network of claim 1 configured to download.   The network according to claim 1, wherein the software is suitable for at least partially reconfiguring the wireless terminal by the second communication system.   The network of claim 11, wherein the wireless terminal includes a layer of a protocol stack for performing at least a capability measurement for the second communication system. A method of resetting a wireless terminal belonging to a certain communication network, wherein a node belongs to the communication network, and the communication network includes a first communication system and a second communication different from the first communication system. Works according to the system,
The wireless terminal is
A client entity that uses a radio resource protocol layer of the radio terminal, wherein the radio resource protocol layer of the radio terminal is related to the first communication system, the radio terminal via a radio terrestrial connection; In the wireless terrestrial connection, a communication system related to the radio resource / protocol layer of the radio terminal is used, and by changing the radio resource / protocol layer of the radio terminal, The communication system used in the wireless terrestrial connection can be reset,
The node is
A server entity that uses the radio resource protocol layer of the node;
Software adapted to reconfigure the communication system used by the wireless terminal, and when the software is installed in the wireless terminal, the wireless resource protocol layer of the wireless terminal relates to the second communication system And the software is changed to a radio resource protocol layer, wherein the radio resource protocol layer of the node is related to the first communication system, and the node is connected to the node via a radio terrestrial connection. Information is exchanged in a communication network, and the wireless terrestrial connection uses a communication system related to the radio resource protocol layer of the node,
The radio resource protocol layer related to the first communication system is:
A first message for managing a wireless terrestrial connection using the first communication system;
An additional message for managing a series of terrestrial download processes for downloading and installing the software from the node to the wireless terminal;
The method
The client entity and the server entity exchanging the additional message via a wireless terrestrial connection using the first communication system;
The step of exchanging the additional message performs the series of terrestrial download processes via a wireless terrestrial connection using the first communication system, and the wireless terminal uses the second communication system. Allowing information to be exchanged within the communication network via a wireless terrestrial connection,
Method. The step of exchanging the additional message comprises:
A first field that identifies the type of message;
A second field identifying the wireless terminal indicated by the message;
The method of claim 13, comprising exchanging messages each including a third field containing data information. The step of exchanging the additional message comprises:
a) executing a download request for the software;
b) mutually authenticating the client entity and the server entity;
c) checking the ability of the wireless terminal to accept the software downloadable from the server entity;
d) providing information on download options;
e) dividing the software into blocks;
f) transmitting the block from the server entity to the wireless terminal;
g) reconstructing the software from the block and testing the reconstructed software;
h) installing the software on the wireless terminal;
15. The method of claim 14, comprising at least one of: The step of exchanging the additional message comprises:
The method of claim 15, comprising monitoring a structure of the block downloaded to the wireless terminal. The step of exchanging the additional message comprises:
16. Managing a set of timers (T100, T200, T300, T400, T500, T101, T201, T301, T302, T401, T501) that limit the time allowed to perform the series of processes. The method described in 1. The step of exchanging the additional message comprises:
And at least a pair of timers, a first timer that monitors processing executed by the wireless terminal and a second timer that monitors processing executed by the server entity, each of the timers being a certain process 16. The method of claim 15, comprising assigning the at least a pair of timers that are started when the process is started and stopped when the certain process is completed.   The method of claim 15, wherein the mutual authentication step is based on a “challenge response” scheme.   The step of dividing the software into blocks includes the step of dividing the block into blocks having a size of 1 to 2 kBytes, and the step of transmitting the block manages a window protocol, and the block into which the software is divided 16. The method of claim 15, comprising the step of matching the window size to the size of.   The method of claim 15, wherein a license is requested prior to installing the software on the wireless terminal.   The method of claim 13, wherein the software is encrypted with a key before being downloaded to the wireless terminal.   The method of claim 13, further comprising storing at least two sets of software in the wireless terminal adapted to reconfigure a communication system used by the wireless terminal. The step of downloading the software comprises:
Additional software adapted to reconfigure a communication system used by the wireless terminal, and when the additional software is installed in the wireless terminal, the wireless resource protocol layer of the wireless terminal 14. The method of claim 13, comprising downloading the additional software that is changed to a radio resource protocol layer associated with a system.   25. A wireless terminal comprising a client entity that performs the steps of the method according to any of claims 13-24.   A node comprising a server entity performing the steps of the method according to any of claims 13-24.   A computer program that can be loaded into a memory of a computer and causes the computer to function as the wireless terminal according to any one of claims 13 to 24.   A computer program that can be loaded into a memory of a computer and causes the computer to function as the node according to any one of claims 13 to 24.