Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Architecture for Customer Based Provisioning for Multiple Telecom Services

IP.com Disclosure Number: IPCOM000016001D
Original Publication Date: 2002-Aug-18
Included in the Prior Art Database: 2003-Jun-21
Document File: 1 page(s) / 52K

Publishing Venue

IBM

Abstract

Telecom systems base their designs off of a service-based model. Service based models mean that the user signs up for DSL, Voice, and ISDN as a service. Customers are generated through a service request. This means that customer data is not created until the user signs up for an initial service. Also, the service based model makes it difficult to market various telecom services to a user, and connect unique services through a common thread, the user. This means, if a person orders DSL service, the information needed to receive this service might be very different from Voice services. Creating one service object to contain both services would be a nightmare. DSL requires different information than voice. Basing the design off of a customer centric model keeps most of the common pieces based in the customer, and it allows new services to be added in the future with ease. If a customer is interested in service that is not available, the customer data can be kept. When the service becomes available, the customer data already exist. This means that the service can be initiated or marketed to the customer. As new services become available, then the vendor can check to see who is not a recipient of the service and market to them. The customer object is a unique object compared to common models where the customer data is part of the service object. Allowing for the customer to be its own object also reduces record duplication; therefore, increasing efficiency. In our solution, the customer is disjoined from the service in its own object. This is not done in service-based models where the information is stored in the service object. By separating the customer object in this way, new services with different back end requirements can be added with ease. This model also allows us to obtain customer information without creating a new service request. The loop, dslam port, virtual circuit, and cpe are unique to the DSL Service. If a voice services was added, it would not contain any of this information. The voice service would contain route, circuit, etc. But both services share the same customer and same customer information. 1

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 67% of the total text.

Page 1 of 1

Architecture for Customer Based Provisioning for Multiple Telecom Services

      Telecom systems base their designs off of a service-based model. Service based models mean that the user signs up for DSL, Voice, and ISDN as a service. Customers are generated through a service request. This means that customer data is not created until the user signs up for an initial service. Also, the service based model makes it difficult to market various telecom services to a user, and connect unique services through a common thread, the user. This means, if a person orders DSL service, the information needed to receive this service might be very different from Voice services. Creating one service object to contain both services would be a nightmare. DSL requires different information than voice. Basing the design off of a customer centric model keeps most of the common pieces based in the customer, and it allows new services to be added in the future with ease.

    If a customer is interested in service that is not available, the customer data can be kept. When the service becomes available, the customer data already exist. This means that the service can be initiated or marketed to the customer. As new services become available, then the vendor can check to see who is not a recipient of the service and market to them. The customer object is a unique object compared to common models where the customer data is part of the service object. Allowing for the customer to be its own object al...