KR19980034077A - Structure of Code Division Multiple Access Mobile System Loading File Format (CLOFF) and Loading Method Using the Same - Google Patents

Abstract

Execution modules to be loaded into the CMS system are loaded with execution modules of various formats according to the type of compiler used. It is virtually impossible to control the version of the system loader for loading the various types of execution modules into the system and the system loader independent of the execution modules. In order to solve this problem, the present invention defines a CMS loading file format (CLOFF) and simplifies the loading procedure and load time by unifying the execution module format generated from the compiler currently being used for CMS system development into the CMS loading file format. Disclosed is a structure of a code division multiple access mobile system loading file format (CLOFF) capable of managing a version of a loader independently of a shortcut and execution module, and a loading method using the same.

Description

Structure of Code Division Multiple Access Mobile System Loading File Format (CLOFF) and Loading Method Using the Same

The present invention relates to a code division multiple access mobile system (hereinafter referred to as CMS), and more particularly, to a structure of a CMS loading object file format (hereinafter referred to as CLOFF) and a loading method using the same. It is about.

The CMS is a loosely coupled realtime embedded system controlled by a stored program. The program of the CMS is downloaded from the SUN workstation in charge of the operation and maintenance of the system at the site installation. At this time, the loading format downloaded is a common file object format (COFF), S-S, depending on the type of compiler used by the programmer involved in the development. There may be various things such as a record format (hereinafter referred to as S-Record). Therefore, the CMS system loader must support all existing executable module formats as well as future executable module formats. Therefore, if the format of the executable module is changed by replacing the compiler, the system loader must be changed. Lose. In addition, executable files generated by commercial compilers contain extra information needed for text (TEXT), data (DATA), Basic Synchronization Subset (BSS), linking and debugging, etc. Depending on the operating system it operates on, it adopts its own executable file format. In addition, even if an executable file is generated by the same compiler, it may take a different form depending on the nature of the program. Therefore, different loading mechanisms are required depending on the compiler and the nature of the program. As a result, the system loader must adopt a very complex procedure, and can only load the currently defined executable, so the system loader must be changed to load an undefined executable. Therefore, the system loader is strictly dependent on the currently defined executable file format.

The program of the CMS loads each processor by the system loader. Program of CMS is composed of operating system, application program, program data file, etc. and has different execution module format according to compiler used. Therefore, since the system loader recognizes each execution module and loads the execution module into the system by different procedures, the system loader is strictly dependent on the supported execution module and cannot perform independent version control.

Accordingly, the present invention for solving the above problems provides a loading method using a new file format defined in order to simplify the loading procedure, to reduce the loading time and to manage the version of the loader independent of the execution module. Its purpose is to.

The structure of the code division multiple access mobile system loading file according to the present invention for achieving the above object comprises a file header containing file maintenance information required for file version management and program execution data in an executable file. It is characterized by consisting of a section header containing information on whether or not, and section data consisting of program execution code and data.

In addition, the loading method using the code division multiple access mobile system loading file format according to the present invention for achieving the above object comprises the steps of receiving the next file information to be changed in the loading information table, and the next file to be changed based on the received information Checking whether the file exists, and if the next executable file to be changed exists, checking the file format of the loaded program from the next file information to be changed, and if the next executable file to be changed exists, and the next executable file to be changed exists. If there is no executable file to be changed next, after downloading all changed code division multiple access mobile system loading files to the operating station and terminating, and if the result of the checking of the loaded program file format is non-BSD (BSD) format, Code Division Multiple Access to SD (BSD) Format Converting to a mobile system loading file format, converting a common file format into a code division multiple access mobile system loading file format when the loading program file format is a common file format, and checking the loading program file format Converting the S-Record format to a code division multiple access mobile system loading file format in the case of the resultant S-Record format; Terminating if the file is a file other than a file format, a common file format, and an S-record format, and inputting information of the converted code division multiple access mobile system loading file format into a version information file of an executable file. And inputting file format information into the version information file of the executable file, and then, in the loading information table, And transitioning to receiving the file information to be changed.

1 is a structural diagram of a CMS system to which the present invention is applied.

2 is a flowchart illustrating a loading procedure of a CMS system to which the present invention is applied.

3 is a structural diagram of CLOFF used in format conversion according to the present invention;

4 is a flowchart illustrating a loading method using CLOFF according to the present invention.

5 is a flowchart illustrating a procedure of generating a VIP file according to the present invention.

Explanation of symbols on the main parts of the drawings

1 mobile station 2 base station

3: mobile telephone exchange 4: home location register

5 wireless base station 6 control station

7: operating station 8: channel element

9 wireless base station interconnection network 10 wireless base station call processing processor

11 radio frequency transmitter and receiver 12 control station group

13 group CDMA interconnection network 14 transcoding selector bank

15 call control processor 16 CDMA interconnection network

17: exchange bureau 18: landing location register

The present invention will be described in detail with reference to the accompanying drawings.

1 is a structural diagram of a CMS system to which the present invention is applied. The CMS consists of four subsystems. The four subsystems are the mobile station (hereinafter referred to as MS) (1), the base station (hereinafter referred to as BS) (2), the mobile telephone exchange station (hereinafter referred to as MS) (3), and the home location. It consists of a register (Home Location Register: HLR) (4). BS 2 is again referred to as a radio base station (Base Transceiver System: BTS) (5), control station (Base station Controller: BSC) (6), operating station (Base station Manager: BSM) ( It consists of 7).

The MS 1 processes the radio signal received from the BTS 5 into four correlation detectors, one of which is a search receiver (not shown), which searches for a pilot signal transmitted from an adjacent base station to the carrier phase of the nearest base station. Obtained as a standard. The search receiver determines a strong signal path among the signals received in the handoff region. The other correlation detector is a digital data receiver (not shown) that correlates signals received in the multipath detected by the search receiver with a corresponding pseudo noise sequence.

The BTS 5 transmits and receives subscriber information and is responsible for wireless connection with the MS 1 and wired and wireless connection with the BSC 6. The BTS 5 includes a channel element 8 (hereinafter referred to as CE) 8, a base station interconnection network (hereinafter referred to as a BIN) 9 and a base station control processor (hereinafter referred to as a BCT). (10) and a radio frequency transmitter / receiver (hereinafter referred to as RF) 11. The CE 8 is responsible for CDMA channel coding / decoding, sector-by-sector interface, performing analog common functions for side / walling, receiving reference time and frequency information, and distributing and supplying functions. The BIN 9 is in charge of controlling and transmitting / receiving traffic information with the BSC 6 via the relay line E1. The BCP 10 is configured with redundancy and controls the BTS 5 overall functions such as receiving and distributing time-of-day (TOD) information of the alarm information vertical and global position system (GPS). The RF 11 is responsible for a low noise of a signal, a large power amplification function, a band filtering function of a transmission / reception signal, a frequency conversion function, a signal combining and distribution function for multi-frequency allocation, and the like. Up to three frequencies, three sectors, 320 traffic channels, and eight E1 trunks can be configured per one BTS 5.

The BSC 6 is located between the BTS 5 and the MX 3 to control the BS 2 and to handle power control and handoff of the MS 1. The BSC 6 is composed of a base station control group (hereinafter referred to as BSCG) 12 and a group CDMA interconnection network (hereinafter referred to as GCIN) 13, which is a communication network between the BSCG. . The BSCG 12 includes a transcoding selector bank (hereinafter referred to as TSB) 14 and a call control processor (hereinafter referred to as CCP) 15 as a CDMA interconnection network (hereinafter referred to as CIN). (16). The BSC (6) consists of 12 BSCGs, 4 selector vocoder processor / selector interface processor (SVP / SIP), 15 channels / SVP, 32 by group TSB Unit / CCP A transcoding channel of x60 = 1,920, BTS and 48 E1 trunks, MX (3) and 64 E1 trunks can be mounted, controlling up to 512 base stations.

The BSM 7 collects various types of information on failures, states, statistics, and the like of the BS 2 and the BSC 6, and performs each subsystem operation management and maintenance function. BSM (7) duplicates commercial workstations (line workstations) through High Level Link Control (HDLC) port redundancy and match mode redundancy to collect and process alarms, and to maintain and operate the entire BS. Performs maintenance control and base station program loading and operator matching.

The MX 3 is composed of an exchange station (Mobile Switching Center (MSC) hereinafter) 17 and a visitor location register (hereinafter referred to as VLR) 18. The MSC 17 is responsible for call processing for subscribers and interworking and operation management between a Public Switched Telephone Network (PSTN) and an Analog Mobile Telecommunications System (AMPS) network. The VLR 18 is located in the MX 3 to store location information about the subscriber and is responsible for database functions.

The HLR 4 performs a central database function for storing temporary information, such as permanent information about the subscriber registered in the digital mobile communication network and the subscriber's current location information.

2 is a flowchart illustrating a loading procedure in a BSM of a CMS system to which the present invention is applied. Application software and processor load data (hereinafter referred to as PLDs) developed on the host system are stored in the BSM's load directory in order of operating system, application, and PLD using UNIX commands (ftp) or cartridge tape. When the BSM receives a load request from the CCP by the power of the CCP or a hardware reset (22), the BSM refers to the load information from the BSM PLD to download an operating system, an application program, or a PLD. It is sequentially loaded on the CCP (23). At this time, the CCP loads not only the CCP itself but also the TSB, BSC, and CE in the group. The CCP loading the load program checks the load request from the TSB (24) and if there is a load request, loads the TSB load program from the CCP to the TSB (25) and then checks the load request from the BCP (26). If there is no loading request in step 24, the process proceeds to step 26. If there is a loading request from the BCP as a result of the check in step 26, the BCP loading program is loaded from the CCP to the BCP (27) and then the loading request from the CE is checked (28). If there is no loading request in step 26, the process proceeds to step 28. If there is a loading request from CE as a result of the check in step 28, the CE loading program is loaded from the CCP to the CE (29) and ends. If there is no loading request from CE as a result of the command of step 28, the process ends immediately.

3 is a structural diagram of CLOFF used in the file format conversion according to the present invention. CLOFF consists of a file header 301, a section header 302, and section data 303. The file header 301 contains file maintenance information necessary for file version management, and the section header 302 contains information on how the execution data of the program is configured in the executable file. The file header 301 stores the name 4 bytes 304 of the current file loaded on the target, the version 4 vipe 305 of the loaded file, the name 4 bytes 306 of the site on which the file is loaded, and CLOFF. The generated last date 4 bytes 307 and the like are sequentially configured. The section header 302 represents the physical shape in the CLOFF file of TEXT, DATA, and BSS required for program execution. The section header 302 includes a name 308 of the section header and an address 309 of the section data. Section data 303 is composed of text (TEXT) 310, which is actual execution code, data (DATA) 311, which is initialized data, and BSS 312, which is uninitialized data.

4 is a flowchart illustrating a loading method using CLOFF according to the present invention. The file format converter receives (401) the next executable file name to load in the loading information table prior to downloading. Based on the received name, it is checked whether there is a file to be changed to CLOFF next (402). If there is no file to be changed to CLOFF next as a result of the check, all changed CLOFF files are downloaded to the BSM (403) and then terminated. . If there is an executable file to be changed to a CLOFF file after the inspection result, the executable program file format is checked from the file name to be changed (404). The loaded file is examined and converted to CLOFF format (406) if it is in BSD format (405). In the case of the COFF format (407), the COFF is converted to the CLOFF format (408). In case of the S-Record format (409), the S-Record is converted into the CLOFF format (410). After extracting the version management information of the program from each changed program to generate a version information file (Version VIP of execution per Processor: hereinafter VIP) of the processor for each processor sequentially (411) and proceeds to step 401. If the result of the check in step 404 is of a type other than the BSD format, the COFF format, and the S-Record format, the process ends (412).

5 is a flowchart illustrating a procedure of generating a VIP file according to the present invention. The configuration database, which changes every time the system is configured, is opened (501) and the next processor name is read (502). It is checked whether all processor names in the shape database have been processed (503). If there is a processor name to be processed, a file belonging to the processor is read from the shape database (504). Processed all processor names in the formation database and terminates. It is checked whether all files belonging to the processor are opened (505). If the file to be opened exists, the file maintenance information is read from the corresponding CLOFF file (506), added to the VIP file of the processor (507), and then the process proceeds to step 504. If there is no file to open in step 505, the VIP file of the processor is closed (508) and the process moves to step 502. One VIP file is created for each processor and contains file maintenance information for all files loaded on that processor.

As described above, according to the present invention, it is possible to standardize the format of an execution module loaded in a system to unify different loading mechanisms for each execution module. Therefore, the system loader program can be configured with a single loading mechanism, and the system loading time of the program can be shortened. The newly defined CLOFF executable file includes data necessary for version control of the execution module, so that the actual CMS program can be Version control is possible, and the loader version is independent of executable modules.

Claims (6)

A file header containing information about file maintenance required for file versioning, A section header containing information about how program execution data is organized in the executable, A structure of a code division multiple access mobile system loading file format, comprising section data consisting of program executable code and data. The method of claim 1, wherein the file header includes a name of a current file loaded on a 4-byte target, The version of the 4-byte load file, The name of the site on which the 4-byte file is loaded, A structure of a code division multiple access mobile system loading file format, wherein a final date of generating a 4-byte code division multiple access mobile system loading file is sequentially configured. The structure of a code division multiple access mobile system loading file format according to claim 1, wherein the section header consists of a name of a section header and an address of section data. 2. The code division multiple access mobile system loading file format of claim 1, wherein the section data comprises text TEXT that is actual executable code, initialized data, and a default subset of synchronization that is uninitialized data. rescue. Receiving file information to be changed next in the loading information table; Checking whether there is a file to be changed next based on the received information; Checking an executable file format to be changed if a next executable file to be changed is found as a result of the checking whether the next file to be changed exists; Downloading all changed code division multiple access mobile system loading file formats to the operating station and ending if the next executable file to be changed does not exist as a result of checking whether the next executable file to be changed exists; Converting the BSD format to a code division multiple access mobile system loading file format when the execution file format is a BSD format; Converting a common file format into a code division multiple access mobile system loading file format when the loading program file format is a common file format; Converting an S-Record format into a code division multiple access mobile system loading file format when the loading program file format is an S-Record format; Terminating the file in a file other than the BSD format, the common file format, and the S-Record format as a result of the inspection of the loaded program file format; Inputting information of the converted code division multiple access mobile system loading file format into a version information file of an executable file; Loading the code division multiple access mobile system loading file format, characterized in that the step of inputting the file format information in the version information file of the executable file and transitioning to receiving the next change file information in the loading information table Way. The method of claim 5, wherein the version information file of the executable file comprises: reading a processor name by opening a shape database; Checking whether there is a processor name to be processed next in the shape database; Checking that the processor name exists and reading the next file belonging to the processor by opening a shape database if the processor name exists; Terminating if the processor name does not exist as a result of checking whether the processor name exists; Checking whether there is a next file to be opened belonging to the read processor; Reading file maintenance information from a corresponding code division multiple access mobile system loading file format when a next file to open is found as a result of checking whether the file to be opened exists; Adding file maintenance information to the version information file of the execution file of the processor in the corresponding code division multiple access mobile system loading file format, and then transitioning to reading the file of the next processor by opening a shape database; If the file to be opened does not exist as a result of checking whether the next file to be opened exists, it is generated by closing the version information file file of the execution file of the processor and opening the shape database to read the next processor name. A loading method using a code division multiple access mobile system loading file format.