KR100334906B1 - Method for Constructuring Effective Multi-tasks in V5 System - Google Patents

Abstract

The present invention can efficiently readjust various V5 modules and line card or device driver modules in a processor board when developing a V5 system in an exchange or access network to test various multi-task structures in an upper level exchange or access network. The present invention relates to a multi-task configuration method in a V5 system. In particular, a first process of identifying a related module and defining a module characteristic defining a corresponding module identifier, and a transmission module based on the module characteristic defined in the first process A second step of defining a queue identifier of the receiving task and defining a queue identifier of the receiving task after defining a queue identifier of the receiving task and determining a task allocation scenario; and a module entry function and a task if the queue identifier of the receiving task is defined through the second process. A third process of defining a function and a message sending function, If the gajeok implementations require determine whether it is necessary to apply the fourth step, and an additional task assignment scenarios to implement the relevant function, and perform the test on demand there is a fifth process proceeds to the re-2 process.

Description

{Method for Constructing Effective Multi-tasks in V5 System}

The present invention relates to a multi-task configuration method for efficiently realigning various V5 modules and line cards or device driver modules in a processor board when developing a V5 system in an exchange or access network. The present invention relates to a multitask configuration method in a V5 system for testing various multitask structures in a network.

In general, V5 communication system developers are LAPV5-EF, LAPV5-DL, PSTN, CTRL (Control), BCC, PTCN (Protection), LKCT (Link Control), LKCT-FSM (Link Control Finite State Machine), SM (V5) .1 System Management, SM2 (V5.2 System Management), SPORT-FSM (V5.1 Link Status FSM), S2PORT-FSM (V5.2 Link Status FSM), PPORT-FSM (PSTN Port Status FSM), BRPORT Consider the issue of what communication environment to configure to maintain acceptable performance when systemizing related V5 modules such as ISDN Basic Rate Port Status FSM and PRPORT-FSM. do.

In this process, various technologies have been proposed since the functional implementation is given priority in the early stage of development. Looking at such conventional technologies, Korean Patent Laid-Open Publication No. 99-061490 (V5.2 interface implementing device in an exchange) as a prior art. And Korean Laid-Open Patent No. 99-049832 (a subscriber transmission device for implementing an IDLC function).

These prior arts are a switch-related interface configuration or the subscriber transmission device inputs a switching unit for extracting and inserting only the signaling information channel between the subscriber channel unit and the E1 trunk unit into the corresponding E1 time slot, and the signaling channel information from the switching unit. It is a configuration method for the HDLC control processing unit which receives and processes the data and returns it to the switching unit, and is not a technology related to the integrated task structure.

However, even though functional implementation is a priority in the early stages of development, the need for an efficient multi-task generation environment in terms of performance and maintenance is a problem that many designers feel at the present time, especially line card drivers or specific chips. The control program that connects the driver and the V5 protocol stack also needs a variety of changeable task structures to derive the optimal task creation environment on the same processor board.

Without this efficient multitasking construct, most development can only be done on a specific multitasking construct, and testing different multitasking constructs requires tracking and changing relevant sources as new task structures change. It is suggested that various tests cannot be conducted smoothly due to accurate change and difficult maintenance. However, the proposed technology is not suggested until now.

An object of the present invention for solving the above problems is to develop a variety of V5 modules and line cards or devices when developing a V5 system in an exchange or access network to test various multi-task structures in the higher level exchange or access network. To provide a multitasking configuration in a V5 system that allows driver modules to be efficiently recalibrated on the processor board.

1 is a schematic diagram of a V5 protocol stack

2 is an exemplary diagram of communication environment elements (message header structure, transmission queue identifier, reception queue identifier, etc.) to which the present invention is applied.

3 is a diagram illustrating a transmission / reception scheme of a module for LAPV5-DL, BCC, PTCN, LKCT, and LKCT-FSM in scenario # 3;

4 is a flowchart illustrating an efficient multi-task configuration method in a V5 system to which the present invention is applied.

A feature of the multi-task configuration method in the V5 system according to the present invention for achieving the above object is a first step of defining a module characteristic to identify the relevant module and define the corresponding module identifier, and defined in the first step A second process of defining a queue identifier of a sending module and a task allocation scenario based on module characteristics, and defining a queue identifier defining a queue identifier of a receiving task, and a queue identifier of a receiving task through the second process If so, the third step of defining the module entry function, the task function and the message sending function, the fourth step of implementing and testing the relevant functions if additional implementation is required, and the additional task assignment scenarios need to be applied. If necessary, and includes a fifth process proceeds to the second process if necessary.

As an additional feature of the multi-task configuration method in the V5 system according to the present invention for achieving the above object, the first process includes the steps of identifying a relevant module for the module characteristic definition step, and the related module identified in the step. Defining the module identifier in the.

As another additional feature of the multitask configuration method in the V5 system according to the present invention for achieving the above object, the second process selects and defines the need for the queue identifier definition of the transmitting module for the queue identifier definition step. And determining whether a task allocation scenario is required, determining the scenario, and defining a queue identifier of the receiving task.

As another additional feature of the multitask configuration method in the V5 system according to the present invention for achieving the above object, the third step is a necessity for defining a module entry function for the module entry / task / message transmission function definition step. And selecting and defining the necessity, selecting and defining the need for a task function definition, and selecting and defining the need for a message transmission function definition.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings.

Figure 1 is a schematic diagram of the V5 protocol stack showing the functional structure of the V5.

The functional structure of the V5 consists of the Layer 1 FSM functions of the User and Service ports as a whole, the functions of the LAPV5 Layer 2, the Layer 3 functions of the PSTN signaling protocol, protection protocol, BCC protocol, control protocol and link control protocol, and It consists of functions of the application layer of V5 system management.

The PSTN User Port, ISDN BA User Port, ISDN PA User Port, and V5 Service Port functional blocks, to which reference numbers are not assigned, represent physical ports for subscribers and service nodes connected to the access network. It is not included in the structure.

In addition, the LAPV5 function block includes frame relay (FR) functions of LAPV5-DL, LAPV5-EF, and ISDN D-channels, and corresponding functions between these functions. In addition, the LAPV5-EF sublayer function, which performs bit stuffing and de-stamping functions for LAPV5-DL frames, ISDN D / F / Ds frames, and FCS check and generation, is replaced by a function handled by an HDLC controller. It is not included in the functional structure of.

Hereinafter, the components related to the functional structure of the V5 to which the present invention is applied will be described.

Protocol modules, referred to as references 1 and 2, include EAP address checking and LAPV5-DL or ISDN, in addition to bit stuffing and de-stamping functions for LAPV5-DL frames, ISDN D / F / Ds frames, and FCS check and generation. LAPV5-EF sublayer (1), which functions as an interface to the FR function, and establishes a data link for reliable transmission of protocol (PSTN, control, etc.) information for layer 3 and performs control functions for detecting abnormal conditions. It consists of the LAPV5-DL sublayer (2).

The CTRL (Control) protocol module, referred to by reference number 3, provides user port control functions, such as blocking and unblocking user ports, and information transfer functions related to interface identifiers and common control functions, such as identification or reprovisioning of a variant. To perform.

In addition, the PSTN signaling protocol module 4 performs a control related information transfer function for the telephone service call via the access network.

In addition, the bearer channel connection (BCC) protocol module 5 performs on-demand information transfer of bearer channels between user ports and service ports for aggregation of V5.2 service calls.

In addition, the Bearer Channel Connection Resource Management (BCC-RM) module 6 is a module that performs resource management functions such as allocation and release of connection resources to perform the BCC protocol.

In addition, the link control protocol module, which is composed of two sub-modules, a link control FSM (LKCT-FSM) 8 and a link control protocol (LKCT) 7, has an agreement between the access network and the switching period signal link. It performs the function of identifying V5.2 E1 link and supporting information to support blocking / unblocking of V5.2 E1 link in operation.

In addition, PTCN (Protection) protocol module 9 performs a transfer related information transfer function to operate a reliable physical C channel of the V5.2 signal link.

In addition, the system management module indicated by reference numerals 10 and 11 requests management of user ports and service ports, initialization of provisioning data, setting of datalinks for overall management of the V5 system, and a system for a V5.1 interface. It consists of two submodules: Management (SM) and System Management (SM2) for the V5.2 interface.

The AGT module 12 performs an agent matching function for provisioning, configuration, and failure of V5.

PPORT-FSM (PSTN Port Status FSM), BRPORT-FSM (ISDN Basic Rate Port Status FSM), PRPORT-FSM (ISDN Primary Rate Port Status FSM) and SPORT-FSM (V5. 1 Link Status FSM) and S2PORT-FSM (V5.2 Link Status FSM) are modules that manage the status FSM for PSTN port, ISDN BRI and PRI ports, and V5.1 and V5.2 E1 links, respectively.

An example of a task assignment scenario applied to the functional structure of V5 configured as shown in FIG. 1 will be described with reference to Table 1 described below.

module Task assignment scenario # 1 Task assignment scenario # 2 Task assignment scenario # 3 LAPV5-EF V5Single LAPV5-EF EF LAPV5-DL LAPV5-EF DL PSTN PSTN L3 CTRL CTRL BCC BCC (V5.2) L32 (V5.2) PTCN PTCN (V5.2) LKCT LKCT (V5.2) LKCT-FSM LKCT-FSM (V5.2) SM SM (V5.1) SM (V5.1) SM2 SM2 (V5.2) SM2 (V5.2) BCC-RM BCC-RM (V5.2) SPORT-FSM SPORT-FSM (V5.1) LFSM (V5.1) S2PORT-FSM S2PORT-FSM (V5.2) LFSM (V5.2) PPORT-FSM PPORT-FSM PFSM BRPORT-FSM BRPORT-FSM PFSM PRPORT-FSM PRPORT-FSM (V5.2) PFSM (V5.2) AGT AGT AGT

Table 1 summarized above relates to a task allocation scenario for each module to which the present invention is applied, and does not include line card or device driver modules for convenience.

In case of task assignment scenario # 1, all modules are included in one task (v5Single), task assignment scenario # 2 is a structure for executing each module in its own task, and task assignment scenario # 3 is This is a task structured by grouping V5.1 layer 3 modules (CTRL, PSTN) and V5.2 layer 3 modules (BCC, PTCN, LKCT, LKCT-FSM).

Of course, another task structure can be determined according to the developer's decision, but for convenience, it has three task structures to solve the technical problem.

In task assignment scenarios # 2 and # 3, tasks marked V5.1 or V5.2 are valid only within the interface. Tasks not marked V5.1 and V5.2 are marked V5.1 and V5.2. Commonly applied in the interface. The advantages of each scenario are as follows.

First, scenario # 1 is a structure that can sequentially check the output messages generated by a single message input to the system before the system is stabilized. Therefore, errors in the operation process of each module can be easily confirmed.

Therefore, after repeating a significant level of debugging with repeated tests for scenario # 1, performance testing can be performed by applying scenario # 2 or scenario # 3.

In the same structure as in scenario # 1, in order to process another message input to the system in all related modules, the operation for the previously input message must be terminated, resulting in the lowest performance in the system level. Therefore, in order to improve system performance, a multi-task structure having a pipelined processing function is required.

In addition, scenario # 2 is a structure that can be easily applied in that each module is separated into each task. Scenario # 3 has a burden of defining the characteristics of modules that can be grouped into the same task. It can be used when there is difficulty in system configuration due to excessive task excessive.

For Table 1, examples of communication environment elements (message header structure, transmission queue identifier, reception queue identifier, etc.) to which the present invention is applied are shown in FIG. Since the node identifier indicates the processor board identifier, the node identifier is meaningless in the same processor board, and only the receiving module identifier is used.

In addition, when transmitting a message from one module to another module to include a queue identifier variable corresponding to the receiving module identifier. Therefore, the message header applied in the present invention must include at least the receiving module identifier.

In addition, the queue identifiers in the transmitting module and the receiving task are examples of a case in which the inter-task communication method is used as a queue method, and in the case of using another inter-task communication method, there may be another identifier.

2 does not include queue identifiers for line card or device driver modules for convenience, all modules in a system incorporating V5 related modules and line card or device driver modules in one processor board. After checking these, you must assign a queue identifier for each module. For the purpose of assigning the queue identifier in the sending module, it is expressed as queueID_XXX.

For Task Assignment Scenario # 1 in Table 1, all queue identifier variables contain the same queue value, for Task Assignment Scenario # 2 all queue identifier variables contain different queue values, and partially for Task Assignment Scenario # 3. Include the same cue value.

Among the queue values corresponding to each scenario, the case of assigning the queue identifier in the transmission module is shown in Table 2 below, and the table below shows the case of assigning the queue identifier in the receiving task. Table 3 is as follows.

module Queue identifier variable Queue value of # 1 Queue value of # 2 Queue value of # 3 LAPV5-EF queueID_001 One One One LAPV5-DL queueID_002 One 2 2 PSTN queueID_003 One 3 3 CTRL queueID_004 One 4 3 BCC queueID_005 One 5 4 PTCN queueID_006 One 6 4 LKCT queueID_007 One 7 4 LKCT-FSM queueID_008 One 8 4 SM queueID_009 One 9 5 SM2 queueID_010 One 10 6 BCC-RM queueID_011 One 11 6 SPORT-FSM queueID_012 One 12 7 S2PORT-FSM queueID_013 One 13 7 PPORT-FSM queueID_014 One 14 8 BRPORT-FSM queueID_015 One 15 8 PRPORT-FSM queueID_016 One 16 8 AGT queueID_017 One 17 9

module Queue identifier variable Queue value of # 1 Queue value of # 2 Queue value of # 3 V5Single queueID_000 One LAPV5-EF queueID_001 One One LAPV5-DL queueID_002 2 2 PSTN queueID_003 3 CTRL queueID_004 4 BCC queueID_005 5 PTCN queueID_006 6 LKCT queueID_007 7 LKCT-FSM queueID_008 8 SM queueID_009 9 SM2 queueID_010 10 BCC-RM queueID_011 11 SPORT-FSM queueID_012 12 S2PORT-FSM queueID_013 13 PPORT-FSM queueID_014 14 BRPORT-FSM queueID_015 15 PRPORT-FSM queueID_016 16 AGT queueID_017 17 9 L3 queueID_018 3 L32 queueID_019 4 L42 queueID_020 6 LFSM queueID_021 7 PFSM queueID_022 8

These queue values, summarized in Tables 2 and 3 above, must be defined based on the queue identifier assignment in the sending module, and the actual program source defines the queue values for each scenario in one title file (* .h). Do not change it in regular files (* .c or * .cc).

The accompanying FIG. 3 shows LAPV5-DL (2), BCC (5), PTCN (9), LKCT (7), and LKCT-FSM (8) in scenario # 3 of the scenarios shown in Tables 1-3. The transmission / reception scheme of the module is shown.

Accordingly, a programming language expression for the reception procedure for the task LAPV5-DL (2), the reception procedure for the task L32, and the message transmission procedure is as follows.

The programming language representations for these procedures are briefly expressed using the system calls (sc_qpost, sc_qpend) of the VRTX real-time operating system and the C ++ programming language. The task LAPV5-DL reception procedure is as follows.

void TaskDL ()

{while (1)

{pMsgBuffer = (tMsgBuffer *) sc_qpend (queueId2_002, 0L, &err);

if (err == RET_OK)

(if (pMsgBuffer-> destinationBlock == V5L2_DL)

V5ODLController.V5MProcessDLEvent (pMsgBuffer);}

}

}

It is also the same as the program language expression for task L32 receiving procedure.

void TaskL32 ()

{while (1)

{pMsgBuffer = (tMsgBuffer *) sc_qpend (queueId2_019, 0L, &err);

if (err == RET_OK)

(if (pMsgBuffer-> destinationBlock == V5L3_BCC)

V5OBCCCtrlr.V5MProcessBCCEvent (pMsgBuffer);

else if (pMsgBuffer-> destinationBlock == V5L3_LKCT)

V5OLinkCtrlr.V5MProcessLKCTEvent (pMsgBuffer);

else if (pMsgBuffer-> destinationBlock == V5L3_LKCTFSM)

V5OLkctFSMCtrlr.V5MProcessLKCTFSMEvent (pMsgBuffer);

else // pMsgBuffer-> destinationBlock == V5L3_PTCN

V5OPtcnCtrlr.V5MProcessPTCNEvent (pMsgBuffer);}

}

}

It is also the same as the program language expression for the message transmission procedure.

void

V5CMessageSender :: V5MsendV5Message

(tMsgBuffer * pMsgBuffer)

(if (pMsgBuffer-> destinationBlock == V5L2_DL)

sc_qpost (queueId_002, (char *) pMsgBuffer, &err);

else if (pMsgBuffer-> destinationBlock == V5L3_BCC)

sc_qpost (queueId_005, (char *) pMsgBuffer, &err);

else if (pMsgBuffer-> destinationBlock == V5L3_PTCN)

sc_qpost (queueId_006, (char *) pMsgBuffer, &err);

else if (pMsgBuffer-> destinationBlock == V5L3_LKCT)

sc_qpost (queueId_007, (char *) pMsgBuffer, &err);

else // pMsgBuffer-> destinationBlock == V5L3_LKCTFSM

sc_qpost (queueId_008, (char *) pMsgBuffer, &err);

}

Therefore, in the case of the module transmission / reception scheme for the LAPV5-DL (2), BCC (5), PTCN (9), LKCT (7), and LKCT-FSM (8), the LAPV5-DL (2) module is a LAPV5-EF module. (1) The direction in which the message received from the module is transmitted to the BCC 5, the PTCN 9, and the LKCT 7 and the reverse direction thereof is the BCC 5, the PTCN 9, the LKCT-FSM 8. The module expresses the direction in which the message transmitted from the LAPV5-DL (2) and LKCT (7) modules is transmitted to the other module and its reverse direction.

In the case of the reception procedure for task LAPV5-DL (2) or L32, the reception related virtual queue identifier variable queueID2_002 or queueID2_019 is checked to check whether a message has entered its own queue. If a successful return is obtained, the receiving module is examined and its entry functions (V5MProcessDLEvent, V5MProcessBCCEvent, V5MProcessPTCNEvent, V5MProcessLKCTEvent, V5MProcessLKCTFSMEvent) are called. Send a message to queueID_002, queueID_005, queueID_006, queueID_007, queueID_008.

4 is a flowchart illustrating an efficient multitask configuration method in a V5 system to which the present invention is applied.

When the processing operation is started through the step S20, the process proceeds to step S21 to identify the relevant module and define module characteristics defining the corresponding module identifier. Subsequently, in step S 22, the queue identifier of the transmitting module is defined based on the module characteristics defined in step S21, the task allocation scenario is determined, and the queue identifier defining the queue identifier of the receiving task is defined.

When the queue identifier of the receiving task is defined through the process of step S22, the module entry function, the task function, and the message sending function are defined through the process of step S23, and related functions are required when further implementation is required through the process of step S24. After implementing and performing the test, it is finally confirmed whether additional task assignment scenarios need to be applied through the process of step S25, and if necessary, the process proceeds to the step S22 again and ends through the step S26 if unnecessary.

At this time, if the module characteristic definition process of step S21 is subdivided, the process of step S27 to step S30 is performed.

At this time, when it is necessary to apply an additional task allocation scenario, since the queue identifier of the transmitting module has already been defined in the previous scenario, the task allocation scenario required immediately is determined, and then the queue identifier of the receiving task is defined (steps S31 to S37). ).

In addition, since the module entry function is already defined in the previous scenario, the task function is defined immediately. Since the message transmission function is also determined in the first scenario, the next step is performed (steps S38 to S45).

Previous task assignment scenarios should be able to compile or execute at any time using programming techniques such as system calls.

In addition, since it is impossible to identify all relevant modules from the early stage of development, there is a possibility that modules can be deleted or added during the development process. However, the procedure for this is similar to that of the initial stage. Task assignment scenario for this can use the previous scenario as it is.

As described above, by applying the multi-task configuration method in the V5 system according to the present invention, it is possible to test a variety of multi-task structure scenarios by comparing the optimal performance value of each task structure scenario to the appropriate task for the corresponding V5 system It provides the technical effect of selecting the operating environment.

Claims (5)

Identifying a related module and defining module characteristics defining a corresponding module identifier; A second step of defining a queue identifier of the transmitting module based on the module characteristics defined in the first step, determining a task allocation scenario, and defining a queue identifier of the receiving task; A third step of defining a module entry function, a task function and a message transmission function when the queue identifier of the reception task is defined through the second step; A fourth step of implementing a related function and performing a test when an additional implementation is required; And And a fifth process of checking whether it is necessary to apply an additional task allocation scenario and proceeding to the second process if necessary. The method of claim 1, The first process includes identifying a relevant module for the module characteristic definition step; And defining a corresponding module identifier in the related module identified in the above step. The method of claim 1, The second process includes selecting and defining a need for defining a queue identifier of a transmitting module for defining a queue identifier; After determining whether a task allocation scenario is required, determining the scenario and defining a queue identifier of a receiving task. The method of claim 1, The third process includes selecting and defining a necessity for defining a module entry function for the module entry / task / message transmission function definition step; Selecting and defining a need for a task function definition; And Selecting and defining a need for a message sending function definition. On a V5 system, Identifying a related module and defining module characteristics defining a corresponding module identifier; A second step of defining a queue identifier of the transmitting module based on the module characteristics defined in the first step, determining a task allocation scenario, and defining a queue identifier of the receiving task; A third step of defining a module entry function, a task function and a message transmission function when the queue identifier of the reception task is defined through the second step; A fourth step of implementing a related function and performing a test when an additional implementation is required; And A computer-readable recording medium having recorded thereon a program for realizing a multi-task configuration method comprising a fifth step of checking whether an additional task assignment scenario needs to be applied and proceeding to the second step if necessary.