KR20100065080A - Method and apparatus for start-up of device manager in mobile terminal - Google Patents

Abstract

PURPOSE: A method for driving device manager in a mobile terminal is provided to drives management component by restarting in remote or itself from a SDR(Software Defined Radio) terminal based on SCA(Software Communication Architecture), thereby effectively manages resource. CONSTITUTION: A manager starting unit performs parsing of DCD(Device Configuration Descriptor) file(S200). If the SPD(Software Package Descriptor) file does not exist in the DCD file, the SDR terminal obtains the object reference value of pre-driven domain manager in a naming service unit(S210,S220). The SDR terminal registers the device manager to relevant domain manager through the obtained object reference value of the domain manager(S230). The SDR terminal registers the device administrator in the naming service unit(S240).

Description

{Method and apparatus for start-up of device manager in mobile terminal}

The present invention relates to a device manager driving method in a portable terminal. More specifically, the present invention relates to a method of remotely or automatically restarting and driving a device manager terminated by an SCA-based Software Defined Radio (SDR) terminal.

The present invention is derived from a study conducted as part of the IT growth engine technology development project of the Ministry of Knowledge Economy [Task management number: 2006-S-012-03, Task name: Development of middleware platform for SDR terminal].

Recently, convergence is the most important change among the factors that characterize the evolution of technology according to the development of information and communication. In addition, voice service-oriented mobile communication user requirements are changing in the direction of using various types of multimedia data in one terminal without limitation of communication mode, type of network and location of use. Changes in these requirements require carriers and handset manufacturers to change their new technologies and paradigms to support multiple communications standards, including existing ones, and to quickly apply or upgrade new standards.

The development of wireless communication technology has provided a lot of services in a variety of communication technologies, but the need for a flexible wireless system began to emerge as the mutual compatibility between the various communication standards are reduced. As an alternative, SDR (Software Defined Radio) technology has begun to be studied to integrate and accommodate multiple wireless communication standards through a single transmission / reception system with only modular software changes without efficient hardware modification.

The concept of SDR is a technology that enables high-speed DSPs, FPGAs, and other reconfigurable components to process from baseband to RF and IF signals, enabling system configurations that are applicable to both existing and new system specifications.

SDR technology enables seamless global communication by downloading object-oriented application software on a single hardware platform with an open structure in order to construct a system that can be flexibly applied in various wireless access environments. By allowing a system to accommodate a specification, it is considered as a system building technology capable of providing multiple standards, multiple processing frequencies, and providing various services.

SDR can be defined as a technology that can integrate various types of wireless communication services, which required the use of different devices, with software changes instead of hardware. In other words, it is an innovative communication technology that integrates existing 2G and 3G, and can implement various communication means such as xDSL, CDMA, GSM, UMTS, CDMA2000, WLAN, Bluetooth, satellite communication in one terminal. Therefore, when the SDR becomes practical, it is possible to receive necessary services only by changing the software in the SDR terminal, which can only be obtained by purchasing various kinds of mobile phones, PCS, WLAN, and the like. In addition, it will enable global roaming, which allows users to receive services anywhere in the world with their own handsets.

On the other hand, in the SCA terminal based on Software Communication Achitecture (SCA), when reconfiguration is performed through mode change, a naming service having information on a component is generally driven. It drives a domain manager that manages device manager, device, service, and application component information in the domain, and drives a device manager that manages logical devices and services. In addition, the device manager manages a device and a service component managed by the device manager, and then drives and reconfigures an application component through a mode change. As such, prior to driving an application component required for reconfiguration, a management component, such as a naming service, a domain manager, a device manager, a device, and a service, must be driven in advance to perform an operation.

In the SCA-based SDR terminal system, the device manager supports various operations to manage logical devices and services. Among these operations, the 'shutdown operation', which shuts down the device manager, shuts down the device / service managed by the device manager and the application components operating in the device and terminates the device manager itself. In addition, the 'shutdown operation' reports the current status to the upper level administrator and reports that the user has been unregistered to the naming service.

As such, when the 'shutdown operation' is used in the device manager, all management components except the naming service and the domain manager and application components operating in the device are terminated. In the conventional SCA-based SDR terminal system, the remote or There was no way to restart the management components (device managers, devices, and services) on their own.

That is, in the conventional SCA-based SDR terminal system, since there was no way to restart or drive the management component remotely or itself, it was not possible to efficiently manage and control resources, and there was a problem in that the system could not be optimized and configured. .

The present invention has been proposed to solve the above problems,

The SCA-based SDR terminal system can be managed remotely or by itself to restart and operate management components (device managers, devices, and services), so that resources can be efficiently managed and controlled to optimize and operate the SCA-based SDR terminal system. The purpose is to make it possible.

In addition, by adding an operation for driving the device manager, it is intended to smoothly drive the management component required for reconfiguration through the mode change in real time in the remote or SDR terminal itself without the operator's manual operation.

It is also an object of the present invention to provide a method of matching the naming service and the domain manager with the current registration information when the device manager is shut down and restarted.

The device manager driving method of the present invention relates to a method of driving a device manager in a portable terminal, wherein the device manager parses a device configuration descriptor (DCD) file to determine whether a software package descriptor (SPD) file exists. step; If the SPD file exists in the DCD file, parsing the SPD file to drive a device; Registering the driven device with itself, initializing and configuring the registered device; Parsing the DCD file to drive a domain manager; And a naming service unit obtaining an object reference value of the driven domain manager and registering itself with the domain manager using the obtained object reference value.

In particular, if an SPD file does not exist in the DCD file, obtaining an object reference value of a domain manager already driven from the naming service unit; And registering itself with the corresponding domain manager using the obtained object reference value.

The parsing of the SPD file and driving the device may include: determining whether a device exists in the SPD file; And if the device component exists in the SPD file, parsing the SPD file to load and execute the device component.

The method may further include processing the driven device to be registered in the naming service unit.

The parsing of the DCD file to drive a domain manager may include parsing a domain configuration descriptor (DMD) file included in the DCD file and an SPD file corresponding to the domain manager to drive the domain manager. It is done.

The method may further include determining whether a device component to be newly registered in the SPD file exists while the device manager is registered with the domain manager; If there is a device component to be newly registered in the SPD file, parsing the SPD file to drive the corresponding device; And registering the driven device with itself and registering the registered device with a domain manager.

The method may further include initializing and configuring the device after registering the device with the domain manager.

The method may further include processing the driven device to be registered in the naming service unit.

The method may further include determining whether a service component to be newly registered in an SPD file exists while the device manager is registered with the domain manager; If there is a service component to be newly registered in the SPD file, obtaining a device on which the corresponding service is to be deployed; Executing and driving the service on the obtained device; And registering the driven service with itself, and registering the registered service with a domain administrator.

The method may further include processing the driven service to be registered in the naming service unit.

According to the present invention has the following effects.

By providing a way to restart and start the management components (device manager, device, and service) remotely or in the SCA based SDR terminal system, SCA based SDR terminal system is optimized by efficiently managing and controlling resources. It becomes operational.

In addition, by adding an operation for driving the device manager, it is possible to smoothly drive the management component required for reconfiguration through the mode change in real time in the remote or SDR terminal itself without the operator's manual operation.

In addition, when the device manager is shut down and restarted, the naming service and the domain manager are matched with the current registration information, thereby maintaining the consistency of data.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. Here, the repeated description, well-known functions and configurations that may unnecessarily obscure the subject matter of the present invention, and detailed description of the configuration will be omitted. Embodiments of the present invention are provided to more completely describe the present invention to those skilled in the art. Accordingly, the shape and size of elements in the drawings may be exaggerated for clarity.

The present invention relates to a method of driving a device manager in a portable terminal. In the following embodiment, a method of driving the device manager in the SDR terminal based on the SCA has been described as an example, but is not limited thereto. Those skilled in the art will appreciate that various modifications and equivalent other embodiments are possible from this.

1 is a block diagram for explaining the structure of an existing SCA-based SDR terminal.

Although not shown in the drawing, the SDR terminal 100 includes an operating system (OS), a CORBA (Common Object), on top of hardware such as a central processing unit (CPU), a digital signal processor (DSP), or a field programmable gate array (FPGA). Request Broker Architecture) and SCA Core Framework (CF) are deployed.

Here, the SCA core framework includes a manager such as a domain manager (140), a device manager (110), a file manager (120), and an application factory (130). A domain profile 160 in the form of an extensible markup language (XML) file exists (see FIG. 1).

Various administrators of the SCA core framework arrange and execute various components of a higher waveform application (hereinafter, referred to as an “application”) on a corresponding hardware device based on a domain profile. At this time, each application component exchanges information with each other using a corresponding port according to the connection configuration defined in the SCA. The connection of each application component is established in one direction, and connection configuration information and corresponding port information between each application component are defined in the form of an XML file in a domain profile.

The device manager 110 described above performs an action by calling an interface operation of the device manager 110 in the SDR terminal 100 through a remote control server (not shown) or by itself.

The domain manager 140 manages the device manager 110, the device, the service, and the application component information in the domain.

The naming service unit 150 manages information about components in the domain. Here, a domain is defined as "a collection of hardware devices under the control of one domain manager component and the applications available on the hardware device".

In addition, the domain profile 160 is a device configuration descriptor (DCD: Device Configuration Descriptor) describing a process (eg, a logical device and service installation method, a method of finding a domain manager, etc.) necessary for driving the device manager 110. Software Package Descriptor (SPD), which defines a file, a Domain Manager configuration Descriptor (DMD) file containing configuration information for domain manager 140, and how to load, run, and implement SCA components. File, and so on.

2 is a block diagram illustrating in detail the structure of an SCA-based SDR terminal according to an embodiment of the present invention.

In the SDR terminal 200 according to the present invention, as shown in FIG. 2, there are administrators such as a domain manager 240, a device manager 300, a file manager 220, and an application factory 230. There is a domain profile 260 in the form of a file. Here, the domain manager 240, the file manager 220, the application factory 230, and the domain profile 260 are basically the domain manager 140, the file manager 120, the application factory 130, and the domain of FIG. 1. Since the same function as the profile 160, a description thereof will be replaced with the description of FIG. 1. The naming service unit 250 manages information on components in the domain.

Referring to FIG. 2, the interface operation of the device manager 300 in the SDR terminal 200 according to the present invention includes a device registration unit 310 and a device manager 300 that provide a mechanism for registering a device with the device manager 300. Device deregistration unit 320 providing a mechanism for deregistering a device from the device), a service registration unit 330 providing a mechanism for registering a service to the device manager 300, and a device deregistration service to the device manager 300 A service deregistration unit 340 that provides a mechanism to perform the above, an implementation identifier unit 350 used to generate an application component, an administrator terminator 360 that provides a mechanism for terminating the device manager 300, and a device manager It consists of an administrator starter 370 that provides a mechanism for starting 300.

In particular, in the present invention, by adding the manager start unit 370 that provides a mechanism for starting the device manager 300 to the interface operation of the existing device manager 300, a management component (device manager, It provides a structure that can smoothly drive (devices and services).

The process of the administrator terminating unit 360 to terminate the device manager 300 and the process of the manager starting unit 370 to start the device manager 300 will be described in more detail with reference to FIGS. 5 and 6 to 11. It will be described later.

3 is a structural diagram of a device manager interface for explaining an operation syntax of the manager starter 370 of FIG. 2.

In the device manager interface according to the present invention, when the device manager 300 is terminated (10), a syntax 12 for starting the device manager 300 is additionally defined.

In the “name” portion of FIG. 3, a name of a device configuration descriptor (DCD) file may be used. As described above, the DCD file describes the actions required to drive the device manager, such as a logical device and service installation method, a domain manager search method, and the like.

According to the present invention, the syntax for starting the device manager 300 is further defined in the device manager interface, so that the management components (device manager, device, and service) required for reconfiguration through mode change can be smoothly driven.

As described above, by adding an operation for driving the device manager, it is possible to smoothly drive the management component required for reconfiguration through the mode change in real time in the remote or SDR terminal itself without the operator's manual operation.

In addition, when the device manager is shut down and restarted, the naming service and the domain manager ensure that the current registration information is matched, thereby maintaining data consistency.

4 is a structural diagram of a DCD file for driving a device manager and related components (devices and service components).

Referring to FIG. 4, the reference numerals 22, 24, and 26 of FIG. 4 may be used to find and drive the device manager component, and may be present between 28 and 36 when the device and the service component are found and driven. This can be done by parsing one or more components. On the other hand, the method of finding a domain manager does not correspond to the main features of the present patent, so a description thereof will be omitted here.

Hereinafter, a method of driving a device manager in an SCA-based SDR terminal will be described in detail. Before describing a method of driving the device manager, a process of terminating the device manager in the manager termination unit of the device manager will be described first.

5 is a flowchart illustrating a process of terminating a device manager.

Referring to FIG. 5, first, an object reference value of a domain manager is obtained (S100). Here, the object reference value means a pointer to a value obtained by realizing the domain manager.

Next, using the object reference value of the domain manager obtained in step S100, the application component (hereinafter, 'application') managed by the device component (hereinafter, 'device') is deregistered from the domain manager and naming service unit (S110). ).

In operation S120, the application registered in the domain manager and the naming service unit is terminated.

After the application is terminated by the domain manager and the naming service unit, the device component and the service component (hereinafter, referred to as "service") managed by the device manager are deregistered from the device manager, the domain manager, and the naming service unit (S130).

Next, the device manager, the domain manager, and the device and the service deregistered from the naming service unit are terminated (S140).

Finally, the device manager is deregistered from the domain manager and the naming service unit (S150), and the process ends by terminating the Divine Manager (S160).

6 to 11 are flowcharts illustrating a device manager driving method according to the present invention. In more detail, FIGS. 6 to 11 are flowcharts for describing a process of driving a device manager and related components (devices, services, and applications) through the manager start of the device manager.

First, referring to FIGS. 6 and 7, an administrator starter of a device manager parses a device configuration descriptor (DCD) file (S200). The DCD file describes the actions required to run the device manager. For example, a logical device and service installation method, a domain manager search method, and the like are defined.

The manager starting unit parses the DCD file to determine whether a software package descriptor (SPD) file exists in the DCD file (S210).

As a result of the determination in step S210, if the SPD file does not exist in the DCD file, the object reference value of the domain manager already driven by the naming service unit is obtained (S220).

The device manager is registered with the corresponding domain manager using the object reference value of the domain manager obtained by the naming service unit (S230), the device manager is registered with the naming service unit and the process is terminated (S240).

If the SPD file does not exist in the DCD file at step S220, since there are no components to be installed (that is, a service, a device, and an application), the manager startup unit uses the object reference value of the domain manager 240 that has been previously driven. Perform step S240.

On the other hand, if the SPD file is present in the DCD file as a result of the determination in step S210, the next step determines whether a device exists in the SPD file (S300).

As a result of the determination in step S300, if a device component exists in the SPD file, the device loads or loads and executes the device by parsing the SPD file (S320).

When the device is driven through the step S320, the driven device registers itself with the device manager (S330).

When the device is registered in the device manager, the device manager initializes and configures the registered device (S340).

Next, the device that has passed through step S340 registers itself with the naming service unit (S350), and ends the process by terminating device driving (S360).

FIG. 8 is a diagram illustrating a process of registering a driven device component with a domain manager through the process of FIG. 7 by driving the domain manager while the domain manager is not driven.

Referring to FIG. 8, the manager starting unit of the device manager determines whether a domain manager component exists in an SPD file obtained by parsing a DCD file (S400).

As a result of the determination in step S400, if a domain manager component exists in the SPD file, the domain manager is parsed by driving a domain configuration descriptor (DMD) file included in the DCD file and an SPD file corresponding to the domain manager (S410).

The domain manager driven through the step S410 registers itself with the naming service unit (S420).

The device manager acquires an object reference value of the corresponding domain manager in the naming service unit (S430), and registers itself with the domain manager using the obtained object manager's object reference value (S440).

Next, the domain manager acquires attribute values of devices managed by the device manager (S450), and registers the devices managed by the device manager to the domain manager using the obtained attribute values (S460).

Finally, the operation of the domain manager is terminated and the process ends (S470).

On the other hand, if the domain manager component does not exist in the SPD file as a result of the determination in step S400, the process ends.

FIG. 9 illustrates a process of registering a new device component with a domain manager while the domain manager is driven through the process of FIG. 8.

Referring to FIG. 9, the manager starter of the device manager determines whether a device component to be newly registered exists in an SPD file obtained by parsing a DCD file (S500).

As a result of the determination in step S500, if there is a device component to be newly registered in the SPD file, the SPD file is parsed (S510).

Next, the SPD file is parsed through the S510 to load the device, or the device is loaded and executed (S520).

When the device is driven through the step S520, the driven device registers itself with the device manager (S530).

Accordingly, the device manager registers the registered device with the domain manager (S535).

The device manager performs initialization and configuration of the corresponding device registered in the domain manager (S540).

Next, the device that has passed through step S540 registers itself with the naming service unit (S550). Finally, the driving of the domain manager is ended to terminate the driving of the device, and the process is completed (S560).

On the other hand, if the domain manager component does not exist in the SPD file as a result of the determination in step S400, the process moves to step S560 to terminate the operation of the domain manager.

FIG. 10 is a diagram illustrating a process of registering a new service component with a domain manager while the domain manager is running.

Referring to FIG. 10, the manager starting unit of the device manager determines whether a service component to be newly registered in the SPD file obtained by parsing the DCD file exists (S600).

As a result of the determination in step S600, when there is a service component to be newly registered in the SPD file, the device manager acquires a device that has already been driven in order to drive and register a service to be placed in a predetermined device (S610).

Next, the service is loaded and executed on a device that is already driven through the operation S610 to drive the service (S620 and S630).

The service registration unit of the device manager registers the service driven through the operation S630 to the device manager (S640).

Next, the device manager registers its service to the domain manager (S650).

In operation S660, the service registered in the domain manager registers itself with the naming service unit.

When the service is registered in the domain manager through the step S660, the domain manager is terminated to terminate the operation of the service and the process is completed (S670).

On the other hand, if the service component does not exist in the SPD file as a result of the determination in step S600, the process moves to step S670 to terminate the operation of the domain manager.

FIG. 11 is a diagram for describing a method in which a device manager registers itself with a naming service unit after processing the aforementioned processes while the domain manager is running.

In the state in which the domain manager is driven, the device manager performing the above-described processes finally registers itself with the naming service unit and ends the device manager driving process of the present invention (S700).

As described above, by restarting and driving management components (device managers, devices, and services) remotely or in the SCA terminal system based on SCA, it is possible to efficiently manage and control resources to optimize the SCA terminal system based on SCA. It becomes operational. In addition, when the device manager is shut down and restarted, the naming service and the domain manager are matched with the current registration information, thereby maintaining the consistency of data.

The present invention can be embodied as computer readable codes on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media may include ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage. Also included are those implemented in the form of carrier waves (eg, transmission over the Internet). The computer readable recording medium can also be distributed over network coupled systems so that the computer readable code is stored and executed in a distributed fashion.

As described above, the best embodiment has been disclosed in the drawings and the specification. Although specific terms have been used herein, they are used only for the purpose of describing the present invention and are not used to limit the scope of the present invention as defined in the meaning or claims. Therefore, those skilled in the art will understand that various modifications and equivalent other embodiments are possible from this. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

1 is a block diagram for explaining the structure of an existing SCA-based SDR terminal.

2 is a block diagram illustrating in detail the structure of an SCA-based SDR terminal according to an embodiment of the present invention.

FIG. 3 is a structural diagram of an interface of a device manager for explaining the operation syntax of the manager starter of FIG. 2.

4 is a structural diagram of a DCD file for driving a device manager and related components.

5 is a flowchart illustrating a process of terminating a device manager in the manager terminating unit of the device manager.

6 to 11 are flowcharts illustrating a device manager driving method according to the present invention.

Claims (10)

A method for driving a device manager in a portable terminal, the device manager, Parsing a device configuration descriptor (DCD) file to determine if a software package descriptor (SPD) file exists; If the SPD file exists in the DCD file, parsing the SPD file to drive a device; Registering the driven device with itself, initializing and configuring the registered device; Parsing the DCD file to drive a domain manager; And And naming service unit obtaining an object reference value of the driven domain manager and registering itself with the domain manager using the obtained object reference value. The method according to claim 1, If an SPD file does not exist in the DCD file, obtaining an object reference value of a domain manager that is already driven from the naming service unit; And And registering itself with the corresponding domain manager using the obtained object reference value. The method according to claim 1, Parsing the SPD file to drive the device, Determining whether a device exists in the SPD file by the device; And If the device component exists in the SPD file, parsing the SPD file to load and execute the device component. The method according to claim 1, And processing the driven device to be registered in the naming service unit. The method according to claim 1, Parsing the DCD file to drive a domain manager, And a domain configuration descriptor (DMD) file included in the DCD file and an SPD file corresponding to the domain manager to drive the domain manager. The method according to claim 1, Determining whether there is a device component to be newly registered in an SPD file while the device manager is registered with the domain manager; If there is a device component to be newly registered in the SPD file, parsing the SPD file to drive the corresponding device; And And registering the driven device with itself and registering the registered device with a domain manager. The method according to claim 6, After registering the device with the domain manager, initializing and configuring the device. The method according to claim 6, And processing the driven device to be registered in the naming service unit. The method according to claim 1, Determining whether there is a service component to be newly registered in an SPD file while the device manager is registered with the domain manager; If there is a service component to be newly registered in the SPD file, obtaining a device on which the service is to be deployed; Executing and driving the service on the obtained device; And And registering the driven service with itself, and registering the registered service with a domain manager. The method according to claim 9, And processing the driven service to be registered in the naming service unit.

Images