Algorithms of Mobile Network Development Using Software-Defined Radio Technology

Today there are many standards, mixed wireless networks and mobile devices with many standards. The operators develop heterogeneous wireless networks to provide access to many services. The mobile devices with many standards use several active applications simultaneously to work with the different networks or the network recourses. Functioning of such mobile devices requires coordination and control of the capacity efficient using of the radio resource and the radio access networks.


Introduction
According to the World Forum for Research in Wireless Communications (Wireless World Research Forum, WWRF) it is expected that in 2015 the volume of traffic around the world will be 23 exabytes 1 . The existing division of the radio spectrum has serious limitations for this growth.
Today there are many standards, mixed wireless networks and mobile devices with many standards. The operators develop heterogeneous wireless networks to provide access to many services. The mobile devices with many standards use several active applications simultaneously to work with the different networks or the network recourses. Functioning of such mobile devices requires coordination and control of the capacity efficient using of the radio resource and the radio access networks.
The rapid development of means and wireless communication systems is ahead the processes of standardization and leads to the problems of interaction and compatibility. So, there are the problems: 1) significant growth of mobile traffic in the conditions of limited range; 2) lack of coordination and control of the capacity efficient using of the radio resource and the radio access networks; 3) actual lack of common standards for radio systems with the possibility of reconfiguration. According these problems it is needed to find solutions in this area. The decision of all this problems can be find by using software-defined radio (SDR) technology which requires the development of special algorithms for software updating and adapting. In this paper the algorithms of mobile network development using software-defined radio technology are proposed.

Algorithms for SDR BS software modification
Currently, SDR is widely used in cellular communications, where real-time support of the different changing radio protocols is required. In receive mode SDR can provide higher efficiency than "traditional" techniques. In digital signal processing their filtering is more closed to the ideal. In addition, by using software algorithms can be implemented functions, which are very difficult to get in analog processing.

Mobile cellular network based on SDR
Software-defined radio is a radio communication system which used software for modulation and demodulation operations of the radio signals. SDR change the priorities, and the processing unit becomes the core of radio system. When using the SDR almost all operations for the signal processing are shifted on software that runs on hardware of the mobile or cellular base station. So, the operation control of some specific specialized microprocessor is designed for this signal processing. The aim of this approach is to develop the flexible and adaptive system. Such kind of the system can send and receive all radio signals using SDR.
The ideal implementation of SDR-receiver is the antenna connection directly to an analogdigital converter (ADC) which is connected to a powerful processor unit. In this case, the software running on processor unit provides processing of the incoming data stream and converts them into the desired format. The ideal SDR-transmitter would operate similarly. The software would form a data stream that would be transferred to a digital-analog converter (DAC) connected to the antenna.
Most of the radio equipment used in the networks is based on the hardware or hardware and software modules that allow upgrading it only under a single standard. For example, most GSM base stations, which are operated at present, can only be upgraded under the GSM standard, but the transition to other technologies require the hardware replacement. With the spread of the radio multiple standards -2G/3G/4G and various technologies -GERAN, UTRAN, WIMAX and LTE becomes necessary cost savings and efficient using of the base stations in a longer life cycle, evolving to the new standards, speed, quality of service and environmental improvements. These problems force operators to look for the new solutions to reduce the unit capital and operating costs, to develop the networks quickly and efficiently.
In multi-channel and RF systems, the hardware defined radio (Fig.1) implementations require a significant amount of analog signal processing for every channel, leading to larger board size, increased analog design complexity, limited flexibility, and RF interference susceptibility. With the Software Defined Radio (SDR) approach (Fig. 2) The flexibility possible with software-defined radios (SDRs) is the key to the future of the wireless communication systems. Wireless devices relied on highly customized, applicationspecific hardware with little emphasis on future-proofing or adaptation to new standards. This design approach generally yielded power-and performance-optimized solutions at the expense of flexibility and interoperability.
Wireless device developers, as well as service providers and end users, can upgrade or reconfigure SDRs continually as new versions of the wireless standards are released. Furthermore, SDR devices can adapt continually to changes in the spectral or network environment, including modulation schemes, channel coding, and bandwidth. They can use be used to establish and maintain ad hoc networks 3 .
Technology Software Defined Radio (SDR), which are started to be used by advanced base stations equipment vendors for radio access network (RAN), becomes more relevant and an effective solution to these problems. New radio systems are known by various marketing names: Single RAN, Uni-BTS, Multi-RAN and Multi-standard Radio. But they all mean essentially the same thing -a relatively simple mechanism of modernization, which allows one base station to support simultaneously several different radio technologies.
Despite the marketing statements of new equipment RAN developers concerning its capabilities and, in particular, on the application in its SDR and the advantages that gives them using a technology offered by the base stations new platform vendors, there is no possibility for the operators to develop advanced multiprotocol and multifrequency 6 networks based on them. Obviously, though the operator can use the same base station equipment, reprogramming it to support other standards, it's still need to add additional radio-frequency devices and antenna-feeder cells or replace them with universal multistandard systems. Also, not so much technology used in base stations is limited to such a transition, but the existing infrastructure with its system of frequencies using regulation, the lack of standards and wide spreading of the terminal equipment capable of supporting these multifunctionality don't allow it to do at this stage.
But a phased transition is still possible, and the mobile operators already can choose available software-modifiable equipment for the evolution of their networks.

Development of an optimal architecture for network upgrade
Possible way for the development of mobile networks may be in the next direction of radio access networks modernization with using the transition to LTE technology (Fig.3).

Fig. 3. Possible direction for network modernization
LTE technology for the service providers (operators) reduces the network cost of owning and operating allowing them to have some of the core network (MME, SGW, PDN Gw), but RAN divide for sharing. This can be achieved by flexible program mechanism allowing each base station to be connected to multiple CN nodes of the different operators. When the mobile terminal included in the operator's network, it connects to the corresponding node CN, based on the service provider identifier sent from the mobile terminal. RAN sharing as a concept was proposed by Orange and T-Mobile in the UK, and could become a model for many operators in their migration to 4G [5].The operators have already invested large amounts in obtaining licenses for 3G frequency spectrum and 4G, and to realize the return on these investments in the future they will have to follow the model of sharing the radio access network, providing operators the necessary requirements of the network. In this case the transition occurs from a fully separate networks (separate: sites, the network planning, base stations and spectrum) to the most optimal variant of the full radio access network sharing, spectrum, and overall planning. And in this case, for base stations the SDR technology is very easy to allow the gradual such functioning equipment upgrading by program way without significant additional investment in equipment.
LTE technology will allow for the higher frequency bands to create sufficient capacity for the transmission of multimedia traffic, and the lower -to ensure wide coverage, albeit with some damage to the bandwidth. LTE is able to work in a large number of frequency bands. When bandwidth is 1.4 MHz, LTE allows three times more efficient to utilize frequency resources than the cellular networks of second generation. Efficiency is determined by the number of bits that can be sent at 1 KHz allocated frequencies.
With the appearance of LTE technology, the scale of using SDR technology is expanded and it's possible to say that main suppliers are increasingly inclined to use it as a new platform to their radio sites and support its key importance in the conditions of standardized solutions. Standardization in the reconfiguration of mobile networks plays today the most important role, as new projects require a sufficient large investment from operators and developers of equipment and for this investment must be no assurance that equipment from different vendors to be integrated into existing networks and will work in a multivendor environment.  (IEEE 802.18, 802.19, 802.21, 802.22, WAPECS, 1900) groups are developed in the various research organizations, which aim to create recommendations for improving spectrum management processes. Due to their implementation it's expected to obtain an additional gain in spectral efficiency and, consequently, in a radio service quality. In Europe, standardization in this area recently was engaged ETSI, which defined the concept of reconfigurable radio systems. This concept is based on technologies such as Software Defined Radio (SDR) and Cognitive Radio (CR), whose systems use radio and reconfigurable networks capabilities for self-adapt to the dynamically changing environment.

Basic requirements for base stations with the possibility of reconfiguration
The ability of reconfiguration is needed for: modulation and bandwidth, frequency allocation, including existing and upcoming bands, power levels, duplex mode, capabilities of the network architecture modification and other functions.
Basic requirements for base stations with the possibility of reconfiguration are given in

The network architecture for a base station with the possibility of reconfiguration and requirements for its functional blocks
Based on specified requirements, the simplest mobile SDR-network can be as follows - Fig.4.
Taking into account defined in paragraph 2.2.1 requirements, RBS optimal architecture can be offered (Fig. 5).
www.intechopen.com  Transaction return; Rapid response in case of breakage or failure in the RBS (e.g., reorganization in damaged equipment).
The RBS functional unit Requirements to block / function

Software Control Unit
The software download procedure execution Has to know what software is installed in every block; Has to know the potential interaction of software modules; The opportunity to activate / deactivate the software in RBS; RBS software process as an integral unit or as an independent application Flexibility of using different approaches to software management

O&M (technical service) Unit
Access to all important parameters of RBS configuration; Activation / deactivation of measurement control; Collecting and summarizing the results of measurements (collection and the summation scheme should be flexible and); Clients should be able to sign for delivery of measurements and /or configuration parameters results (delivery scheme should be flexible and reconfiguration ); Servicing of internal and external clients; RBS defense from too many requests.

Transmission Control Unit
Servicing of internal and external clients; Having the following physical layer configuration: gigabit Ethernet, copper, optical, SDH, μwave, (multiple connections with a link to the supported standards); Having the following logic level configuration: TCP / IP, SDH-Frame, S1/X2 Association (referring to the supported standards); Supporting the internal configuration of the standard algorithms to RRM (Radio Resource Management) algorithms for autonomous fine-tuning.

Spectrum Management Unit
Supporting the separation of the spectrum bands and rules for their using; Planning / control of spectrum using in a supported cells (if enabled): algorithms, the period of appointment, thresholds, interference between the cells;; Supporting functions of cognitive radio.

Capacity Control Unit
Providing maximum transmitter power, a change of power in accordance with the RAT specifications for the cells, antennas, etc.; Providing specific power schemes management (in the daytime, at night, depending on events, saving power, etc.); Providing the effectiveness measuring to coordinate with RAT specifications The functional unit RBS Requirements to block / function

Radio Resource Control Unit
Supporting the choice of terminal equipment access based on: The required quality of service (bandwidth, maximum delay, real time / unreal time); Radio conditions; User preference; Network policies; Information about a neighbor cell; Cell location (latitude / longitude), its radius and capacity; Cell capabilities (supporting services to the real / unreal time); Dynamic data such as current cell load.

Antenna Control Unit
Providing radiation pattern of antennas, the antenna directed action coefficient, antenna direction; Sector configuration providing (3х1, 1х1, etc.); Supporting of different physical types of antennas (Multі-pad, MІMO, SІMO); Using of heterogeneity receivers / transmitters, according to the separate antenna cable structure; Providing mechanical rotation / tilt, electrical rotation, modified rotation / tilt, azimuth direction. Based on the proposed network architecture for the effective network operation it is necessary to realize the method of SDR network reconfiguration.

The method of radio access network reconfiguration
The method of the base station reconfiguration uses graph of the base station software states, flowchart of the base station software upgrading sequence, the scheme of the software modification and block diagram of the control objects in the base station with the possibility of reconfiguration.

System description
To consider the software as a set of simultaneously operating and interacting programs in all hardware and software modules of the basic station, this provides general functional operation for all applications and supporting programs. This software includes basic functional blocks: the functions of maintenance and hardware and software modules control, functions in SDR signal processors (execution programs of generation radio interface, antenna beam control, etc.). Let's consider the program blocks and functional elements to be the subject of reconfiguration for SDR-technology.

Functional elements with combined program blocks
Combined software units managing of the functional elements are run as well in a main processor of a functional module as in processors of devices (e.g., SDR signal processors). The program management object can be configured to perform at one or more functional elements, and presented as several program blocks in the same loaded unit of the functional module. How the program can be structured is shown in Fig.6. The program unit associated with the management object -functional element in a functional module, has the same attributes as the functional element and is included in the same restart group. For example, if a functional element is restarted, then all software units belonging to this functional element are restarted too. Other blocks will not be affected.

Functional elements with connected program blocks
In this case software blocks are run in the functional element directly, as it is shown in fig. 7. Software blocks are configured with indicating, how software blocks are distributed and which functional element they are run on. The attributes that are linked with the name of the block in the software management object cannot be used to connect the software block to management objects -functional elements. The attribute of the restart group is not being used at this time. If a functional module is restarted, then all program blocks in this module are restarted. Fig. 7. The management object structure of the functional module with connected program blocks

State phases of the BS software
The graph of the BS software states is shown on the fig. 8.
If one considers the base station software as a single management object or as one application, then it is possible to define the main phases of its operation, a transition to which is executed at the certain events that occur during operation of the base station (increasing the number of software failures, necessary to perform action on a particular schedule, etc.), and in case of the commands, written in Man-Machine Language (MML). These commands come from the outside. They are: In this phase the base station is in the standby mode and the software isn't loaded into processor RAM of the functional modules and O&M. The external power is connected to the base station, but the internal power supply off. Thus, all functional modules and functional elements of the BS are inactive except for independent software module of BS power management. This module should provide an opportunity to remote turn on and off the internal power sources for BS by sending MML command from OSS or from the control element(O&M terminal). Switching to the Phase 0 is executed from the Phase 7 by remote external MML command or emergency in the case of forced power interruption from any phase. Passing from Phase 0 to Phase 1 is executed at the event of its successful completion.
-Phase 1 "Start" In this phase the synchronized and consistent (in a strictly fixed order) turning on the internal power supply of the BS hardware modules and activation of the boot modules , the management interface of BS internal resources are carried out. In fact, the boot modules have to be located in processors ROM of the BS modules, and boot programs have be activated immediately after power-on to the processor modules.
Also, switching to Phase 1 is executed from phase 6 in the case of unsuccessful testing of functional modules after software initialization or from the phase 7 by remote external MML command. Passing from Phase 1 to Phase 2 is executed at its successful completion event. www.intechopen.com Algorithms of Mobile Network Development Using Software-Defined Radio Technology 15 -Phase 2 "Downloading software from flash" In this phase the parallel software download from the flash memory modules into the RAM of the BS main O&M module and all regional processors that provide the work of functional modules and the BS functional elements. Also, passing to Phase 2 is executed from phase 5 in the case of unsuccessful software initialization or from the phase 7 by remote external MML command. Passing from Phase 2 to Phase 3 is executed by its successful completion event.
-Phase 3 "Downloading configuration from flash" In this phase the parallel download of the BS configuration files from the flash memory modules into the RAM of the main O&M BS module and all regional processors to provide of the functional modules and functional BS elements is executed. Passing to Phase 3 is executed also from phase 7 by remote external MML command. Passing from Phase 3 to Phase 4 is executed by its successful completion event.
-Phase 4 "Running software" In this phase it is executed the synchronous and consistent running (in a strictly fixed order) of the downloaded software modules in the main O&M processor and later in regional processor functional modules, under the management of O & M module. Passing to Phase 4 is executed also from phase 7 by remote external MML command. Passing from Phase 4 to Phase 5 is executed at its successful completion event.
-Phase 5 "Initialization" In this phase it is executed synchronous and consistent initialization of all program modules and blocks with the initial set of these blocks variables, and configuration of software complex for programs support, defined by configuration files, and the actual bringing of all working modules to an active state, ready for testing BS applications. Passing to Phase 5 is also executed from Phase 7 and Phase 8 by remote external MML commands. Passing from Phase 5 to Phase 6 is executed by its successful completion event, in case of unsuccessful completion of Phase 5,passing to Phase 2 is executed for restarting software in some or all BS modules.
-Phase 6 "Testing" In this phase it's executed parallel independent testing of all the hardware and software modules correct functioning according to the performance algorithm. Then testing is executed of the all modules collaboration within the application, specified by configuration data. Passing to Phase 6 is executed also from phase 7 by remote external MML command. Passing from Phase 6 to Phase 7 is executed by the its successful completion event, in the case of unsuccessful completion of Phase 6, passing is executed to Phase 1 for the initial start, or if necessary -repair execution.

-Phase 7 "Functioning"
This is the main phase, in which the functioning of the base station is executed. It provides execution of all applications, defined by the BS configuration data and its resources control, configuration and providing of its interaction with other elements of the mobile network: Radio Network Controller (RNC), Base Station Controller (BSC), Operational Support Systems (OSS), etc. Switching to Phase 7 is also executed from Phase 8 and Phase 9 after their completion. Passing from Phase 7 to Phase 8 is executed by external MML command when software upgrade is requested. Passing from Phase 7 to Phase 9 is executed by the external MML command when software backup is requested. Passing from Phase 7 to Phase 6 is executed by external MML command when regular or compulsory testing is requested. Passing from Phase 7 to Phase 5 is executed by external MML command for restarting the software modules. Passing from Phase 7 to Phase 4 is executed by external MML command or in the case of detecting software failure. Passing from Phase 7 to Phase 3 is executed by external MML command, or in the case of detection configuration data failure to reload configuration files from flash memory. Passing from Phase 7 to Phase 2 is executed by external MML command, or in the case of detection of non-revolving by means of restarting crashing software for reloading of the software module from flash memory. Passing from Phase 7 to Phase 0 is executed by external MML command to switch off internal power supply BS. Return from Phase 8 to Phase 7 is executed by external MML commands at the completion of software correction or update. Passing from Phase 8 to Phase 5 is executed by external MML commands when the software upgrade function is completed.
-Phase 9 "Software backup" In this phase it is executed backup of all software modules, memory modules, data blocks and links of the program modules and blocks from the main O&M module, the functional blocks and functional elements in structured DUMP, that includes 3 files: programs, data and references, which are stored in the flash memory of O&M main module. Return from Phase 9 to Phase 7 is executed after completion of backup Phase. Fig.9 presents general diagram of the operation sequence of the base station with the ability to modify the software. It describes the basic steps which must be completed in the states phases on the BS management objects level, according to diagram in the Fig.6.

The general scheme of the operation sequence of the base station with the ability to modify software
In the off state in the standby mode BS receives a command to power up independently from the site or remotely with OSS or O&M terminal. Standalone the BS power management software module generates signals internal power supply on of the BS modules in software defined sequence. After time-out power on at all functional modules, their power on are controlled.
In case of hardware inactivity of any of the modules, BS indicates "accident of powering" on the power supplies on the scoreboard display and informs about the accident through the O&M interface (in OSS or control element).
On successful completion of powering on in all functional modules boot software modules are activated. They are located in the processor ROM of the each module.
Loading modules activate the internal interface of local resources management, total control of which is done by the main O&M module. O&M module makes a request to the software download in the processor RAM of the modules from local flash memory devices, guided by these processors.
After the timeout software downloads into all functional modules, the load control is executed using responses which confirm loading of these modules.
If not all modules verified the software downloading from the local device flash memory, O&M module activates the emergency software module download from the active backup, located in the flash memory of O&M module.
Later on a load test of software is done and if unsuccessful downloading some of the modules, BS indicates "accident of the software downloading" on the scoreboard display and informs about the accident through the O&M interface (in OSS or control element).
On successful completion of software loading into all modules, O&M module initiates the loading of the configuration settings from a BS configuration file in all custom function modules, functional elements (blocks of software).After a timeout boot parameters in blocks of software the loading and configuration are controlled by responding units of software downloads.
If not all blocks verified download of the configuration parameters the BS indicates "accident of configuration" on the scoreboard display and informs about the accident through the O&M interface (in OSS or control element).On successful completion of parameters loading in the software blocks and BS configuration BS the initial start (or restart) of all modules and software blocks is executed with the main O&M module in all functional modules. They in its turn initiate the restart of software units in functional elements.
After the waiting times of restart in all functional modules complete the monitoring the restart completion is executed from all software blocks.
In case, if not all software blocks confirmed restart complete, it is executed the cycle restarts test. If reset phase was performed twice or more times in a short time interval and if the restart was cyclic, then the BS indicates "accident of cyclic restart" on the scoreboard display and informs about the accident through the O&M interface (in OSS or control element).
If the restart was not cyclical, the attempt is made to restart the software of restart module correctly with an active backup. If restart of the all software modules and blocks was successful it is executed the initializing of the all applications, followed-up -applications modules start, of all modules and applications functioning, the synchronization of signaling protocols, further tuning antenna system by successive queries from basic O M module. After a timeout the BS and all applications readiness are controlled confirmation of readiness. If the BS is not ready, the message "Accident of Start applications" indicates on the scoreboard display through O&M interface (in OSS or control element) and the attempt is made to restart the software modules with an active backup.
When BS is ready full operational command interface is run what allows to continue working with BC as a complete part of the network through signaling protocols and O&M interface, to interact with other network elements: RNC, BSC, Mobility Management Entity (MME) and the control system (OSS) Then BS is functioning into test functionality mode.
After testing timeout BS executes control of the testing end completion. If the test result is unsuccessful, then "accident Test BS" is indicated on the scoreboard display through O&M interface (or in OSS) and attempt to re-start is made. On successful completion of testing, the BS goes into full operation mode. Operational command interface further allows executing the BS management via O&M interface with the control system (OSS, the control element or the terminal O&M). The base station receives the following basic commands:  Request for software and configuration backup;  Request for the software modification;  Request for the software reload;  Request for the configuration reload;  Request for the software restart;  Request for initialization of the applications;  Request for BS testing;  Request for the BS initial start;  Request for the BS turning off.
In addition to these requests BS has to receive and process a lot of other requests, associated with applications functioning, the definition of different settings, etc. But they are not associated with software modification.
On command of software and configuration backup main O&M module sends a request to the functional modules for reading and backup of all software modules, memory modules and data blocks, links on blocks and software modules structured DUMP, that includes 3 files: programs, data and links as well as the configuration file stored in flash memory of the main module O&M. After the backup it is executed returning back to operation phase. It should be noted that in the phase of Backup BS continues normal operation only with some restrictions of O&M functions.
The commands to modify the software perform:  Correction of the software block;  Update of the function modules or functional element software;  Upgrade of the base station software.
After upgrading the software of the function Upgrade the initial start (or restart) all software modules and blocks is executed. In two other cases, the software modifying it is executed returning to the operation stage. When the software modifying, BS continues normal operation only with some restrictions of O&M functions too.

Software modification of the base station with the possibility of the reconfiguration
The process of corrections downloading into the software block should be done in the running block, so it may be cause of the unplanned failure of the BS operation and even break it down. Therefore, this operation has been carefully checked before performing. This will allow making software management very flexible and in some cases to avoid serious loss of traffic connected with the Upgrade functions and maintenance costs for software Update.

Sequence description of corrections loading operations into the base station software block
On the command from OSS, the control element or O&M terminal (0-7) executes direct loading of corrections (commands codes) into correction space of the program in processor www.intechopen.com

20
RAM of the functional module ( fig.10).Further corrections are activated by setting navigation in the correction workspace from the points of corrections installation and returning into the next program point from the correction workspace into the software workspace. It also set a mark in the links memory of the software block about the block correction and its status (active / passive).The variables and constants used by software block can be changed directly in the processor RAM of the functional module too. In this case, the correction activation will be consisted of only installing the correction marks in the software block.
The unit is executed the functionality test of the software block with the special tests. If the software block is wrong functioning it is executed the corrections deactivation and retuning the software block into its initial state before corrections with the corrections removal from the correctional workspace.
Further, the commands are send to OSS, the control element or the O&M terminal, with indication of downloading correction error into the software block and then the correction function of the software block is completed. If successful testing of the block with installed correction, the correction function of the software block is completed successfully.

The sequence description for the Update function of the functional module/BS element software
The Update function of the functional modules or elements software should be executed with the ability to transfer all variable data and parameters associated with the block that is modified, into the new modified software module. This function is needed for reducing the cost of BS characteristics redefinition after modification.
On the OSS command the control element or the O&M terminal executes the regional processors separation of the functional module. At the same time working (EX) processor continues to execute the program of the functional module or the functional element, and backup (SB) processor will be used to transfer data into the new module from EX processor. Then it is made direct download software of the new module into SB processor. Then the table of the functional data transfer is downloaded into the EX processor. Interface of data transferring between the EX and the SB processor is activated.
Next step is the data transfer of the software blocks of the functional modified module or the functional element from the EX processor into the SB processor. After data transfer is executed the software of the modified module in SB processor is restarted. Then it is made checking of the new software correct functioning of the module. When work is incorrect the command is sent to OSS, the control element or O&M terminal, and the function Update error of the functional modules or the functional element (0-5) is indicated and then the software Update function in OSS, the control element or the O&M terminal are ended.
On the side of the functional module the SB&EX processors are transferred in parallel operation with the software of the Update function shut downing, and, an actual, loss of the modified software in SB processor.
When new software is executed correct it is made switching the EX&SB processors of the functional module with software restart. Then new software of the functional module or functional element begins to work.
Further if necessary it is made saving the copy of the modified software from the EX processor into the internal flash memory of the functional module. Then EX&SB processors are transferred in parallel operation with the successful completion of the software Update function.

Description of operations for the software of the base station modernization/update
The update function of base station software should be made with the possibility of the all variable data and parameters of all BS software blocks transfer during the transition to a new release of software within a single standard. This function is needed to reduce the cost of the BS character is tics redefinition after modification. When replacing the base station software to another standard, data transfer should be not carried out if new software blocks are not hereditary. In this case, the preparation of new software applications is executed by applications of the radio network scheduler and OSS. Then downloading of the new software into the flash memory of the O&M basic module, its activation, reboot of the function modules and restart are executed.
On command from the OSS, when the Upgrade function with a data transfer is used, the control element or the O&M terminal downloads the new software into flash memory of the main O&M module. At the same time working (EX) processor continues to execute the program of the O&M module and backup (SB) processor will be used to transfer data into the new software blocks from the EX processor. The structure universality of the processor modules should allow software modification of the all functional modules using only the processors of the O&M module.
Then it is made the new software direct downloading of the all modules into SB processor and the BS configuration file loading. After that the tables of functional data transfer of all modules into the EX processor are downloaded and the interface of data transferring between the EX and SB processors is activated.
At the next step the data transfer of all software blocks of all functional modules and functional elements and the configuration file transfer into the base station new software blocks are done.
After the transfer have already done it is executed the BS software restart in the SB processor of the O&M module and checking the correctness of the new software blocks functioning. When the functioning is incorrect the command is sent to OSS, the control element or O&M terminal, which indicates the software error of the BS function Upgrade and then the software of the Upgrade function in OSS, the control element or the O&M terminal completes. On the side of the BS O&M module, the EX and SB processors are transferred into parallel operation to complete the software of the Upgrade function and, as a fact, to loss of the modified software in SB processor.
If operation of new software blocks is correct it is executed modified software backup from EX processor into flash memory of the O&M module with the notes installation to mark the BS active software for further BS software restart after the transfer of the Upgrade function data will be completed.  The block diagram of the operations sequence for software modification is shown on fig. 10.

2.4.4
The general control scheme of the software modification Fig.11 shows the diagram of the software modification control. The software modification control is executed with OSS using software named "Software Manager", which executes: Fig. 11. The general scheme of the software modification control  The loading and activation of the correction in units of BS software;  Downloading the package for the function "Software Update" of a functional module or a functional element and execution of the update software function;  Downloading the new release of software for execution of the base station software upgrade function.
The correctness control of the control objects and the whole base station functioning after software modernization is made by the manager of the radio network quality control.
There is proposed to use the radio network scheduler (located on a separate server) for computing the all radio network parameters and preparing upgrading packages for each network element when the radio access network is upgrading and using the new standards or combining the different standards. The scheduler will use the separate database of installed radio access network equipment. Prepared by the scheduler packages of BS modernization with all settings of the parameters are loaded in the certain sequence through OSS to BS. In this case it can be involved BSC /RNC. The control element or the O&M terminal is also used for the local software upgrades on a separate BS. Fig. 12 shows the processor modules of the BS control objects. The main O&M module is represented by two processors working in parallel mode in the normal operation phase, or in the mode of the separation for Upgrade function. This module is executed the information interchange with the network via O&M interface, and also controls other BS functional modules via control of the local resources. He has flash memory that backup copies of the BS software and the software of the O&M module are stored. RAM is also used for software loading and for the subsequent software start.
The each functional element is also represented by two regional processors functioning in parallel mode in the normal operation phase or in the mode of separation for Upgrade function. The each functional element has its flash memory and RAM. Data exchange with the main O&M unit is run using the control interface of the local resources.

Conclusion
Thus, it is considered a new concept of development a multi-standard mobile network. It includes the architecture of the base station development with the requirements for its functional units and the method of reconfiguration of the radio access network. The method of reconfiguration is based on the state graph of the base station functioning, the block diagram of an operations sequence of base station functioning, the block diagram of an operations sequence of the base station software upgrade, the principle of the software modifications control and structural pattern of the BS control objects with the reconfiguration ability. This allows to development a radio network that is different from existing single standard mobile radio networks by the reconfiguration opportunity without changing the hardware of the radio access network. It also gives the ability to support many radio standards based on the one universal base station platform with flexible antenna systems and using SDR technology.
The next stage of research will be:  Simulation of the proposed algorithms,  Development of the software updating and adaptation algorithms for the mobile terminals functioning in SDR network,  To propose the recommendations for using of all this algorithms in the mobile SDRnetwork development.