A Formal Specification and A Formal Specification and Verification of TINA Verification of TINA

Architecture Service with The Architecture Service with The Accounting Management Accounting Management

ModuleModule

Abderrahim SekkakiAbderrahim Sekkaki1,21,2, Carlos Becker Westphall, Carlos Becker Westphall22, , Ivanise Volpato De SouzaIvanise Volpato De Souza22, Leila Liliane Rossi, Leila Liliane Rossi22

11Departement de Mathématiques et d’Informatique. Faculté des sciences – Ain Chock. Departement de Mathématiques et d’Informatique. Faculté des sciences – Ain Chock. Université Hassan II, Casablanca, MarocUniversité Hassan II, Casablanca, Maroc

22Network and Management Laboratory. Post-Graduate Program in Computer Science. Network and Management Laboratory. Post-Graduate Program in Computer Science. Technological Center. Federal University of Santa Catarina. Florianopolis, BrazilTechnological Center. Federal University of Santa Catarina. Florianopolis, Brazil

GRES Décembre 2001 Marrakech MarocGRES Décembre 2001 Marrakech Maroc

IndexIndex

1. Introduction1. Introduction

2. TINA Overview2. TINA Overview

3. Informal description of the TINA service 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Modulearchitecture with the AcctMgmtCtxt Module

4. TINA Accounting Management Architecture 4. TINA Accounting Management Architecture and Componentsand Components

5. Conclusion and Future Works5. Conclusion and Future Works

6. Most Important References6. Most Important References

1. Introduction1. Introduction TINA is a comprehensive architecture for multi-TINA is a comprehensive architecture for multi-

service networks that will help multimedia service networks that will help multimedia communications and give access to information communications and give access to information for business and private consumers.for business and private consumers.

TINA is based in a Distributed Processing TINA is based in a Distributed Processing Environment (DPE) and CORBA as infrastructure.Environment (DPE) and CORBA as infrastructure.

The service is carried out as distributed The service is carried out as distributed applications and provided within a distributed applications and provided within a distributed computing environment.computing environment.

TINA has defined the Network Resource Architecture (NRA) that covers the management areas of connection, configuration, fault and accounting management (FCAPS).

2.TINA Overview2.TINA Overview2.1 TINA Service Architecture2.1 TINA Service Architecture

2.TINA Overview2.TINA Overview2.2 TINA Service Management2.2 TINA Service Management

The service management is associated by four The service management is associated by four conceptual axes:conceptual axes:– Partitioning axisPartitioning axis: TINA is partitioned into three : TINA is partitioned into three

layers (service, resource and DPE).layers (service, resource and DPE).– Functional axisFunctional axis: is represented most notably by : is represented most notably by

FCAPS functions to support the FCAPS integrity of a FCAPS functions to support the FCAPS integrity of a service session;service session; constructs such as management constructs such as management context and service transaction are provided.context and service transaction are provided.

– Computational axisComputational axis: represents computational : represents computational support for management needs.support for management needs.

– Life cycle axisLife cycle axis: represents the life cycle issues, : represents the life cycle issues, including service life cycle management and user including service life cycle management and user (consumer) life cycle management.(consumer) life cycle management.

2.TINA Overview2.TINA Overview2.3 TINA Accounting Architecture2.3 TINA Accounting Architecture

TINA accounting management consists of four cycles namely: Metering, Classification, Tariffing and Billing.

It introduces a concept of Accounting Management Context (AcctMgmtCtxt) associated with Service Transaction (ST).

The purpose of AcctMgmtCtxt is to guarantee that accountability can be preserved through a set of activities of distributed objects, which constitute the service..

2.TINA Overview2.TINA Overview2.3 TINA Accounting Architecture2.3 TINA Accounting Architecture

The Service Transaction (ST) concept consists of The Service Transaction (ST) concept consists of three phases:three phases:– Set-up phaseSet-up phase: Is a phase of negotiation between the : Is a phase of negotiation between the

user and the provider (e.g. Tariff structure, etc.). The user and the provider (e.g. Tariff structure, etc.). The agreed scheme is submitted as AcctMgmtCtxt of the ST.agreed scheme is submitted as AcctMgmtCtxt of the ST.

– Execution phaseExecution phase: The service is being offered to the : The service is being offered to the user, as it was specified in the first phase. The user, as it was specified in the first phase. The description of information of the service session is description of information of the service session is specified as a part of AcctMgmtCtxt.specified as a part of AcctMgmtCtxt.

– Wrap-up phaseWrap-up phase: The service is concluded, account : The service is concluded, account record or charging information may be sent to the user record or charging information may be sent to the user at the conclusion of the transaction, if specified in at the conclusion of the transaction, if specified in AcctMgmtCtxt.AcctMgmtCtxt.

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module

Our system is constituted the basic Our system is constituted the basic components of the TINA service components of the TINA service architecture and the AcctMgmtCtxt architecture and the AcctMgmtCtxt componentcomponent

We illustrate just the interfaces We illustrate just the interfaces describing the behavior of the TINA describing the behavior of the TINA system by introducing the TINA system by introducing the TINA accounting Management accounting Management

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module 3.1 LOTOS formal specification of the 3.1 LOTOS formal specification of the modelmodel

The specification demonstrates the The specification demonstrates the behavior between the user domain behavior between the user domain and the provider domain through and the provider domain through the Ret Reference Point which is the Ret Reference Point which is separated in access and use.separated in access and use.

The access part was totally The access part was totally specified while the use part only the specified while the use part only the accounting service was specified.accounting service was specified.

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module 3.1 LOTOS formal specification of the 3.1 LOTOS formal specification of the modelmodel

Specification1sSpecification1s[req,initial1,providerinitial,initial2,userinvite,providerauthen[req,initial1,providerinitial,initial2,userinvite,providerauthenticate,initial3,userinitial,providernamedacticate,initial3,userinitial,providernamedaccess,setup,useraccess,access1,accountingpull1,accountingpull2,access2,accountingpull3,access3,subscriberinfoncess,setup,useraccess,access1,accountingpull1,accountingpull2,access2,accountingpull3,access3,subscriberinfonotify,subscribernotify,providerpasbreq,accountingpushmanagement1,accountingpushmanagement2,accountingpotify,subscribernotify,providerpasbreq,accountingpushmanagement1,accountingpushmanagement2,accountingpush1,accountingpush2,accountingpushmanagement3,accountingpush3,accountingpush4,accountingpushmanagush1,accountingpush2,accountingpushmanagement3,accountingpush3,accountingpush4,accountingpushmanagement4,accountingpush5,accountingpushmanagement5,accountingpush6,execution,wrapup1,wrapup2]:noexitement4,accountingpush5,accountingpushmanagement5,accountingpush6,execution,wrapup1,wrapup2]:noexit

  behaviourbehaviour

  1s[. . .]1s[. . .]

  wherewhere

process 1s[. . .]:noexit:=process 1s[. . .]:noexit:=req;req;

(i;initial1;providerinitial;initial2;userinvite;providerauthenticate;initial3;userinitial;providernamedaccess;setup;us(i;initial1;providerinitial;initial2;userinvite;providerauthenticate;initial3;userinitial;providernamedaccess;setup;useraccess;access1;accountingpull1;accountingpull2;access2;accountingpull3;access3;1s[. . .]eraccess;access1;accountingpull1;accountingpull2;access2;accountingpull3;access3;1s[. . .]

[]i;account[. . .][]i;account[. . .] ))

wherewhere  process account[. . .]:noexit:=process account[. . .]:noexit:=

req;req;(i;subscriberinfonotify;subscribernotify;providerpasbreq;accountingpushmanagement1;accountingpushmanagem(i;subscriberinfonotify;subscribernotify;providerpasbreq;accountingpushmanagement1;accountingpushmanagement2;accountingpush1;accountingpush2;accountingpushmanagement3;accountingpush3;accountingpush4;accouent2;accountingpush1;accountingpush2;accountingpushmanagement3;accountingpush3;accountingpush4;accountingpushmanagement4;accountingpush5;accountingpushmanagement5;accountingpush6;execution;wrapup1;wntingpushmanagement4;accountingpush5;accountingpushmanagement5;accountingpush6;execution;wrapup1;wrapup2;account[. . .]rapup2;account[. . .]

[]i; 1s[. . .][]i; 1s[. . .] ))endprocendprocendprocendproc

endspecendspec

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module 3.1 LOTOS formal specification of the 3.1 LOTOS formal specification of the modelmodel

In the protocols specification , two In the protocols specification , two processes are detailed : access and processes are detailed : access and account processes.account processes.

In the process access the user In the process access the user authentication is performed authentication is performed allowing it to request services.allowing it to request services.

The process account provides the The process account provides the control and the accounting of the control and the accounting of the service used.service used.

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module 3.1 LOTOS formal specification of the 3.1 LOTOS formal specification of the modelmodelspecification 1p [req,initial1, providerinitial, initial2, userinvite, providerauthenticate, initial3, userinitial, providernamedaccess, specification 1p [req,initial1, providerinitial, initial2, userinvite, providerauthenticate, initial3, userinitial, providernamedaccess,

setup, useraccess, access1, accountingpull1, accountingpull2, access2, accountingpull3, access3, subscriberinfonotify, setup, useraccess, access1, accountingpull1, accountingpull2, access2, accountingpull3, access3, subscriberinfonotify, subscribernotify, providerpasbreq, accountingpushmanagement1, accountingpushmanagement2, accountingpush1, subscribernotify, providerpasbreq, accountingpushmanagement1, accountingpushmanagement2, accountingpush1, accountingpush2, accountingpushmanagement3, accountingpush3, accountingpush4, accountingpushmanagement4, accountingpush2, accountingpushmanagement3, accountingpush3, accountingpush4, accountingpushmanagement4, accountingpush5, accountingpushmanagement5, accountingpush6, execution, wrapup1, wrapup2] : noexitaccountingpush5, accountingpushmanagement5, accountingpush6, execution, wrapup1, wrapup2] : noexit

  behaviour behaviour 1p[. . .]1p[. . .]  wherewhere  process 1p[. . .]:noexit:=process 1p[. . .]:noexit:= access [. . .]access [. . .]

>> >> account [. . .]account [. . .]

endprocendproc process access [. . .]:exit:=process access [. . .]:exit:=req;(i;initial1; providerinitial; initial2; userinvite; providerauthenticate; initial3; userinitial; providernamedaccess; setup; req;(i;initial1; providerinitial; initial2; userinvite; providerauthenticate; initial3; userinitial; providernamedaccess; setup;

useraccess; access1;accountingpull1; accountingpull2; access2; accountingpull3; access3;acesso [. . .]useraccess; access1;accountingpull1; accountingpull2; access2; accountingpull3; access3;acesso [. . .] []i;exit []i;exit ) )

endprocendproc  process account[. . .]:noexit:= process account[. . .]:noexit:= req;req;

(i;subscriberinfonotify;subscribernotify;providerpasbreq;accountingpushmanagement1;accountingpushmanagement2;acc(i;subscriberinfonotify;subscribernotify;providerpasbreq;accountingpushmanagement1;accountingpushmanagement2;accountingpush1;accountingpush2;accountingpushmanagement3;accountingpush3;accountingpush4;accountingpushmanagountingpush1;accountingpush2;accountingpushmanagement3;accountingpush3;accountingpush4;accountingpushmanagement4;accountingpush5;accountingpushmanagement5;accountingpush6;execution;wrapup1;wrapup2;account[. . .]ement4;accountingpush5;accountingpushmanagement5;accountingpush6;execution;wrapup1;wrapup2;account[. . .]

[]i;1p[. . .][]i;1p[. . .]))endprocendprocendspecendspec

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module 3.2 Verification of the model 3.2 Verification of the model

The verification is the formal test The verification is the formal test that the specification satisfies the that the specification satisfies the desirable propreties using rigorous desirable propreties using rigorous mathematical methodsmathematical methods

To validate the formal specification To validate the formal specification we used the Encalyptus tool that we used the Encalyptus tool that integrates CADP and Aldèbaran.integrates CADP and Aldèbaran.

3. Informal description of the TINA 3. Informal description of the TINA service architecture with the service architecture with the AcctMgmtCtxt ModuleAcctMgmtCtxt Module 3.2 Verification of the model 3.2 Verification of the model

4. TINA Accounting 4. TINA Accounting Management Architecture and Management Architecture and

ComponentsComponents4.1 Architectural Model4.1 Architectural Model

TheThe Accountable Accountable Events CollectingEvents Collecting component receives, component receives, collects and collates collects and collates the accounting events the accounting events associated with the associated with the Session Component.Session Component.

The The BillingBilling component may be component may be automatically issued automatically issued at the end of a billing at the end of a billing period as negotiated period as negotiated and defined in the and defined in the customer's contract customer's contract (souscription). (souscription).

Consumer Retailer

PA

UAP

UA

SSM

CSM

CC

LNC

SUB

C.O. C.O.

C.O.

C.O.

Network Element

Metering

AccMgmtCtxt

Security

BillingTariffing

Usage Metering

4. TINA Accounting 4. TINA Accounting Management Architecture and Management Architecture and

ComponentsComponents4.1 Architectural Model4.1 Architectural Model

Tariffing– Recovery Module,Recovery Module, it it

converts the collected converts the collected accountable events to a accountable events to a charging record and stores it charging record and stores it in the charging record in the charging record database. database.

– Tariff ModuleTariff Module, It calculates , It calculates the tariff, using the charging the tariff, using the charging formula according to the formula according to the contract of subscription and contract of subscription and stores it into the billing stores it into the billing record.record.

Usage Metering– Collects and controls data Collects and controls data

acquisition concerned with acquisition concerned with the utilization of network the utilization of network resources generated by the resources generated by the LNC (Layer Network LNC (Layer Network Coordinator). Coordinator).

Consumer Retailer

PA

UAP

UA

SSM

CSM

CC

LNC

SUB

C.O. C.O.

C.O.

C.O.

Network Element

Metering

AccMgmtCtxt

Security

BillingTariffing

Usage Metering

4. TINA Accounting 4. TINA Accounting Management Architecture and Management Architecture and

ComponentsComponents4.2 Definition of the AccMgmtCtxt Components4.2 Definition of the AccMgmtCtxt Components

The model of implementation The model of implementation uses the CORBA objects on uses the CORBA objects on Visibroker 3.04. The objects Visibroker 3.04. The objects are defined as interfaces in are defined as interfaces in IDL, so that they can access IDL, so that they can access and be accessed by any other and be accessed by any other CORBA object regardless of CORBA object regardless of the programming language.the programming language.

The data-bases register the The data-bases register the events of Tariffing component events of Tariffing component while the service execution is while the service execution is carried out.carried out.

..

TariffingBilling R ecord

R ecoveryD B

D B

EventM anagem ent

SessionC om ponent

AcctM gm tC txt

5. Conclusion and Future 5. Conclusion and Future WorksWorks

– We presented in this paper an overview of We presented in this paper an overview of TINA service architecture with the TINA service architecture with the integration of the accounting management integration of the accounting management context module and their component.context module and their component.

– By showing the formal description and By showing the formal description and validation of our model through the formal validation of our model through the formal description LOTOS and using the Aldèbaran description LOTOS and using the Aldèbaran tool, we showed that the model is correct.tool, we showed that the model is correct.

– This model becomes thus,’basic model’ for This model becomes thus,’basic model’ for the specification and the implementation of the specification and the implementation of the others management functions in future the others management functions in future works. works.

5. Conclusion and Future 5. Conclusion and Future Works Works

– We described the accounting We described the accounting components in IDL, their roles and components in IDL, their roles and their interactions to accomplish the their interactions to accomplish the accounting functionalityaccounting functionality

– This work provides an overview of the TINA This work provides an overview of the TINA concept specifying the accounting concept specifying the accounting management context. We described management context. We described accounting features, requirements, and accounting features, requirements, and some accounting issues.some accounting issues.

5. Conclusion and Future 5. Conclusion and Future WorksWorks

– We proposed the accounting management We proposed the accounting management architecture specifying an architectural architecture specifying an architectural model that contains specific components model that contains specific components such as AcctMgmtCtxt, Session Component, such as AcctMgmtCtxt, Session Component, etc., covering different aspects of service etc., covering different aspects of service control and managementcontrol and management

– In the future it will become necessary to implement a In the future it will become necessary to implement a model that includes, in addition to management model that includes, in addition to management accounting, the management of security, failure and accounting, the management of security, failure and performance, so that the service mode will be in real-performance, so that the service mode will be in real-time and on a level of reliability defined by time and on a level of reliability defined by international standardsinternational standards

6. Most Important 6. Most Important ReferencesReferences

Pavlou G. et al., “Issues in Realizing the TINA Network Pavlou G. et al., “Issues in Realizing the TINA Network Resource Architecture”, in: Interoperable Communication Resource Architecture”, in: Interoperable Communication Networks Journal,” Vol. 2, No. 1, March 1999.Networks Journal,” Vol. 2, No. 1, March 1999.

Kristiansen L. et al., “TINA Service Architecture 5.0”, TINA-C, Kristiansen L. et al., “TINA Service Architecture 5.0”, TINA-C, 1997.1997.

Mulder H. et al., “TINA Business Model and Reference Points”, Mulder H. et al., “TINA Business Model and Reference Points”, TINA-C, 1997.TINA-C, 1997.

Farley P. et al,. Farley P. et al,. “TINA Retailer Reference Point Specification,” “TINA Retailer Reference Point Specification,” v. 1.0, TINA-C, 1998.v. 1.0, TINA-C, 1998.

Abarca C. et al., “TINA Service Component Specification”, v. Abarca C. et al., “TINA Service Component Specification”, v. 1.0b, TINA-C, 1998.1.0b, TINA-C, 1998.

6. Most Important 6. Most Important ReferencesReferences

Kormann L. F. et al., “OSI Usage Metering Function for OSIMIS Kormann L. F. et al., “OSI Usage Metering Function for OSIMIS Management Platform”, in: Journal of Network and Systems Management Platform”, in: Journal of Network and Systems Management, Vol. 4, No. 3, 1996.Management, Vol. 4, No. 3, 1996.

Notare M. S. M. A et al, “Formal Design of a Platform for Notare M. S. M. A et al, “Formal Design of a Platform for Telecommunication Heterogeneous Network ManagementTelecommunication Heterogeneous Network Management”,”, DSOM’97 – Sydney, Oct 1997.DSOM’97 – Sydney, Oct 1997.

Sekkaki A. et al., Sekkaki A. et al., ., “Development of a Prototype Based on TINA ., “Development of a Prototype Based on TINA Accounting Management Architecture”, IEEE/IFIP International Accounting Management Architecture”, IEEE/IFIP International Symposium on Integrated Network Management. Seattle, Symposium on Integrated Network Management. Seattle, Washington, USA, 14-18 May 2001. Washington, USA, 14-18 May 2001.

Sekkaki A. et al,Sekkaki A. et al, “Development of Accounting Management “Development of Accounting Management based Service Environment in TINA, JAVA and CORBA based Service Environment in TINA, JAVA and CORBA Architectures”, International Conference on Networking. July 9-Architectures”, International Conference on Networking. July 9-13, 2001, CREF, Colmar, France. 13, 2001, CREF, Colmar, France. Springer LNCS (Lecture Notes Springer LNCS (Lecture Notes in Computer Science). in Computer Science).