Service Specification Description Method for AdvancedIntelligent Network

Mitsuhiro Okamoto and Yoshihiro Niitsu

NTT Information Sharing Platform Laboratories, NTT Corporation, Musashino, 180-8585 Japan

SUMMARY

The communication service software (SLP) whichrealizes the communication service in advanced IN is usu-ally generated automatically through a description of theservice specification in a diagram format in the servicegeneration environment (SCE). This paper considers sucha description of the service specification in diagram formatfor SLP generation, and proposes a method of servicespecification description which allows easier description, iseasier to understand, and has greater descriptive capabilitythan the conventional description method. A widely usedconventional description is the method proposed in ITU-T,in which the descriptive elements (having the role of icons)correspond one-to-one to the service-independent buildingblocks (SIBs). It sometimes happens, however, that the SIBas a functional unit is too large, degrading the reusabilityand understandability of the service specification. In con-trast, the proposed description method is based on theinformation sequence diagram previously proposed by theauthors, and extends the descriptive capability by addingdescriptive elements so that the service specification ofadvanced IN can be described. The proposed descriptionmethod was evaluated by nonexpert examinees, and it wasverified that the description is easy and understandable. Theproposed description method is also applied to SLP descrip-tion of many commercial services, and it is verified that thenecessary descriptive capability is provided. © 2003Wiley Periodicals, Inc. Electron Comm Jpn Pt 1, 87(2):17–27, 2004; Published online in Wiley InterScience(www.interscience.wiley.com). DOI 10.1002/ecja.10162

Key words: advanced IN; SCE; SLP; SIB; commu-nication service specification description.

1. Introduction

In order to provide sophisticated and diversified net-work services quickly and economically, there have beenresearch and development efforts on the advanced intelli-gent network (advanced IN) [1]. The communication serv-ice in an advanced IN is realized by constructing programswhich describe the connection logic, called service logicprograms, SLPs, which are executed on the service controlnode (service control point, SCP). The service creationenvironment (SCE) is necessary as an environment to sup-port the efficient construction of the SLP.

The general framework in the SCE is that the servicespecification in diagram format is described on a general-purpose computer display, and an SLP generation tool isprovided so that the SLP can be generated automatically.For this purpose, one of the important items of investigationis the description of the service specification in diagramformat, as the interface to the service developer for SLPgeneration.

The description by service-independent buildingblocks (SIBs) [2] proposed by ITU-T is widely used as themethod of description with diagram format for SLP genera-tion (called the service specification below). In this descrip-tion of the SIBs, a method is widely used in which aone-to-one correspondence is established between the SIBsand the descriptive elements of the diagram format (repre-sented by icons), and the relations among icons (SIB chain)are described in tree form or with SDL (Refs. 3–5, for

© 2003 Wiley Periodicals, Inc.

Electronics and Communications in Japan, Part 1, Vol. 87, No. 2, 2004Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J86-B, No. 3, March 2003, pp. 344–352

17

example). This method is a description which is easy andunderstandable so long as the processing of the SLP isconsidered.

On the other hand, problems have been pointed outin the description of the processing of the basic calls (basiccall process, BCP) and the addition/modification of theSIBs in the actual service description [6, 7]. In particular, ithas been found to be difficult in the present descriptionmethod for a nonexpert to generate an SLP without knowl-edge concerning the detailed control mechanism in thenetwork or knowledge of the programming language.

Consequently, this paper proposes a descriptionmethod for service specifications in the advanced IN thatcan be utilized by a nonexpert, assuming the developmentof the actual commercial service. First the features of theservice specification description are pointed out, togetherwith the problems found so far. Then, a description methodfor the service specification which is highly understandableis proposed in which the whole service, including theprocessing of the BCP, can be described as a flow. Theconstruction of descriptive elements with high reusabilityto be utilized in the proposed description method is pre-sented.

The detailed implementation is based on the informa-tion sequence diagram that has been proposed by theauthors [8]. A method is proposed in which the descriptiveability is enhanced by adding descriptive elements. Then,the evaluation of the proposed description method for theservice specification is presented, together with the results.For feasibility testing, a service specification descriptionsystem was constructed in order to support the servicespecification description. The constructed system was ap-plied to the development of an SLP in a real commercialservice, and the range and power of the description wereexamined. The ease of description was investigated withnonexpert service developers as the subjects.

2. Service Specification Description inAdvanced IN

This section discusses the features and the accompa-nying requirements in the service specification descriptionin the advanced IN.

2.1. Specification description by nonexperts

It is expected in the advanced IN that diversifiedservice development will proceed in parallel fashion. Thus,a wide range of nonexpert service developers who do nothave knowledge of the detailed control mechanism in thenetwork or of the programming language must be included.

[Requirement 1] The description method should be rich inunderstandability considering use by nonexperts.

2.2. Processing description of advanced INservice

Figure 1 is an example of representation in terms ofSIBs for a service control model in the advanced IN, asviewed from the SLP. When the service is started, the BCPfirst starts the processing, and the processing shifts to theSLP at a certain point. This point is called the point ofinitiation (POI). The SLP starts the processing from thispoint. If necessary, the processing is again shifted to theBCP, and the BCP restarts the processing from the indicatedpoint. This point for the BCP is called the point of return(POR). In case of further need, the above procedure isiterated.

Thus, the framework of the advanced IN is defined asfollows:

• SLP processing [SIB connection (chain) in Fig. 1]• Shift of processing between BCP and SLP (defi-

nition of POI and POR)

The processing by the SLP is the processing of each SIBand the processing between SIBs (global service logic,GSL).

[Requirement 2] The BCP unit should be included in thespecification description, from the viewpoint that the entireservice specification should be described.

2.3. Contents of SLP description

The contents of the SLP description are broadlydivided as follows:

• Processing inside SCP• Signal transmission between SCP and other nodes

[Requirement 3] In the representation of the contents ofSLP processing, the above items should be described as awhole.

Fig. 1. Service control model for advanced IN.

18

2.4. Descriptive element with high reusability

Usually, the addition or modification of descriptiveelements for the SLP description implies development ofan SCE, preventing the quick and economical provision ofa diversity of services, which is one of the purposes ofadvanced IN.

[Requirement 4] The descriptive elements should be asversatile as possible.

3. Method of Service SpecificationDescription

3.1. Problems in the conventional approach

As was discussed in Section 1, the main stream inservice specification description in the advanced IN is themethod based on SIBs. However, there exist the followingproblems from the viewpoint of the requirements describedin Section 2.

[Problem 1] The whole flow of the service cannot berepresented (viewpoints of requirements 1 and 2).

Assuming description by a nonexpert, the only partthat can be described easily is the connection between SIBs(SIB chain). It is impossible to describe explicitly BCPunits or the shift of processing between the BCP and SLP(the BCP is represented as an SIB) [6]. Even if the descrip-tion is possible, the state transition diagram is used in thedescription, which requires highly developed design skillin the service developer. Furthermore, it is difficult todescribe the SIB chain and BCP unit (state transition dia-gram) as a flow of the whole service. Thus, it is difficult tounderstand the relation between the contents of the descrip-tion and the service operation as seen by the user.

[Problem 2] The signals between nodes and the inter-nal processing of the SCP cannot be described at the sametime (viewpoint of requirement 3).

The descriptions by Message Sequence Chart (MSC)[9] formats are suited to the signals between nodes, and thedescription by SDL format is suited to the internal process-ing of the SCP. Each of these offers a description with highunderstandability, but the descriptions cannot be combinedfor representation as a single diagram format. The SCPinternal processing in this paper is restricted to the process-ing that appears in the application program interface (API)of the SLP.

[Problem 3] Customization of the SIBs is required foreach service (viewpoint of requirement 4).

In the standardized SIBs, the functional granularityis still too large at present. It is known that addition ormodification of SIBs is necessary in the description of theactual service [7]. Because of this property, the reusability

of the descriptive elements is low in the description methodin which the descriptive elements correspond to the stand-ardized SIBs (or SIBs following standardization). If themethod of handling the individual services by the additionor modification of SIBs is applied, which is the usualstrategy, the development cost is too high.

3.2. Proposal of a service specificationdescription method in the advanced IN

3.2.1. Principle of problem solution

The principle for solving the problems pointed out inSection 3.1 is presented below.

(1) Description of flow in the whole service(problem 1)

In order to improve the understandability of the serv-ice specification, SLP processing for SIB description andthe processing in the BCP unit are described by a commondiagram format in a single flow. By this approach, it is madeeasier for the nonexpert to image the whole service. Fur-thermore, conditional branching in the BCP unit (such asbusy or no-response of the receiving side) can be explicitlyrepresented.

(2) Combining sequence (MSC) and processingflow (SDL) descriptions (problem 2)

The two are described in a single diagram format inthe description of the SLP. For the nonexpert, it is clearerto describe the service image as seen by the caller and thecallee as an MSC between the user and the network, ratherthan to describe the SDL for the internal operation of thenetwork. Consequently, the sequence format-based de-scription method is used as the representation configurationfor specification description.

(3) Adjustment of granularity of descriptiveelements (problem 3)

When the functional granularity of the descriptiveelements is large, the reusability is lowered, and addition ormodification of the descriptive elements is required for thedevelopment of each service. It is difficult to anticipate inreal service development what processing will be requiredin the SLP. Consequently, it is not appropriate to definedescriptive elements with a large granularity from the be-ginning. Consequently, descriptive elements with smallgranularity are defined in this study.

19

3.2.2. Proposal of extended informationsequence diagram

We wish to realize a service specification descriptionfor advanced IN satisfying the above design principle.Based on the information sequence diagram [8] which waspreviously proposed by the authors, the extended informa-tion sequence diagram (extended MSC, E-MSC) with anextended description power is proposed in which new de-scriptive elements are added.

3.3. Extended information sequence diagram

3.3.1. Service specification description byinformation sequence diagram

In the information sequence diagram, the serviceprotocol between the user and the network is representedby the sequence diagram format. The format is developedso that a service developer who does not have knowledgeof the detailed processing in the network can describe theservice specification. It has the feature that the service isdescribed from the viewpoint of the user (terminal), and thedescriptive elements are represented in terms of their se-mantics. Figure 2 shows the sequence diagram proposed inRef. 8, and Table 1 shows the descriptive elements.

3.3.2. Extension of description power

The following descriptive elements and descriptivefunctions are newly added so that the description power ofthe information sequence diagram is extended and thecontents of SLP processing can be described.

(1) SLP control command

This is a descriptive element which represents theINAP operation and the internal processing of the SCFperforming data processing. The INAP operation is theexchange of processing between the SCF and other func-tional entities [such as the service switching function (SSF)and specialized resource function (SRF)]. The data process-ing includes the acquisition of date/time information andinvoice calculation.

The processing related to the transfer of control to theBCP (such as reception of the SLP processing start eventand restart of the BCP) is included. Among these com-mands, the commands appearing on the user interface, suchas guidance transmission and call release, are described inthe sequence format. The internal processing in the network(such as data processing concerning date/time and invoice)is defined as (SDL-like) descriptive elements on the timeaxis of the sequence diagram.

(2) Service data operation

The values used in the SLP, including the parametersconcerned with above item (1), are called service data.There must be descriptions for substitution, addition, sub-traction, bit operations, and string operations among theservice data. These are defined as internal processing in thenetwork, and the corresponding descriptive elements arespecified.Fig. 2. Message sequence chart.

Table 1. Descriptive elements of MSC

20

(3) Conditional branching of processing

Conditional branching can be divided into threetypes: (a) comparison of service data, (b) return value forSLP control command, and (c) input from the user. (a) isrepresented by descriptive element of service data operation(2). (b) is represented by SLP control command (1). (c) isrepresented by the descriptive elements of the informationsequence.

(4) Definition of data table

The type definition and the entity (initial value) areset for the data table. The table is defined in a table formatseparately from the sequence. There can be definitions forthe type alone (mostly for the type conversion of the re-ceived data) and definitions that extend to the domain (fortransmission data). Table 2 gives detailed examples of theadded descriptive elements.

3.4. Description examples

Figure 3 shows an example of service specificationdescription by E-MSC. The following example of servicespecification is given. The originator issues a special calland receives guidance. The SCP receives the connectiondestination and the originator attribute. Then, the connec-tion to the set destination is performed. In order to releasethe capture in due time, the SLP monitors the terminationof the call.

The following descriptive elements are newly intro-duced in the sequence diagram of Fig. 3.

(1) TDP: This is the descriptive element correspond-ing to the first POI. From this point to item (5), the PIC isprocessing by the SLP.

(2) Guidance: This explicitly appears in the userinterface, and is represented by a sequence description.

(3) HUNT (resource capture of destination subscriberand incrementation of number of simultaneous connectionsin subscriber data): Since this is closed processing in thenetwork (as seen by the user), it is represented as a descrip-tive element (icon) on the time axis of the network. Thisdescriptive element includes a branch (# in the figure)based on the return value of the control command. For eachroute corresponding to the branch condition, the screen isswitched for the description by selecting the branch condi-tion on the service specification description screen, as willbe discussed later.

(4) ValOp (substitution and comparison): This per-forms manipulation and comparison of service data. In thisexample, the element is used as a conditional branch (# inthe figure) based on a comparison between the service data.The detailed setting of the service data name and the con-dition are performed as parameters of this descriptive ele-ment.

(5) PIC: This is the descriptive element correspond-ing to POR. SLP processing is interrupted by this element.After this point, the requirement for EDP and the parame-ters to be sent to BCP are set as the parameters of thisdescriptive element.

(6) EDP: This corresponds to the second and laterPOIs. From this point to the point at which the PIC is againdefined, or to the end point of the sequence diagram,processing is performed by the SLP.

As is seen from this example, the processing in theSLP unit can be described in the same flow as the BCP.

Table 2. Example of newly added descriptive elements

21

3.5. Description of more complex callprocessing operation

For the basic call state model (BCSM) [2], withmixed origination/termination and service concurrency/in-teraction, the processing is as follows.

(1) Mixed origination/arrival of BCSM

Consider the case in which a call originated by theterminating BCSM is to be connected to the transfer sidedue to a no-answer or busy signal, and the connection to thetransfer side is controlled by the originating BCSM, result-ing in a mixed origination/terminating BCSM for a singlecall. In this case too, service control is performed as a flowin a program in the SLP, not as the collaboration of multipleSLPs.

As a consequence, the mixed originating/terminatingBCSM is described as a flow in the service specificationdescription. It is the EDP name corresponding to the POIthat indicates the mixture (such as originating side_origi-nation discard (originating BCSM), and terminatingside_no-answer (terminating BCSM). The description ofthe sequence itself is the same as when BCSM is not mixed.

(2) Service concurrency and interaction

In the present IN, the general method for resolutionof competition has not been established. Consequently,

most commercial systems have a configuration in whichconcurrency is prohibited by processing on the platformside. Thus, no interaction between non-IN calls and INcalls, or between IN calls, is generated, and the descriptionis not required to handle competition.

In the future development of service software innext-generation networks such as Open API, developmentwill be carried on independently by multiple developers,and there is a danger of concurrency and interaction. Thus,one problem in the application of the proposed specificationdescription method is to provide a method of handlingconcurrency and interaction on the platform, together withthe corresponding description method.

4. Construction of SLP GenerationEnvironment

4.1. Configuration

In order to generate an SLP that handles real com-mercial service, an SLP generation environment is con-structed by using the specification conversion system andthe specification verification system, together with the serv-ice specification description system (Fig. 4). The functionsof the systems are as follows.

Fig. 3. Example of description using proposed method.

22

(1) Service specification description system

Considering the standpoint of the service specifica-tion description, a sequence input editor is provided be-tween the user and the network. The editor provides supportfor input, such as complementation of the input value, andverifying and correlation between conditions set.

(2) Service conversion system

Starting from the input service specification of thediagram format, the descriptions are successively converteduntil the final execution format SLP is reached. This is notsimply conversion of specifications, but includes the auto-matic complementation function for service-independentquasi-normal procedures (such as the call release protocolfor discard by the user in the intermediate stage or in caseof a reception error), and the function for default valuesetting for the service data in the SLP [10]. Optimization ofthe output immediately before the SLP software (reductionof redundant routes and required memory) is also per-formed.

(3) Specification verification system

This system detects syntactic and logical errors in theinput service specification. As regards syntactic error, infi-nite loops in sequences, etc., are detected. As regards logicalerror, parameter errors and state transition errors in theINAP interface specification between the SCF and SSF aredetected. The former is performed in the service specifica-tion system, and the latter is performed in the serviceconversion system.

4.2. Construction of service specificationdescription system

In order to evaluate the feasibility of the proposedservice specification description method, the authors con-structed a service specification description system on ageneral-purpose computer. The newly added descriptiveelements are shown by using icons and arrows in thesequence diagram. By double clicking with the mouse, thesetting window is opened, and the parameters of eachdescriptive element can be set. Parameter setting is madeeasy for the service developer by providing various buttonsand menus.

5. Utility Evaluation of ServiceSpecification Description Method

Using the proposed service specification descriptionmethod, the service specification of a currently availablecommercial service is described, and the SLP is con-structed. In the following, the observations in the course ofSLP development are presented as examples, and a quali-tative evaluation is made as to whether the requirements aresatisfied. A comparison is also made with the existinggeneral-purpose SDL tools that support the SDL descrip-tion.

5.1. Utility evaluation in SLP developmentprocess

5.1.1. Object service of description

Using the proposed description method, approxi-mately 40 different SLPs have now been developed, and

Fig. 4. SLP creation environment.

Fig. 5. Service specification description system.

23

some are already being used in providing commercial serv-ices. Some are modifications of SLPs corresponding tofunction addition in the commercial service. Table 3 out-lines the functions realized by SLPs. Most of the con-structed SLPs contain more than one function, as shown inthe table.

5.1.2. Solution of problems

We next consider whether the problems discussed inSection 3.1 have been solved.

(1) Description of flow of overall service (problem 1)

In all SLPs that have been developed, the BCP unitand SLP processing unit can be described in a sequence, asshown in the descriptive example in Section 3.4.

(2) Simultaneous description of signals betweennodes and internal processing of SCPs(problem 2)

For services in commercial use, all processing neededin defining SLPs can be described in a sequence. It has beenverified that the description of advanced IN service inITU-T recommendation (25 CS-1 and 16 CS-2) is possible.

(3) Reusability of descriptive elements (problem 3)

For 11 SLPs composing a communication service,the number of reuses of descriptive elements is shown inTable 4. The number of descriptive elements depending onthe SLPs is smaller, and reuse can be achieved withoutmodifying the descriptive elements. All SLPs can be con-

structed by using only E-MSC and the functions defined inthe data table. A nonexpert with no experience in using theSLP programming language (C language) could constructan SLP.

5.2. Comparison to existing SDL tools

Consider the case in which the service specificationis described by SDL, using a general-purpose commercialtool to support SDL (called the SDL description below).The description by the proposed method is called the E-MSC description below. Due to differences in the interfaceto be described, the following differences occur in terms ofease of description.

(1) Knowledge required for input

In the SDL description, knowledge concerning thestate transitions in SLP processing is required. In the E-MSC description, in contrast, no explicit knowledge isrequired. As regards the description of the BCP unit, itsoperation is described in E-MSC in terms of the operationsequence, which is transparent to the user. Consequently,no knowledge concerning the state transition in the BCPunit is necessary. It is only necessary that the service devel-oper retain the event name corresponding to the POI, suchas “originating side_origination termination,” as knowl-edge at input.

(2) Understandability of entire specification

In SDL description, the description is applied to eachstate by using general-purpose descriptive elements (suchas input, output, and decision). But in sequence description,the entire service is described by using descriptive elementscorresponding to SDL control commands. This is moreunderstandable to the nonexpert.

Table 3. Functions of created SLPs

Table 4. Reuse of descriptive elements

24

(3) Number of input errors

In SDL description, input is mostly in text form,which is relatively close to the programming language. Butin E-MSC description, the item to be set by menus andbuttons (such as the setting of the service data) is specifiedbeforehand by using the GUI, which will reduce inputerrors.

Thus, E-MSC is suited to use by nonexperts, since itis specialized for advanced IN. We see that, when a nonex-pert uses E-MSC description, the productivity of specifica-tion description is improved by approximately 50%compared to the use of SDL description. On the other hand,SDL description is suited to the expert who must handle awide range of description objects.

6. Evaluation of User Interface in ServiceSpecification Description System

As criterion of ease of description, the user interfacein the service specification description system is evaluated.

6.1. Evaluation items

An evaluation of the service specification descriptionsystem is made from the viewpoint of the skill of a noviceuser. The operation time and the number of operation errorsare examined in the evaluation. A general evaluation of theuser interface is performed on the basis of general-purposeuser interface guidelines [11], and it is verified that noproblems exist.

6.2. Evaluation and discussion

The evaluation was made by two subjects. One of thesubjects (developer A) was able to use multiwindow appli-cations to some extent but had no knowledge at all ofcommunication services. The other (developer B) was anexpert service developer experienced in using the proposedtool.

(1) Operation time

The specification is input by the proposed descriptionmethod, using the tool, the operation manual, and thespecification booklet (description of input contents for sam-ple specification). The time required until the input iscompleted is measured. The number of operation errors andthe content of error are recorded. Two different specifica-tions are used for the descriptions. One is simple (specifi-cation 1) and the other is complex (specification 2, with 2.5times as many input items as specification 1).

We see in the case of developer A, who is a novice inthe use of the tool, that the operation time approaches thatof developer B after three iterations of the operation (Fig.6). It is also noted that the manual reference time decreasesrapidly after the first operation. In other words, a userinterface that the novice can quickly become familiar withand operate has been realized.

(2) Number of operation errors

Analyzing the reasons for the errors in operation, wefind that most are simple mistakes (such as typing errors)and errors in Japanese input (such as Japanese conversionmistakes). In particular, Japanese input errors almost en-tirely disappeared with the progress of the evaluation pro-cedure and the improvement of the evaluator’s skill,indicating that this is not a serious problem.

Fig. 6. Reduction of operating time.

25

Errors due to the user interface of the tool were alsodetected, but such errors decreased with improvement ofskill in the use of the tool. The rate of occurrence alsodecreased, and this kind of error will not be a problem inoperation. Figure 7 shows the change in the number ofoperation errors per input item. There is no error in thedescribed specification itself.

7. Conclusions

The purpose of the investigation reported here was torealize service specification description for an advanced INby a nonexpert. Problems inherent to advanced IN havebeen pointed out, and the service specification descriptionmethod has been proposed in order to handle problems inwhich the descriptive capability of the information se-quence diagram is extended. The service specification de-scription system which was developed to support thedescription is also reported.

Evaluation of the proposed service specification de-scription method shows that the indicated problems weresolved. As was intended by the authors, the system can beused by the nonexpert service developer, and can be appliedto SLP development for commercial services. The evalu-ation of the user interface in the service specification de-scription system indicates that use of the system is also easyfor beginners.

Problems for the future are as follows:

• Easier addition or modification of descriptive ele-ments;

• Development of an improved specification de-scription system which provides more intelligentinput support by collaboration, with a conversionfunction and a verification function.

REFERENCES

1. Yuba H, Sato K, Imagawa H, Suzuki T, Tanaka T. Anew advanced IN node technique. NTT R&D1996;45:559–568.

2. ITU-T Recommendations Q.1200 series, 1998.3. Genette M. Service creation in practice. ICIN’94, p

129–133.4. Takagi K. Service creation and test environment for

intelligent network. ICIN’96, p 188–193.5. Welsch T, Wietgrefe H, Jobmann K. An environment

for the design and test of IN-services. IN’98.6. Rieken R. IN service creation—How to make the

service independent building block concept fly.ISS’95, A7.3, 1995.

7. Ito A, Ogino N, Nakao K, Wakahara K. Evaluation ofthe power of IN service generation technique thatapplies IN CS-1 SIB. Tech Rep IEICE 1994;SSE94-121.

8. Mizuno O, Niitsu Y. A design method for communi-cation service specifications using message sequencediagram input. Trans IEICE 1991;J74-B-I:1042–1055.

9. ITU-T Recommendations Z.120, 1999.10. Sakai H, Takami K, Niitsu Y, Hirano M. A method for

communications service software generation in ad-vanced IN. Trans IEICE 1999;J82-B:886–897.

11. Kato S, Horie K, Ogawa K, Kimura S. Checklist forHI design and evaluation of its usefulness. Trans InfProcess Soc 1995;36(1).

Fig. 7. Reduction of error rate.

26

AUTHORS (from left to right)

Mitsuhiro Okamoto (member) graduated from the Department of Electrical Engineering of Osaka Prefectural Universityin 1987, completed the M.E. program in 1989, and joined NTT. He was engaged in development of service generationenvironment for advanced IN, specification description, and specification verification. He is now a chief researcher at NTTInformation Sharing Platform Laboratories. He is a member of the Information Processing Society and IEEE.

Yoshihiro Niitsu (member) graduated from the Department of Electrical Engineering of Tohoku University in 1976,completed the M.E. program in 1978, and joined NTT. He was engaged in development of communication network architecture,advanced HMI, link/packet composition network control methods, prototyping systems for communications service, specifica-tion description/verification, and service generation environment for advanced IN. He has been with Shibaura Institute ofTechnology since 2003, and is a professor on the Faculty of System Engineering. He holds a Ph.D. degree, and is a seniormember of IEEE and a member of the Information Processing Society.

27