Implementing Real Solutions Using the NGOSS Methodologydpnm.postech.ac.kr/papers/TMW/TMW2004-LongBeach… · · 2004-12-09Implementing Real Solutions Using the NGOSS Methodology

Implementing Real Solutions Using the Implementing Real Solutions Using the NGOSS MethodologyNGOSS Methodology

Joel J. Fleck, IIChief Architect, Hewlett-Packard

Cliff C. FaurerTechnical Director, NGOSS Program

Giuseppe CovinoProject Manager, Telecom Italia Lab

Elena BaldinoTechnical Expert, Telecom Italia Lab

Implementing Real SolutionsUsing the NGOSS Methodology:

NGOSS Lifecycle & Methodology

Joel J. Fleck, IIChief Architect, Hewlett-Packard

Why an NGOSS Lifecycle?Why an NGOSS Lifecycle?

To assure that roles, requirements, models, implementations and deployments all contribute in a holistic manner to the solution.To provide traceability throughout the lifetime of an NGOSS SolutionTo provide a documented means of utilizing, extending and enhancing the NGOSS Knowledge Base

Why an NGOSS Methodology?Why an NGOSS Methodology?

To provide a consistent, documented manner for understanding, defining, modeling, developing, integrating and deploying NGOSS Solutions

Goals of the NGOSS Lifecycle and MethodologyGoals of the NGOSS Lifecycle and Methodology

Develop an NGOSS Lifecycle and Methodology that:Utilizes/borrows the best parts/strengths of Zachman, RM-ODP, MDA and USDPPromotes and strongly encourages linkage between NGOSS eTOM, NGOSS SID and NGOSS ArchitectureEmphasizes “consumer” - “provider” relationship for each level of decompositionFacilitates the identification of “testing” points that can be used to test/monitor/manage the health of both NGOSS solutions under development and deployed NGOSS solutions

Service Provider Business PerspectivesService Provider Business Perspectives

AgilityCost Reduction - Profit ImprovementJoined up solutionsFlexible Service CreationMore Performing: People & SystemsAutonomic capability - policy based management

OSS Knowledge Management ChallengeOSS Knowledge Management Challenge“The challenge has been, and still is today, to rapidly find the exact knowledge artifactneeded for a given situation. As the volume of available knowledge increases, so does the difficulty of locating the correct artifact. Because of how we have structured our information- document-centric world, we are constantly engaged in this tug of war. The more voluminous our libraries get, the harder it becomes to recall anything with a high degree of precision.” Arthur J. Murray, D.Sc, J-KMCI Vol. 1 No 1

What Should an NGOSS Methodology Include?What Should an NGOSS Methodology Include?Formalized expression of Business Problem/SolutionLinkages from the Business Problem/Solution to the technical/realization models (i.e., Architectural Traceability):

Traceability from the business problem/solution through each level of decomposition & refinement (vertical traceability)Traceability from the process model to the data model to the policy model at each level (horizontal traceability)

Documented steps and guidelines for developing an NGOSS Solution using the NGOSS MethodologyCapability of being mapped onto major Architectural FrameworksUse Case drivenIterative

What Are We Borrowing?What Are We Borrowing?Zachman

Emphasis on Enterprise and Business Model

MDAMeta-ModelsBusiness (CIM) - Technology Neutral (PIM) - Technology Specific (PSM) Separation of ConcernsAbility to use a model to specify architectural artifacts (as the model changes, code is updated to reflect those changes)

RM-ODPViewpoints (particularly Computational, Engineering and Technology)Strong support for modeling distributed architectures

USDPUse Case DrivenIterative Approach

NGOSS LifecycleNGOSS Lifecycle

LogicalView

PhysicalView

Service DevelopersView

Service Providers View

ImplementationDeployment

Business System

Deployment Capabilities, Constraints & Context

Implementation Capabilities, Constraints & Context

Business Capabilities, Constraints & Context

System Capabilities,Constraints & Context

CorporateKnowledge

Base

NGOSSKnowledge

BaseShared

NGOSS SANRR MethodologyNGOSS SANRR Methodology

1. SCOPE : Define Solution Boundary including Solution Mission Goals, and High-Level Use Cases

2. ANALYZE: Document existing (legacy) and desired environments with detailed Use Cases, Process Maps, Activities and Policy Lists

3. NORMALIZE: Map current view onto common vocabulary to achieve a “single unified model” (using SID)

4. RATIONALIZE: Examine normalized model for needed changes (Gap Analysis, Replication Analysis, Conflict Analysis). Terminate when no more changes needed

5. RECTIFY: Modify, delete or add functionality (Contractually Specified) to resolve needed changes identified in Step 4. Once complete, cycle to Step 3.

Iterate withSANRR

Iterate withSANRR

Roles in NGOSS LifecycleRoles in NGOSS LifecycleCreate Solution High Level Use CaseCreate Solution High Level Use Case

Business System


Solution Manager (1)Subscriber (2)Market Analyst (2)Account Manager (2)

Customer (3)

{

Business Solution Definition Use Case

{Roles

Supporting Use Cases

Roles

Solution Designer (1)Information Modeler (1)System Architect (1)Service Architect (1)

{

System Solution Design Specification Use Case

{Supporting Use Cases

Solution Integrator (1)Service Component Builder (1)Service Implementer (1)Data Modeler (1)Network Administrator (1)

Information Modeler(2)System Architect (2)Service Architect (2)

{

Solution Implementation Use Case

{Roles


Solution Delivery Manager (1)Subscriber (1)System Manager (1)Service Operator (1)Network Operator (1)

Data Modeler (2)

{

Solution Deployment/Operation Use Case

{Roles


Notes: - Bold Italic Roles indicate accountability- Following numbers (n) indicate Primary, Secondary or Tertiary Actors- Interactions between Accountability Roles for each View follow

indicated doubled headed black arrows- Use Cases that span one or more Views are constructed as a coordinating Use Case that orchestrates the use of non-spanning Use Cases

CorporateKnowledge

Base

NGOSSKnowledge

Base

Shared

Iterate withSANRR

Iterate withSANRR Iterate with

SANRR

Iterate withSANRR

Iterate withSANRR

Iterate withSANRRIterate with

SANRR

Iterate withSANRR

LogicalView

PhysicalView

Service DevelopersView

Service Providers View


Business System

Deployment Capabilities, Constraints & Context

Implementation Capabilities, Constraints & Context

Business Capabilities, Constraints & Context

System Capabilities,Constraints & Context

Iterate withSANRR

Iterate withSANRR

NGOSS Lifecycle with Iteration UsingNGOSS Lifecycle with Iteration UsingNGOSS SANNR MethodologyNGOSS SANNR Methodology

CorporateKnowledge

Base

NGOSSKnowledge

BaseShared


NGOSS Information Models

Cliff C. FaurerTechnical Director – NGOSS Program

NGOSS Lean Operator: StrategyNGOSS Lean Operator: Strategy

Goal, Context, Capabilities & Constraints

A Blueprint for ChangeUnderstand the current behaviorsCommunicate the desired behaviorsActionable plan to implement the necessary changesContinuous monitoring and management to maintain desired course

Policies and Processes drive behavior

A View on a Business ChallengeA View on a Business Challenge

Soft Constraints

Derivations

Hard Constraints

Enterprise Context

Business requires fluid adaptability at all levels:• Process & Policy: rules are “applied” to govern the expected behavior (both at

people and systems level) to achieve the desired outcome – reach the goal!

• People: effective collaboration, decision making and accountability throughout the solution lifecycle: business – system – implementation – deployment

• Technologies: requires technology neutral architecture framework capable of integrating and being implemented by any technologies

CapabilitiesCapabilities

Goal

Beyond Beyond SoASoA: NGOSS System Architecture …: NGOSS System Architecture …Problem Understanding – Use Case

Capture and communicate stakeholder understanding of the challengeDescription of what should happen

Solution Specification – ContractCapture and communicate results of working the challenge into a solution statementDescription of how the challenge will be metUnit of service specification

Component – unit of service deployment

Goal

Rules

Mgmt Info

NGOSS Business Contract

NGOSS Use CaseName:Scope:Level:Audience:Primary Actor(s):Supporting Actor(s):Primary Goal(s):Stakeholder Goal(s):

Policies:Processes:Pre-conditions:Post-conditions:Triggers:Main scenario:Extension scenarios:

Process

LimitationsCapabilities

Activity

Roles

Specification

Context

Obligations

Benefits

Party Role

OAMConcepts

Mgmt Method

Enterprise Management

Strategy, Infrastructure & Product Operations

Fulfillment Assurance BillingProductLifecycleManagement

InfrastructureLifecycleManagement

OperationsSupport &Readiness

Customer Relationship Management

Service Management & Operations

Resource Management & Operations

Supplier/Partner Relationship Management

Strategy & Commit

Marketing & Offer Management

Service Development & Management

Resource Development & Management

Supply Chain Development & Management

(Application, Computing and Network)(Application, Computing and Network)

Customer

Enterprise EffectivenessManagement

Knowledge & ResearchManagement

Enterprise RiskManagement

Strategic & EnterprisePlanning

Financial & AssetManagement

Stakeholder & ExternalRelations Management

Human ResourcesManagement

eTOM v4.0Enhanced Telecom Operations MapEnhanced Telecom Operations Map®®

SID Framework SID Framework –– Aligned with eTOMAligned with eTOMStrategy, Infrastructure & Product

Operations

Enterprise

CustomerMarket/Sales Product

Service

Supplier/Partner

Enterprise Common Business Entities

Resource

NGOSS SID NGOSS SID –– ProductProduct--ServiceService--ResourceResource

ProductSpecification

0..n 0..10..n

involvedProductSpecs

0..1

ProductOffering0..n0..1 0..n

involvedProductOfferings

0..1

1

0..n

1

0..n

madeAvailableAs

Product1 0..n1 0..nofferedAs

Resource

ProductItem1 1..n1 1..nhasProductItems

1

0..n

1

0..n

resourceRealizedAs

CustomerFacingService

1

0..n

1

0..n

serviceRealizedAs

ResourceFacingService

0..n0..n 0..n0..n

cfRequiresRFServices

PhysicalResource

1

1..n

1

1..n

physicalResourcesHostRFS

LogicalResource

1

1..n

1

1..nlogicalResourcesForRFS

0..n0..n 0..n0..n

pResourceSupportsLResource

Service

NGOSS SID NGOSS SID –– Top of Generalization TreeTop of Generalization Tree

RootEntityuserDefinedName : Stringdescription : String

Specification CharacteristicRoleEntity PartyIdentification ManagementDomain

PolicyLocation

NGOSSS SID NGOSSS SID –– RolesRoles

Employee

ServiceProvider

ValueNetworkRole

VendorIntermediary

Individual

PartyRole

Organization

Party0..n1 0..n1

HasPartyRoles

0..1

0..n

0..1

0..nHasPeopleOrOrgs

ProductOfferingPartyRole

EnterprisePartyRole

Customer

Roles in NGOSS LifecycleRoles in NGOSS LifecycleCreate Solution High Level Use CaseCreate Solution High Level Use Case

Business System


Solution Manager (1)Subscriber (2)Market Analyst (2)Account Manager (2)

Customer (3)

{

Business Solution Definition Use Case

{Roles


Roles

Solution Designer (1)Information Modeler (1)System Architect (1)Service Architect (1)

{

System Solution Design Specification Use Case

{Supporting Use Cases

Solution Integrator (1)Service Component Builder (1)Service Implementer (1)Data Modeler (1)Network Administrator (1)

Information Modeler(2)System Architect (2)Service Architect (2)

Solution Implementation Use Case

{Roles


Service Delivery Manager (1)Subscriber (1)System Manager (1)Service Operator (1)Network Operator (1)

Data Modeler (2)

{

Solution Deployment/Operation Use Case

{Roles


Notes: - Bold Italic Roles indicate accountability- Following numbers (n) indicate Primary, Secondary or Tertiary Actors- Interactions between Accountability Roles for each View follow

indicated doubled headed black arrows- Use Cases that span one or more Views are constructed as a coordinating Use Case that orchestrates the use of non-spanning Use Cases

CorporateKnowledge

Base

NGOSSKnowledge

Base

Shared

Iterate withSANRR

Iterate withSANRR Iterate with

SANRR

Iterate withSANRR

Iterate withSANRR

Iterate withSANRRIterate with

SANRR

Iterate withSANRR

{

Example: Order Handling Business Use CaseExample: Order Handling Business Use Case

OrderHandling

Customer

ReceiveOrderRequest

«include» ValidateOrderRequest

AnalyzeOrderFeasibility

ProcessOrder

AuthorizeCredit

IsssueOrder

TrackOrder

ManageJeopardy

CompleteOrder

AmendOrder

CancelOrder

«include»

«include»

«include»

«include»

«include»

«include» «include» «include»

OrderProcessing

CustomerInterface

Pre-Order Processing

InternalEngineering

NOC

Sales

SupplierPartner

«extend» «extend»

Courtesy PEA and mdapce

Example: Business Flow for Product OrderingExample: Business Flow for Product Ordering

MarketProduct &Customer

Resource(Application,Computingand Network)

Supplier/Partner

Service

Customerrequests SPoffering

Customer InterfaceManagement Customer Interface

ManagementCustomer InterfaceManagement

Selling

CustomerRequestReceived

CustomerOrderConfirmed

S/P RequisitionManagement

ExternalComponentRequested

ResourceProvisioning



ServiceConfiguration &Activation

ResourceAllocated


External Supplier required

ResourceAllocationrequested


InternalWork OrderInitiated


Internal ResourceProvisioningCompleted

ResourceActivationrequested

OrderHandling

Customer OrderInitiated

Design Requested

Order Handling

Design Completed

Design Confirmationby Engineeringrequested

OrderHandling

InternalService OrderInitiated

DesignAccepted byCustomer

Retention &Loyalty

PriorityRequested

Priority Advised

External OrderIssued

Service Detailsfor Assurance

Service Detailsfor Billing


ResourceActivated

S/P Requisition Management

External ResourceActivated

Order Handling

Service Activated

Completion advisedto Customer

OrderCompletionNotification

ExternalResourceActivated

MarketProduct &Customer

Resource(Application,Computingand Network)

Supplier/Partner

Service

Customerrequests SPoffering

Customer InterfaceManagement Customer Interface

ManagementCustomer InterfaceManagement

Selling

CustomerRequestReceived

CustomerOrderConfirmed

S/P RequisitionManagement

ExternalComponentRequested





ResourceAllocated


External Supplier required

ResourceAllocationrequested


InternalWork OrderInitiated


Internal ResourceProvisioningCompleted

ResourceActivationrequested

OrderHandling

Customer OrderInitiated

Design Requested

Order Handling

Design Completed

Design Confirmationby Engineeringrequested

OrderHandling

InternalService OrderInitiated

DesignAccepted byCustomer

Retention &Loyalty

PriorityRequested

Priority Advised

External OrderIssued

Service Detailsfor Assurance

Service Detailsfor Billing


ResourceActivated

S/P Requisition Management

External ResourceActivated

Order Handling

Service Activated

Completion advisedto Customer

OrderCompletionNotification

ExternalResourceActivated

Example: Business Contract governing ProductExample: Business Contract governing Product

0..n 0..n

GovernsBusinessServiceDetails

GovernsBusinessResourceDetails

LogicalResourceResourceFacingService

0..1 1..n0..1 1..n

LogicalResourcesImplementRFS

CustomerFacingService

0..n1..n 0..n1..n

CFServiceRequiresRFServices

PhysicalResource

0..n 0..n

PResourceSupportsLResource

0..1 1..n0..1 1..n

PhysicalResourcesHostRFS

Service Resource

Product

0..1

0..n

0..1

0..n

ProductHasCustomerFacingServices

0..1

0..n

0..1

0..n

ProductHasPhysicalResources

BusinessContract

0..n

0..n

0..n

0..nGovernsBusinessServices 0..n

0..n

0..n

0..n

GovernsBusinessResources

0..n

0..n

0..n

0..n

GovernsBusinessProduct

GovernsBusinessProductDetails

Example: Partial Contract Hierarchy for Example: Partial Contract Hierarchy for UpsellUpsell

Customer Contract

Product Contract

PhysicalResourceContract

CustomerFacingServiceContract


ResourceFacingServiceContract






View of the data from Market, Sales and Order points-of-view

Translated into ProductSpecs, ProductOfferings, and ProductsMay require new

device to use enhanced features Gold Service


VoIP VPN

Traffic Identification

Traffic Conditioning

Route Forwarding

Device OS

Import Policies

Export Policies

Implementation

SystemBusiness

Deployment

NGOSS Lifecycle and MethodologyNGOSS Lifecycle and Methodologyaddress all stakeholder viewsaddress all stakeholder views

Knowledge Base

Design Standards & Process

• System Architecture• Policy Model• Information Model• System Contract

Operational Environment

• Component Instance• Policy Instance• Data Instance• Contract Instance

Implementation Choices

• Components• Policy Spec.• Data Model• Contract Implementation

Repository of Reusable Best

Practices – process, policy, capabilities,

etc.

Business Scope, Goals, Missions

• Business Process• Business Policies• Business View Info Model• Business Contract

No big bang project, must use tools to make knowledge visible and manageable through each solution project iteration


DSL Fulfillment Example

Giuseppe CovinoProject Manager, Telecom Italia Labs

The context of the project The context of the project –– model requirementmodel requirement

The research project is investigating practical usage of TMF guidelines and artifacts along with evolution of OSS platforms beyond bus based architectures.Data model is a key factor: to mitigate the pain of OSS integration, it must:

cover all SP domainsbe extensible and “tailorable”be powerful and/but not too complexaim to broad diffusion.

SID was the choice

Case study: DSL fulfillmentCase study: DSL fulfillment

SOHO customer requests of rich DSL offerings delivery, comprising

broadband Internet connectivityLAN configuration at their premisesmailboxes

Order handling and network activation phases are considered (Billing for next phase).

Multi-vendor and multi-technology network equipments involved:

ADSL DSLAM Alcatel, Marconi, SiemensATM switch Cisco 86xx, 88xx; Element Manager CWMB-RAS Cisco 6400, 7500

SID Domains and our Data ModelSID Domains and our Data Model

Resource

Customer

*

CustomerAccount

CustomerFacingServiceTI ResourceFacingServiceTI

CustomerOrderTI CustomerOrderItemTI

ProductSpecificationTIProductTI ProductOfferingTI

NetworkElementTI

PhysicalPortTI

CardTIEquipmentHolderTI

PhysicalLinkTI

TTPointTICTPointTI

1,*

*

1

1

*1,*

*

1,*

1,*

1

0,1

*0,1

*0,1

*0,1

*

1

1,* 1,*

0,1*

**

Customer1,*

*

*

1

*

* *1

0,1

*

0,1

1

* * *

* *

* * *

*

Product

Service

LogicalPortTI Connection

2..*

1Trail

1

2..*

CustomerCustomer and and ProductProduct domaindomain modelmodel

CustomerAccount

+ «AttrReq» id : CDMidType+ «AttrReq» name : CDMstring+ «Attr» accountType : CDMstring+ «Attr» accountStatus : CDMstring

CustomerOrder

+ «Attr» assignedPriority : CDMinteger+ «Attr» assignedResponsibilityDate : CDMdatetime

CustomerOrderTI

BusinessInteraction

+ «AttrReq» id : CDMidType+ «AttrReq» interactionDate : CDMdatetime+ «Attr» description : CDMstring+ «AttrReq» interactionDateComplete : CDMdatetime+ «AttrReq» interactionStatus : CDMstring

*

BusinessInteractionItem

+ «AttrReq» quantity : CDMinteger+ «Attr» action : CDMstring1..*

*

Request

*

1..*

CustomerOrderItemTI

+ «AttrReq» id : CDMidType+ «AttrReq» detailInfo : CDMstring

Product

+ «AttrReq» name : CDMstring+ «Attr» description : CDMstring+ «Attr» productStatus : CDMstring+ «AttrReq» productSerialNumber : CDMinteger+ «Attr» validFor : CDMdatetime

ProductOffering

+ «AttrReq» id : CDMidType+ «AttrReq» name : CDMstring+ «Attr» description : CDMstring+ «Attr» validFor : CDMdatetime+ «Attr» status : CDMstring

ProductOfferingTI

+ «AttrReq» type : CDMstring+ «Attr» parameterValue : CDMstring+ «Attr» maxQuantity : CDMinteger

ProductTI

*

*

*

1

*

1

0..1

*

ProductSpecification

+ «AttrReq» name : CDMstring+ «AttrReq» description : CDMstring+ «AttrReq» productNumber : CDMstring+ «Attr» brand : CDMstring- «Attr» validFor : CDMdatetime- «Attr» lifecycleStatus : CDMinteger

ProductSpecificationTI

+ «AttrReq» id : CDMidType+ «AttrReq» characteristic : CDMstring

*

*

*

0..1

Customer

+ «AttrReq» id : CDMidType+ «Attr» customerStatus : CDMstring+ «Attr» customerRank : CDMstring

1..*

*

Mr. Dante

Mr. Dante Account

Mr. Dante ADSL SMART 8 order

ADSL SMART 8

ADSL SMART 8

LAN

Mailbox

Broadband Connectivity

ResourceResource domaindomain model model –– PhysicalPhysical ResourceResource

EquipmentHolder

+ «AttrReq» holderStatus : CDMboolean

Equipment

+ «AttrReq» equipmentStatus : CDMboolean

*

0..1Card

- «Attr» isConfigurablePhysically : CDMboolean- «Attr» daughterCardInstallStatus : CDMinteger- «Attr» isMotherBoard : CDMboolean- «Attr» slotLayout : CDMstring- «Attr» slotsRequired : CDMinteger+ «Attr» hardwareVersion : CDMstring

*

PhysicalPort

+ «AttrReq» portNumber : CDMinteger- «AttrReq» typeOfPPort : CDMinteger- «Attr» vendorPortName : CDMstring

*

0..1

ManagedHardware

- «Attr» additionalInfo : CDMstring- «Attr» administrativeState : CDMinteger- «Attr» physicalAlarmReportingEnabled : CDMboolean = true- «Attr» physicalAlarmStatus : CDMinteger = 0- «Attr» coolingRequirements : CDMstring- «Attr» hardwarePurpose : CDMinteger

PhysicalContainer

- «Attr» hotSwappable : CDMboolean- «Attr» removable : CDMboolean- «Attr» replaceable : CDMboolean

PhysicalResource

- «Attr» manufactureDate : CDMdatetime- «Attr» otherIdentifier : CDMstring- «Attr» powerState : CDMstring- «Attr» serialNumber : CDMstring+ «Attr» versionNumber : CDMstring

PhysicalDevice

- «Attr» backplaneIndependent : CDMboolean- «Attr» backplaneNumber : CDMinteger- «Attr» configurationOrder : CDMstring- «Attr» deviceGroupID : CDMstring- «Attr» isComposite : CDMboolean- «Attr» canMixPower : CDMboolean = false

NetworkElementTI

+ «AttrReq» id : CDMidType+ «Attr» softwareVersion : CDMstring+ «AttrReq» ipAddress : CDMstring+ «Attr» hostName : CDMstring+ «Attr» password1 : CDMstring+ «Attr» password2 : CDMstring+ «AttrReq» name : CDMstring+ «Attr» description : CDMstring+ «AttrReq» username : CDMstring

PhysicalPortTI

+ «AttrReq» id : CDMidType+ «Attr» name : CDMstring+ «Attr» description : CDMstring+ «AttrReq» adminStatus : CDMinteger+ «AttrReq» operStatus : CDMinteger+ «AttrReq» index : CDMinteger

CardTI

+ «AttrReq» id : CDMidType+ «Attr» name : CDMstring+ «Attr» description : CDMstring+ «AttrReq» type : CDMstring

EquipmentHolderTI

+ «AttrReq» id : CDMidType+ «AttrReq» position : CDMinteger+ «Attr» description : CDMstring

PhysicalLinkTI

+ «AttrReq» description : CDMstring+ «AttrReq» id : CDMidType+ «AttrReq» busId : CDMstring

*

0..1

Hardware

- «Attr» depth : CDMstring- «Attr» height : CDMstring- «Attr» measurementUnits : CDMinteger- «Attr» weight : CDMstring- «Attr» weightUnits : CDMinteger- «Attr» width : CDMstring

*

*

0..1

*

0..1

Mr. Dante’s CO

Mr. Dante’s port

PortsPorts, CTP, , CTP, connectionsconnections and and linkslinks

CPEc.p.

transport & IP network

CTPCTP

o.f.

connection

link

Mr. Dante’s port

TTP trail (end-to-end)D

SLAM

ResourceResource domaindomain model model –– LogicalLogical ResourceResource

LogicalResource

- «Attr» serviceState : CDMstring

ManagedTransmissionEntity

- «Attr» additionalInfo : CDMstring+ «AttrReq» mteAdministrativeState : CDMinteger- «Attr» logicalAlarmReportingEnabled : CDMboolean = true- «Attr» logicalAlarmStatus : CDMinteger = 0- «Attr» isMTEOperational : CDMboolean- «Attr» typeOfMTE : CDMinteger+ «Attr» operationalState : CDMinteger

TerminationPoint

+ «AttrReq» direction : CDMinteger+ «Attr» vendorTPName : CDMstring

ConnectionTerminationPoint

- «Attr» mappingMode : CDMinteger- «Attr» ctpState : CDMinteger- «Attr» supportedConnectionRates : CDMinteger

*

TrailTerminationPoint

TTPointTI

+ «AttrReq» id : CDMidType+ «AttrReq» label1 : CDMinteger+ «AttrReq» label2 : CDMinteger

CTPointTI

+ «AttrReq» id : CDMidType+ «AttrReq» label1 : CDMinteger+ «AttrReq» label2 : CDMinteger

LogicalPortTI

+ «AttrReq» id : CDMidType+ «AttrReq» portType : CDMstring+ «AttrReq» customerInterfaceNumber : CDMstring+ «AttrReq» isInterfaceEnabled : CDMboolean

*

0..1

*

0..1

PhysicalPortTI

+ «AttrReq» id : CDMidType+ «Attr» name : CDMstring+ «Attr» description : CDMstring+ «AttrReq» adminStatus : CDMinteger+ «AttrReq» operStatus : CDMinteger+ «AttrReq» index : CDMinteger

*

*

*

Pipe

+ «AttrReq» isUniDirectional : CDMboolean+ «Attr» operatingLayerRate : CDMstring

Connection Trail

1..* 0..1

12..*

Lesson learntLesson learnt

SID wider coverage is very good for an ISP, ranging from customer accounts to termination points of connections.SID/UML extensibility has revealed essential to fitspecific SP needs.Network technology specific models have beenplugged in (e.g. ATM).The interconnected models are somehow complex: learning curve a bit slow, so...More guidebooks are welcome to understandsemantics of entities and where to extend.

Thank You!Thank You!

For more information visit:For more information visit:tmforum.orgtmforum.org

Implementing Real Solutions Using the NGOSS Methodologydpnm.postech.ac.kr/papers/TMW/TMW2004-LongBeach… · · 2004-12-09Implementing Real Solutions Using the NGOSS Methodology

Documents