tmf-tina-collab-feb99 - UCL Computer Science

Download Report

Transcript tmf-tina-collab-feb99 - UCL Computer Science

TMF/TINA-C Liaison &
Collaboration with FlowThru
Dave Lewis
FlowThru Technical Co-ordinator
Department of Computer Science
University College London
[email protected]
Outline
• Introduce TINA-C & ACTS project FlowThru
• Review draft TMF/TINA-C liaison agreement
• Review further FlowThru/TMF collaboration
possibilities
TINA Scope and Mission
• TINA defines an all-encompassing open distributed
software architecture for future telecommunication
systems:
– Rapid introduction of new advanced services
– Integrated Management of the services and supporting
infrastructure (network, computing equipment)
• Service intelligence lies completely “outside” the network
• Uses object-oriented specification and design principles
• Long-term architecture integrating connection control, IN
and TMN and through Open Distributed Processing (ODP)
principles:
– Portability, interoperability, reusability
The TINA Consortium (TINA-C)
• Created in 1992 by telecom operators, telecom
suppliers and computer vendors
• Core Team (~30 researchers) was co-located at
Bellcore, U.S. - different model to ITU-T and IETF
standardisation
• Work continues through “workgroups”
• Various auxiliary projects world-wide are
complementing, enhancing and validating the TINA
architecture and specs through design, implementation
and demonstration
TINA-C Members
 Telecom operators
AT&T
Bellcore
BNR
BT
Cable & Wireless
Deutsche Telecom
Eurescom
France Telecom
KDD
Korea Telecom
Telenor
NTT
KPN
Portugal Telecom
Stentor
Sprint
Telecom Italia
Tele Danmark
Telefonica
Telia Research
Telstra
MCI
CSELT
Swiss PTT Telecom
 Telecom Vendors
Alcatel Telecom
Ericsson / Ellemtel
Fujitsu
GPT
Hitachi
NEC
Nokia
Northern Telecom
OKI
Siemens
 Computer - IT vendors
 DEC
HP
IBM
Isis Distributed Systems
IONA Technologies
Samsung
Stratus Computer
SUN Microsystems
Unisys
TMF/TINA: The Major
Differences
• TMF addresses only mgmt, TINA has mostly focussed
on service and network control
• TMF covers general business processes, TINA focuses
on automated DPE-based interactions
• TMF aims at technology integration, TINA assumes DPE
• TMF is member driven, addressing wide range of
current services, TINA aimed at broadband, multimedia
services
• TMF focussed on process interactions and interface
agreements, TINA more architecture and component
driven
TMF/TINA Liaison
• Aim: to avoid duplication and misalignment and take
advantage of each other’s results where appropriate
• Suggested Work Items:
– Business Model mapping: TMF processes to TINA roles
– TINA to benefit from TMF experience in move to UML (currently
OMT+ IDL/ODL)
– Component Engineering: TMF ACT may benefit from TINA
experience in component-based modelling
– Specific TINA solutions may aid TMF working groups:
subscription mgmt for order handling, broadband config mgmt
– OMG’s TINA-based Session Control/Subscription Mgmt RFP
• FlowThru is using experience from integrating TINA and
TMF models to facilitate the drafting of the liaison
agreement.
TMF Business Process to TINA
Business Role Mapping
Broker
Sales
Order Handling
Rating and
Discounting
Bkr
Bkr
Bkr
Retailer
Bkr
Sales
Order Handling
Problem Handling
Customer QoS
Management
Invoicing/
Collection
Service Planning/
Development
Service
Configuration
Service Problem
Resolution
Service Quality
Management
Rating and
Discounting
Bkr
RtR
3Pty
Ret
3rd Party Service Provider
Consumer
Service Planning/
Development
Customer
TCon
TCon
ConS
Service
Configuration
Service Problem
Resolution
Network TCon
Provisioning
Network Inventory
Management
Service Quality
Management
Network Data
Management
ConS
3Pty
Connectivity Provider
CSLN
Network Planning/
Development
Network
Provisioning
Network Inventory
Management
Rating and
Discounting
Network Maintenance
& Restoration
Network Data
Management
LNFed
Example: Multi-Domain Trouble
Ticketting
User/Customer
Domain
RetailerDomain
Connectivity Problem
Reported by Customer
Service Problem
Reported by Customer
QoS Degradation
Reported by Customer
QoS Degradation
Reported by Customer
Service User
Connectivity Problem
Detected by Provider
3rd Party
Service
Provider
Service Problem
Service Quality Detected by Provider
Manager
Srv.
Problem
Service
Quality
Manager
Service Problem
Reported by Customer
Service Problem
Detected by Provider
discount
SLA violation detected
by Provider
discount
SLA violation detected
by Provider
Account Manager
Request Bill with
SLA Violation Discount
Request Bill with
SLA Violation Discount
Account Manager
Example: Business Model
Mapping
Retailer
Sales
Order Handling
Problem Handling
Customer QoS
Management
Invoicing/
Collection
Service Planning/
Development
Service
Configuration
Service Problem
Resolution
Service Quality
Management
Rating and
Discounting
RtR
3Pty
Ret
3rd Party Service Provider
Consumer
Service Planning/
Development
Customer
TCon
TCon
ConS
Service
Configuration
Service Problem
Resolution
Network
Provisioning
Network Inventory
Management
Service Quality
Management
Network Data
Management
ConS
3Pty
Connectivity Provider
CSLN
Network Planning/
Development
Network
Provisioning
Network Inventory
Management
Rating and
Discounting
Network Maintenance
& Restoration
Network Data
Management
LNFed
FlowThru Overview
• EU funded- started Mar’98, ends Feb’00
• Partners:
– Waterford Institute of Technology(IRL), STS(UK),
AlgoSystems(GR), GMD-Fokus(DE), TCD (IRL),
UHC (DK), Alcatel Bell (BE), UCL (UK), Surrey
University (UK), Alcatel Corporate Research (FR)
• Input from:
– Previous ACTS projects implementing advanced
(often-TINA based) management systems
– EURESCOM: methodology, trouble ticketting
– Standards from TINA, TMF, ITU-T, OMG
FlowThru Goals
• To provide validated Guidelines on how to build
management system from Reusable Components, that
satisfy Business Process requirements
• Disseminate results to industry via Guidelines:
– Development Methodology: UML, OOSE, use cases, facades
– Component Integration Technology: CORBA Components,
Workflow, technology gateways
• Integrate existing components from ACTS projects and
demonstrate working integrated management systems
– Similar to catalyst projects built from research implementations
– Separate demonstrators for fulfilment, assurance and
accounting
FlowThru Development
Methodology
• Promote use of general OO techniques and UML for
management system and component development
• Approach is:
– Business modelling through responsibility modelling, use
cases and activity diagrams
– Component modelling based on facades which traceably
packages requirements, analysis and design models
– Use OOSE Analysis Model to trace use cases to detailed
design
– Published component facades on web using paradigm Plus
and customer scripts
Business Process Modelling
Customer Interface
Management
Order
Handling
Service
Configuration
Network
Provisioning
Network Planning and
Development
Network Inventory
Management
Accept Order for ATM
Service
Place Order
[Credit check fail]
Order Failed
[Credit check OK]
Create Customer
Account
Determine Location of
Customer Site(s)
Locate NAP
[network access point in place]
Determine CoS to be
used at each site
Determine available
CoS
Activate Network
Access Points
[network access point not in place]
Install NE hardware
and lines to NAP
Determine the users to
use each CoS at each
site
Activate CoS user
groups
Update network usage
predictions
Authorise users to use
service
[VP network capacity inadequate]
Update network
topology
[physical network
capacity
adequate]
[physical network
capacity
adequate]
Order Complete
Reconfigure VP network
Install trunk NE
hardware and lines
Tracing Use Cases via Analysis
Model
Create a
customer
account
Terminate a
customer
account
*
CA if
1..*
PA if
Provider
Administrator
account
mgmt
Customer
Administrator
*
accounting if
*
customer
Accounting
Management
Conventional Component
Modelling
Requirement
s Capture
Component
framework
Requirement
s Analysis
Requirement
s
model
trace
Analysis
model
part of
Component
Design
Design
model
trace
exports
i/f
exports
Software
i/f
Design
model
Implementatio
n
trace
Software
Testing
Deploy
Component Modelling with
Facades
Component
Use case
model
Analysis
model
Requirement
s Capture
exports
i/f
Requirement
s Analysis
exports
Requirement
s
model
trace
Analysis
model
i/f
Design
Design
model
trace
exports
i/f
exports
Software
i/f
Design
model
Implementatio
n
trace
Software
facade
Testing
Deploy
Further TMF/TINA/FlowThru
Collaborations
• Applying ACT requirements to CORBA
Components, Workflow, EJB TINA
• Design Assurance:
– Facades and requirements tracability
– Using XML with UML, using XML for CIF
– XML DTD for propagating GDMO model, also
IDL, ODL, SDL?
• Management of IP QoS: SLAs, billing etc
• Management of CORBAised IN based on
TINA models