| Oracle® Communications Data Model Reference Release 11.3.1 Part Number E28440-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Data Model Reference Release 11.3.1 Part Number E28440-03 |
|
|
PDF · Mobi · ePub |
The logical data model of the Oracle Communications Data Model defines the business entities and their relationships and provides an understanding of the business and data requirements for the Oracle Communications Data Model data warehouse.
This chapter includes the following sections:
The following describes the main entities related to some major or typical subject areas in Oracle Communications Data Model:
Note:
The entity-relationship figures of the major reference entities in those subject areas are available with the Oracle Communications Data Model IP Patch. The IP Patch includes additional documentation. To obtain the IP Patch and for the latest information about Oracle Communications Data Model patch sets, go to My Oracle Support at
https://support.oracle.com.Table 2-1 lists the entities associated with the subject area Account Simple.
Table 2-2 lists the entities associated with the subject area Customer.
Table 2-3 lists the entities associated with the subject area Dealer.
Table 2-4 lists the entities associated with the subject area Geography.
Table 2-5 lists the entities associated with the subject area Organization Business Unit.
Table 2-6 lists the entities associated with the subject area Party.
Table 2-7 lists the entities associated with the subject area Party (Extended).
Table 2-8 lists the entities associated with the subject area Product.
Table 2-9 lists the entities associated with the subject area Product Instance.
Table 2-10 lists the entities associated with the subject area Service.
Table 2-11 lists the entities associated with the subject area Subscription.
Table 2-12 lists the entities associated with the subject area Time Calendar.
Table 2-13 lists the entities associated with the subject area Vendor.
Table 2-14 lists the entities associated with the subject area Wireless Network.
Note:
Oracle Communications Data Model also covers Wireline (PSTN) and cable type of network. Wireless Network is here taken as an example of the types of supported networks.These business areas lists contain the logical entities in the data model grouped by business area.
Note:
The notion of a business area is not strict. That is, some business areas are overlapping. Thus, a logical entity can belong to, or be needed in, several business areas. Some logical entities are not explicitly listed because they either only represent a relationship between tables, are not critically important to any business area, or are simply lookup entities. For more information, see Business Areas and Subject Areas in Oracle Communications Data Model.The following are the business area logical data model entities:
Note:
The business area figures showing complete diagrams with attributes and entities are available with the Oracle Communications Data Model IP Patch. The IP Patch includes additional documentation. To obtain the IP Patch and for the latest information about Oracle Communications Data Model patch sets, go to My Oracle Support athttps://support.oracle.com.Table 2-15 lists the logical entities for Cost.
Table 2-16 lists the logical entities for Customer Management.
Table 2-17 lists the logical entities for Marketing.
Table 2-18 lists the logical entities for Network.
Table 2-19 lists the logical entities for Partner Management.
Table 2-20 lists the logical entities for Product Management.
Table 2-21 lists the logical entities for Provisioning and Service.
Table 2-22 lists the logical entities for Revenue.
Table 2-23 through Table 2-29 list the logical data model entities, in alphabetical order.
Table 2-23 A to C Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Reference |
Methods that a customer accesses or utilizes a service. For example:
|
|
|
Reference |
Assigns ACCESS METHODs to an account. |
|
|
Lookup |
Type of relationship between two ACCESS METHODs. For example:
|
|
|
Reference |
Assignment of an ACCESS METHOD to a related ACCESS METHOD. |
|
|
Reference |
The ACCESS METHOD may be split into multiple elements for better management. Each element is a segment in the ACCESS METHOD, which represents a group of access methods. For example, for the access method for a phone number, where access method elements are:
|
|
|
Lookup |
Lookup for type of ACCESS METHOD ELEMENT. For example:
|
|
|
Reference |
How the access method binds to an equipment instance. For example:
|
|
|
Reference |
Assigns the access method to a geographic region. |
|
|
Reference |
Assigns access method to a party. |
|
|
Lookup |
Lookup for type of relationship between ACCESS METHOD and PARTY. For example:
The management type of access method party relationship specifies that an employee may be responsible for the maintenance of a group of access methods. |
|
|
Reference |
The logical network resources. For example:
|
|
|
Base |
The history of access methods that the customer brought to the operator from another telecom operator, according to the number porting scheme. |
|
|
Reference |
Segments of ACCESS METHODs defined for usage tracking. For example:
|
|
|
Reference |
The relationship between ACCESS METHOD SEGMENT and PRODUCT CAPABILITY to define which product capabilities require which access method segment. |
|
|
Reference |
Defines the relationship between a SERVICE and an ACCESS METHOD. For example, which service (gsm voice) is using which mobile number. |
|
|
Base |
The status of an ACCESS METHOD. Defines both current status and historical status. For example:
|
|
|
Lookup |
Lookup for available reasons an ACCESS METHOD may have a change in status. For example:
|
|
|
Lookup |
Lookup for available ACCESS METHOD status types and descriptions. For example:
|
|
|
Reference |
Assigns ACCESS METHOD(s) to a SUBSCRIPTION. |
|
|
Lookup |
Lookup for ACCESS METHOD type: Defines the types of methods by which a customer may use or access services or products. For example:
|
|
|
Reference |
The accessories that may be purchased from the service provider in addition to the item, product, or service. For example:
|
|
|
Reference |
The account is generated by a contract between service provider and customer. For the service provider hosting different network, including CDMA, GSM, broadband, and others, one customer may have a different account for a different network or can be unified. Once set up, a customer can use account for self service from the Web site or from a Service Provider terminal. In this case the account is normally protected by a password. |
|
|
Reference |
The type of relationship between two ACCOUNTs. For example, a corporate account has several affiliated accounts. |
|
|
Base |
Billing cycle status history for ACCOUNTs. |
|
|
Lookup |
Lookup of all the reasons for adjustments. For example:
|
|
|
Reference |
Relationship assignments between ACCOUNTs. For example, parent and child accounts. |
|
|
Lookup |
Lookup for available reasons ACCOUNTs may be related. |
|
|
Base |
Contains the list of all adjustments to any account balance. These are pure adjustments and not just additional payments or costs. An account balance adjustment is usually related to the party interaction thread. |
|
|
Lookup |
Lookup of all the types of adjustments. For example:
|
|
|
Base |
Tracks the expire date and recharge date for each “Bucket” of the prepaid balance. |
|
|
Reference |
The balance group concept allows one account to have multiple balance groups, which applies to different groups of services. For example, some special discounts, or monetary balance, can be given for wireless calls, but not for fixed line service. |
|
|
Base |
Balance history of ACCOUNT subjected to the primary currency. The balance value was classified by the balance type. For example:
|
|
|
Base |
The account balance change details, because of a specific event. For example:
|
|
|
Derived |
Daily aggregate of free minutes allowance (PPA) for ACCOUNT and PRODUCT MARKET PLAN. |
|
|
Base |
The Peer to Peer balance transfer between two ACCOUNTs. One ACCOUNT can transfer credit, including free minutes, into another ACCOUNT. |
|
|
Lookup |
Type of account balance. For example:
|
|
|
Reference |
Billing cycle status history for ACCOUNTs. |
|
|
Reference |
Billing frequency history for ACCOUNTs. |
|
|
Reference |
Specifies each billing occurrence for an ACCOUNT. A billing occurrence may be triggered by a predefined billing cycle or some other event such as account termination. In a single account billing occurrence there may be multiple invoices generated. |
|
|
Reference |
Billing period history for ACCOUNTs. |
|
|
Reference |
The business interaction role which can be assigned by a Customer Account. |
|
|
Reference |
||
|
Base |
Subtype of COST, which associates a specific incurred cost to an ACCOUNT (through an EMPLOYEE). |
|
|
Base |
Credit limit assigned to an account, subscription, or contract. |
|
|
Derived |
The summarized daily debt status for each account. |
|
|
Aggregate |
Derived from ACCOUNT DEBT DAY DRVD. The summarized monthly debt status for each CUSTOMER TYPE. |
|
|
Base |
The transaction to write off debt, and clear it out from accounts receivable. |
|
|
Lookup |
Lookup for account event types. |
|
|
Base |
Subtype of PARTY ACCOUNT ASSIGNMENT. The account management history tracks the management relationship from employee to the accounts, including account creation, through sales channel, and accounts update or termination. |
|
|
Reference |
Assigns accounts and parties to PRODUCT MARKET PLAN. |
|
|
Base |
Allocations of funds from a receipt made by a party to an account. The receipt of a single sum from a party as a credit against an outstanding balance for the provision and supply of products or services. |
|
|
Base |
The ACCOUNT BALANCE IMPACT originated from ACCOUNT PAYMENTs. |
|
|
Derived |
Daily aggregation of payments made by all customers. |
|
|
Base |
Status history of each account preferred payment method. For example:
|
|
|
Aggregate |
Collects all changes to the payment method status and the reason of the changes over time. |
|
|
Derived |
Collects the changes on payment method status. |
|
|
Lookup |
Lookup for specific status of the account payment method. For example:
|
|
|
Lookup |
Lookup for types of ACCOUNT PAYMENT METHOD STATUS. For example:
|
|
|
Aggregate |
Monthly summary of payments made by all customers. |
|
|
Base |
Defines the history of how account uses the PRODUCT MARKET PLAN. |
|
|
Reference |
The preferred invoice delivery type history for account. |
|
|
Reference |
Contains preferred payment methods for the account. |
|
|
Reference |
Records more details about the account. |
|
|
Base |
The recharge (refill) made into the customer account. |
|
|
Base |
The customer refund is the money transferred back to customer account, which is normally based on an invoice adjustment. |
|
|
Derived |
The daily summary of refund to customers and the impacts to revenue. |
|
|
Aggregate |
The monthly summary of refunds to customers and the impacts to revenue. |
|
|
Lookup |
Lookup for the reasons why a refund may occur. For example:
|
|
|
Lookup |
The type of ACCOUNT ROLEs, for example, primary account, secondary account, and so on. |
|
|
Reference |
The segments identifying distinct groupings of accounts with similar characteristics. The account segments are typically generated from the data mining analysis. |
|
|
Reference |
Assign account segment to each account. |
|
|
Reference |
Used to cluster the account. |
|
|
Derived |
Account statistics for each account. One account normally has multiple SUBSCRIPTIONs, and CONTRACTs, all values on which are summed into the account level. Any deleted or blocked accounts are also included and are deemed as Churned, regardless of whether the deletion or block was voluntary. |
|
|
Aggregate |
Account statistical information at higher level by CUSTOMER TYPE. |
|
|
Derived |
The status change information about all accounts at every month. |
|
|
Base |
The history of account status change, including activation, suspension, and so on. |
|
|
Lookup |
Lookup for account status reasons, or possible reasons a given account status has been changed. |
|
|
Lookup |
Lookup for account status types. |
|
|
Aggregate |
Account statistical information at a higher level by customer type. |
|
|
Reference |
History of subscriptions by an account. |
|
|
Lookup |
Each account to subscription relationship may have a reason associated with it. For example:
|
|
|
Lookup |
Lookup for account type. For example:
|
|
|
Lookup |
Internal Billing cycle which is used to calculate the usage amount and update the account balance for accounting GL purpose. |
|
|
Lookup |
Lookup for categories that can be associated with incurred costs. For example:
|
|
|
Reference |
Additional text can save multiple lingual notes or comments for products, parties, and other information. |
|
|
Reference |
Address details for physical or mailing address. |
|
|
Reference |
Tracks other names used by the same ADDRESS LOCATION. |
|
|
Reference |
Entity associates addresses with other addresses. Addresses can be associated in many ways. For example, one address is an alternate for another address for those locations with multiple addresses. |
|
|
Lookup |
Lookup for reasons addresses may be related. |
|
|
Lookup |
Lookup for the type of relationship between two addresses. |
|
|
Base |
Current status of an address location. For example:
|
|
|
Lookup |
Lookup for the reason for a change to the current ADDRESS STATUS. |
|
|
Lookup |
Lookup for address types. For example:
|
|
|
Reference |
Defines an advertising period. |
|
|
Reference |
Defines a quarter in an advertising calendar. |
|
|
Reference |
Defines a week in an advertising calendar. |
|
|
Reference |
Defines a year in an advertising calendar. |
|
|
Lookup |
Lookup to bin the customer into different groups according age. For example:
|
|
|
Lookup |
Defines subscriber life cycle ranges. For example:
|
|
|
Reference |
Defines a DEVICE INTERFACE that functions as an Aggregation Interface; that is, an interface on the aggregation portion of the network. The objective of this role is to enable the definition of POLICYs such that all Aggregation Interfaces in a particular Domain can receive the same common configuration commands. |
|
|
Reference |
An allowance, a number of something allowed before charging begins, for a SUBSCRIPTION. |
|
|
Reference |
The Property Address format used in USA. |
|
|
Reference |
The SIC code used in Australia and New Zealand. |
|
|
Base |
The appointment between two parties to define a future time for conducting businesses. For example:
|
|
|
Base |
Appointments assigning times for vendor or provider to deliver or provide a service. |
|
|
Lookup |
Lookup for appointment types. For example:
|
|
|
Aggregate |
The monthly summary of revenue values for ARPU calculation on CUSTOMER TYPE level. |
|
|
Derived |
The monthly summary of revenue values and revenue value components along with the subscriber base count; used to calculate the ARPU values. |
|
|
Lookup |
Average Revenue per Unit Band definitions. For example:
|
|
|
Reference |
Any tangible or intangible economic resource, owned by the operator, which may be of interest to the financial status of the operator. For example, an asset may be a network element, for example routers, switches, or a business asset like land, building, or patent, and so on. |
|
|
Base |
The valuation history of the ASSET. |
|
|
Base |
The condition history of an ASSET, as inspected by an internal employee or a contractor. This is important for vehicles or buildings. |
|
|
Base |
The financial depreciation history of a given ASSET. |
|
|
Reference |
||
|
Reference |
The history of locations of each ASSET. An ASSET may be moved among different SITEs in its life cycle. |
|
|
Lookup |
The Type of ASSET. For example:
|
|
|
Reference |
Asynchronous Transfer Mode (ATM), is a network technology based on transferring data in cells of a fixed size. The cell used with ATM is relatively small compared to that used with older technologies. In principle, the small, constant cell size allows ATM equipment to transmit video, audio, and computer data over the same network, and assure that no single type of data can dominate network traffic. ATM creates a fixed route between two points whenever data transfer begins. This differs from TCP/IP, in which messages are divided into packets and each packet can take a different route from source to destination. This difference makes it easier to track and bill data usage across an ATM network, but it makes it less adaptable to sudden surges in network traffic. |
|
|
Reference |
An Autonomous System (AS) provides a structured view of routing by segregating the system that is using routing. For example:
This segregates the system into a set of separately administered domains and each has its own independent routing policies. This is defined in RFC1771. |
|
|
Reference |
This entity represents managed entities, such as power supplies, fans, and cables, which are required for the proper operation of the Device but have a primary function that is different than the primary end-user function(s) of the Device. The difference between Auxiliary Components and other subclasses of EQUIPMENT are whether the physical object performs a function intrinsic to the main function of the Device. For example, consider a ROUTER. The routers main function is to route and forward packets. A Power Supply is an Auxiliary Component, because even though it is needed for the proper operation of the ROUTER, it does not directly help in routing and forwarding packets. A Line Card, that provides routing functionality, is a subclass of EQUIPMENT because its purpose is to route and forward packets. Similar examples exist for different types of equipment, where their criteria may be different. For example, instead of whether it routes or forwards packets, the criterion "does it carry signal" may be useful to appropriately classify components. |
|
|
Lookup |
The level of customer's loyalty, based on the LOYALTY PROGRAM and ability to contribute to the revenue of the carrier. For example:
|
|
|
Reference |
Bank information that may be used in transactions. |
|
|
Reference |
Subtype of the PAYMENT CHANNEL, which tracks various bank channels where customers can pay by direct debt method. |
|
|
Lookup |
Lookup defining reasons a customer may be banned from using a service. |
|
|
Reference |
The abstracted information about a day, which serves as a base for DAY. |
|
|
Reference |
Subtype of NETWORK ELEMENT, which lists the Base Station Controller (BSC) of the network. The Base Station Controller provides, classically, the intelligence behind the BASE TRANSCEIVER STATION (BTS)s. Typically a BSC has tens or hundreds of BTSs under its control. The BSC handles allocation of radio channels, receives measurements from the mobile phones, and controls handovers from BTS to BTS. |
|
|
Reference |
Base Transceiver Station (BTS) is the equipment which facilitates the wireless communication between User Equipment (UE) and the network. |
|
|
Derived |
Daily BER (Bit Error Rate) and FER (Frame Error Rate) statistics about the network elements. |
|
|
Aggregate |
Monthly BER (Bit Error Rate) and FER (Frame Error Rate) statistics about the network elements. Derived from BER FER ERROR RATIO DAY DRVD. |
|
|
Lookup |
Lookup to indicate the statistics value for BER (Bit Error Rate) or FER (Frame Error Rate). |
|
|
Lookup |
Documents each billing run/cycle. Typically the billing cycle is per month. Sometimes a customer may be billed at a different date inside the billing cycle. For example:
|
|
|
Lookup |
The billing frequency specifies the number of billing periods that comprise the billing cycle. |
|
|
Lookup |
Type of billing occurrence which could be classified by the trigger type. For example:
|
|
|
Lookup |
The billing period specifies the unit to be used to calculate the billing cycle (such as days or months). |
|
|
Lookup |
Lookup for category of billing status. For example:
|
|
|
Lookup |
Lookup for reasons why the NETWORK EVENT is at certain billing status. For example:
|
|
|
Lookup |
Lookup for the status type of billing result, including the reasons. For example:
|
|
|
Base |
History of all black-listed customers. |
|
|
Reference |
The brands associated with hardware (usually this applies for handsets, but also for ITEMs). |
|
|
Reference |
Bridging Protocols operate at the data link layer of the OSI model, and are used to define communications over different types of homogeneous and heterogeneous local area networks. |
|
|
Reference |
Broadband is subtype of PRODUCT service. Describes the characteristics specific to the broadband product. |
|
|
Reference |
Subtype of PRODUCT RATING PLAN applied to BROADBAND product. |
|
|
Reference |
Broadband service is subtype of SERVICE, to track the broadband services used by the user. |
|
|
Base |
The broadband network usage event, normally implemented as a period while customer is connected to the network. This is charged based on time usage. Some internet connection product might charge by data volume. |
|
|
Lookup |
Lookup for brand of client browser. For example:
|
|
|
Reference |
Version of customer browser, such as Internet Explorer 6.0, Firefox 3.6, and so on. |
|
|
Base |
A detailed product bundle usage event. A bundled network event is comprised of other Product Usage event(s), that may be either Product Bundle Usage or Product Component Usage. |
|
|
Reference |
Any business asset that may be of financial interest to the operator. For example:
Note: the equipment which is part of the network is in the entity: NETWORK ELEMENT |
|
|
Reference |
Defines month-in-half in a business calendar. |
|
|
Reference |
Defines half year in a business calendar. |
|
|
Reference |
Describes an arrangement, contract, communication, or joint activity between one or more PARTY ROLEs, Element Roles, or Customer Accounts. A Business Interaction may consist of one or more BUSINESS INTERACTION ITEMs. A BUSINESS INTERACTION ITEM may refer to a Product, Service, Element, or one of their specifications. A Business Interaction is further defined by one or more Places. One Business Interaction may reference another Business Interaction and one BUSINESS INTERACTION ITEM may reference another BUSINESS INTERACTION ITEM on the same or different Business Interaction. There are five types of Business Interactions:
|
|
|
Reference |
Defines the relationship between two BUSINESS INTERACTIONs. |
|
|
Lookup |
Interaction type such as subordinate business interaction. |
|
|
Reference |
A characteristic quality or distinctive feature of a BUSINESS INTERACTION. |
|
|
Lookup |
Type of BUSINESS INTERACTION CHARACTERISTIC. |
|
|
Reference |
A value of a BUSINESS INTERACTION CHARACTERISTIC. |
|
|
Base |
The purpose for the Business Interaction expressed in terms of a Product Type, PRODUCT MARKET PLAN, Service Type, or NETWORK ELEMENT TYPE or may refer to a Product, Service, or NETWORK ELEMENT. The detail items included in the BUSINESS INTERACTION. |
|
|
Base |
This is the actual price charged to the BUSINESS INTERACTION ITEM, despite the original list and discount price from product setting. An amount associated with a BUSINESS INTERACTION ITEM that is valued by the associated PMP Price |
|
|
Reference |
The BUSINESS INTERACTION ROLE which can be assigned to an address. For example:
|
|
|
Base |
The association between a payment and BUSINESS INTERACTION. For example, a payment for a contract or a customer order. |
|
|
Reference |
The roles which can be played by PARTY or other business interaction elements like Resource, and so on. |
|
|
Base |
The status history of a BUSINESS INTERACTION. For example:
|
|
|
Lookup |
The reason to explain why a BUSINESS INTERACTION has had a change in status. |
|
|
Lookup |
Lookup for available BUSINESS INTERACTION status types and descriptions. For example:
|
|
|
Lookup |
Type of BUSINESS INTERACTION. For example:
|
|
|
Reference |
Represents the ability to distinguish between different instances of ElementSpecifications. It represents a particular form or variety of a ElementSpecification that is different from others or from the original. The form represents differences in attributes, methods, relationships, or constraints that characterize this particular ElementSpecification, but which are not enough to warrant creating a new ElementSpecification. |
|
|
Lookup |
The legal status of the company. For example, a Public Company, Private, and so on. |
|
|
Reference |
Defines month in a business calendar. |
|
|
Reference |
Defines quarter in a business calendar. |
|
|
Reference |
Assigns job roles to a business unit within the organization. |
|
|
Reference |
Work shift associated with the Business Unit, mapped to the Employee job roles for the allocation for these shifts. |
|
|
Reference |
Defines week in a business calendar. |
|
|
Reference |
Defines year in a business calendar. |
|
|
Reference |
A container of conductors or fibres. At least two connectors are attached to a cable. |
|
|
Reference |
Subtype of EQUIPMENT INSTANCE, which collects all cable modem instances installed at customer's site connecting to the network of the Communications Service Provider. |
|
|
Reference |
Defines month-in-half in a Gregorian or Normal Calendar. |
|
|
Reference |
Defines half year in a Gregorian or Normal Calendar. |
|
|
Reference |
Defines month in a Gregorian or Normal Calendar. |
|
|
Reference |
Defines quarter in a Gregorian or Normal Calendar. |
|
|
Reference |
Defines weeks in a Gregorian or Normal Calendar. |
|
|
Reference |
Defines years in a Gregorian or Normal Calendar. |
|
|
Lookup |
Lookup for call categories. For example: Data, Fax, or Voice. |
|
|
Reference |
Defines call centers for a carrier or provider. |
|
|
Reference |
Agents of a call center. |
|
|
Lookup |
Lookup for call center agent types. For example: Employee or IVR. |
|
|
Derived |
The daily aggregate of customer call statistics from the call center. The customer calls are analyzed for the time of the call, duration of the call, subscriber or non-subscriber calling, and the call direction. |
|
|
Aggregate |
Monthly summary of customer call statistics for the call center. |
|
|
Derived |
Statistics for all the cases initiated or resolved by the call center. For example:
|
|
|
Aggregate |
Monthly summary of statistics for all the cases initiated or resolved by the call center. |
|
|
Lookup |
Lookup to further characterizes the type of cases from the call center. The case subtype helps to split a given case type into various subtypes. For example, for the case type, "Srv: Service Request", the subtype could be classified as "Package Upgrade", "Package Downgrade", "Simple Contract Renewal", or "Onsite Support". |
|
|
Lookup |
Further classifies the CALL CENTER CASE SUB TYPE. For example, for call center case type "Service Request", and call center case subtype "Technical Support", the call center case title could be:
|
|
|
Lookup |
Lookup for type of call center cases. For example:
|
|
|
Reference |
Assigns to the CALL CENTER, the languages, products, or geographical areas which the call center can serve. |
|
|
Lookup |
To indicate incoming call or outgoing call. |
|
|
Reference |
A type of phone service. The calling party can be on hold if receiving party is in a call. |
|
|
Lookup |
This is to record any other characteristics of the call, such as, 3-party call, or any user defined special type of call. |
|
|
Lookup |
Lookup for reasons why the voice carrying channel is being recycled during the call. |
|
|
Lookup |
Lookup to define how the call was routed. For example:
|
|
|
Lookup |
Lookup for service types that could be used in a call. For example:
|
|
|
Reference |
Entity represents all the possible zones associated with a combination of any sources and destinations. Those call sources or destinations classify the calls into different groups, such as local call, long distance domestic call, or internal call. Note: it is not the purpose of this entity to reproduce the A-B number mapping (this is a billing operation). This entity only represents the result of such a mapping. |
|
|
Lookup |
Lookup to classify calls into successful calls or unsuccessful due to various reasons or causes. Call success failure, along with the call direction helps in facilitating the required analysis for roaming calls. |
|
|
Lookup |
Any extra charge on the call in addition to the normal rating. |
|
|
Lookup |
Lookup for the reasons a call may be terminated. For example:
|
|
|
Lookup |
Lookup to further classify call category into call types. For example:
|
|
|
Reference |
Subtype of PRODUCT, with specific information about CALLER ID service. |
|
|
Reference |
Campaigns are the entire communication strategy for a specific marketing communications program. The marketing communications program is frequently in support of promotional events and individual promotions but can be standalone. A campaign is always associated with a MEDIA OBJECT, such as a television campaign. |
|
|
Reference |
Channel by which a CAMPAIGN is exposed to a customer. For example: News group or media company which issues newspaper, television affiliate, and so on. A piece of newspaper of a block/slot on the paper is a publication/media object. The campaign channel can be categorized by CAMPAIGN CHANNEL TYPE. |
|
|
Reference |
The assignment to define which CAMPAIGN is lunched at which CAMPAIGN CHANNEL. |
|
|
Lookup |
Lookup for campaign channel type. For example: newspaper, Television, Magazine. |
|
|
Reference |
A characteristic quality or distinctive feature of a CAMPAIGN. The characteristic can take on a discrete value, such as the number of press releases, can take on a range of values, for example the number of prospects reached is 50,000 - 100,000, or can be derived from a formula, for example, the number of brokerage house pickups = the sum of all brokerage house instance characteristics. |
|
|
Reference |
A number or text that can be assigned to a CAMPAIGN CHARACTERISTIC. |
|
|
Base |
||
|
Reference |
The customer documents provided during campaign activities. |
|
|
Reference |
The history of campaign party role about management of a CAMPAIGN. The party here can be not only the sales or marketing employee at TELCO operator, it can also be campaign partner. |
|
|
Reference |
Details regarding message broadcast or sent during a CAMPAIGN. |
|
|
Base |
Information about the creative content of the message. |
|
|
Reference |
Details about how the execution message is depicted for a CAMPAIGN. |
|
|
Lookup |
Lookup for types of campaign purposes. For example:
|
|
|
Reference |
Defines the relationship between two CAMPAIGNs. For example:
|
|
|
Lookup |
Status of CAMPAIGN. |
|
|
Reference |
The term value for a given campaign. |
|
|
Lookup |
Lookup for type of campaign. For example:
|
|
|
Derived |
The calculated detail information related to the tariff/package change of customers. For prepaid customers, usually it is impossible to track customer movement between products due to lack of customer identification. For some customers, they may change at the next "beginning of the month". |
|
|
Aggregate |
The calculated tariff or package change summary of all customers at the month level. For prepaid customers, usually it is impossible to track customer movement between products due to lack of customer identification. |
|
|
Reference |
This is an abstract base entity that is the parent for both the PHYSICAL CAPACITY and the LOGICAL CAPACITY. These entities define the minimum and maximum requirements, limits, or other variable features of another entity. |
|
|
Reference |
Represents a type of physical container that can be plugged into a SLOT. A card may represent a primary function, for example, a networking card, or an auxiliary function, for example, a memory card, that supports another card. All objects of this type are capable of carrying electrical and optical signals. A card also provides a mounting point for other types of Managed Physical Elements, such as Chips or Cards. |
|
|
Reference |
This association entity represents the semantics of the Card On Card aggregation. The Card Relationship defines an attribute that describes how the CARD is mounted on or plugged into another CARD. |
|
|
Reference |
The cell in a wireless network such as GSM, which is an area serviced by the BASE TRANSCEIVER STATION (BTS). |
|
|
Lookup |
Lookup for reasons a cell outage could occur. For example:
|
|
|
Reference |
Most cells are split into sectors or individual areas to make them more efficient and to let them to carry more calls. The cell site equipment provides each sector with its own set of channels. |
|
|
Reference |
This is where the base station radio equipment and their antennas are located. A cell site gives radio coverage to a cell. |
|
|
Base |
Subtype of COST which could apply to a CELL SITE. For example:
|
|
|
Lookup |
Lookup for type of CELL SITE. For example: the cell site type can be classified by GSM/CDMA/PHS/broadband/Pay TV. |
|
|
Derived |
The network parameters and runtime statistics captured at the cell level. |
|
|
Aggregate |
The network parameters and runtime statistics for all CELL SITEs aggregated at the month and certain geography level. |
|
|
Lookup |
Lookup for all possible cell types. For example, Macro, Micro, and Pico:
|
|
|
Reference |
Defines the relationship of the CFS Type aggregation. Specifically, it enables an application to define which set of versions of this CUSTOMER FACING SERVICE Type are appropriate for a given task. |
|
|
Lookup |
Lookup for who proposed the changes for a customer tariff change. For example:
|
|
|
Reference |
Identifies all the channels through which customers interact with the telco provider for sales or services purposes. |
|
|
Base |
Subtype of COST, which collects all costs specifically related to a given sales channel. |
|
|
Lookup |
Lookup for types of channels as defined by their functions. For example:
|
|
|
Reference |
A Chassis is a type of Secure Holder that encloses other Managed Physical Entities and provides a definable functionality in its own right, such as a desktop or a network device. For example, a router or a switch. |
|
|
Reference |
Represents the semantics of the Chassis In Rack aggregation. Defines two attributes: Position and Location, to define where the CHASSIS is located in the RACK. |
|
|
Derived |
Monthly statistics regarding each account, which acts as source material for training the Churn Predict Mining Model. |
|
|
Lookup |
Lookup for reasons an account may churn. |
|
|
Lookup |
Lookup for categories to classify the type of circuit. For example:
|
|
|
Reference |
Describes each component of each circuit. Typically a circuit will include several components. For example, a Digital Data Services circuit linking two customer sites may include three components:
There are two scenarios:
For the first scenario, where two switches are linked, the switch_id and secondary_switch_id attributes will identify the two switches. The site_id attribute will be null. If the circuit component links a switch with a customer site, then the switch_id attribute will identify the switch and the site_id attribute will identify the customer site. The secondary_switch_id attribute will be null. |
|
|
Base |
Business activities of renting some circuits to other operators, in return for a monthly, or fixed, revenue. |
|
|
Lookup |
Lookup for types of rental events. For example:
|
|
|
Base |
The traffic volume statistics over certain periods, where periods are implementation dependent but generally hourly, for each CIRCUIT COMPONENT. |
|
|
Lookup |
Lookup for type of detailed circuit types. For example: For interconnect:
For customer connection ADSL:
|
|
|
Reference |
This entity represents collections of Managed Entity objects. A Collection enables common attributes, methods, relationships, and other semantics to be applied to different types of Collections of Managed Entity objects. These can then be refined in the subclasses of Collection. |
|
|
Reference |
Subtype of a PARTY, who collects the customer debt on behalf of the operator under a financial agreement. For example:
|
|
|
Derived |
Statistics of all commissions granted to the sales agents because of the sales of products and services in the given period. |
|
|
Aggregate |
Monthly aggregation of all commissions granted to the sales agents because of the sales of products and services in the given period. |
|
|
Lookup |
Lookup for commission types that may be paid to sales representatives. For example:
|
|
|
Reference |
The service type of product, including fixed line phone call, wireless phone call, and so on. |
|
|
Reference |
A characteristic quality or distinctive feature of a COMPETITOR INTELLIGENCE. The characteristic can take on a discrete value, such as number of press releases, can take on a range of values, for example, number customers within a MARKET SEGMENT (50,000 - 100,000), or can be derived from a formula, for example, number of products offered in a MARKET SEGMENT = the number of the COMPETITOR's Product instances associated to the MARKET SEGMENT. |
|
|
Reference |
A number or text that can be assigned to a COMP INTEL CHARACTERISTIC. |
|
|
Reference |
A MARKET SEGMENT in which a COMPETITOR makes Product available. |
|
|
Reference |
A characteristic quality or distinctive feature of a COMPETITOR PRODUCT CORRELATION. The characteristic can be take on a discrete value, such as geographic disbursement (central, national, cascading). The characteristic can take on a range of values, (for example, Competitor Product Offering revenue of $500,000 - $1,000,000), or can be derived from a formula (for example, number of MARKET SEGMENTs in correlation = number of MARKET SEGMENTs related to this correlation). |
|
|
Reference |
Assign the COMP PROD CRRL CHARACTERISTIC to the related COMPETITOR INTELLIGENCE characteristic. |
|
|
Reference |
Defines the relationship between two COMP PROD CRRL CHARACTERISTICs. |
|
|
Reference |
A number or text that can be assigned to a COMP PROD CRRL CHARACTERISTIC. |
|
|
Reference |
A classification of a COMPETITOR, such as by size, product lines offered, and so on. |
|
|
Reference |
A PARTY that offers PRODUCT similar to the enterprise's PRODUCT in a MARKET SEGMENT. |
|
|
Reference |
Facts gathered about a COMPETITOR's plans and activities. These facts perform COMPETITOR SWOT analysis to better understand a COMPETITOR. |
|
|
Reference |
The PARTY who developed the COMPETITOR INTELLIGENCE. |
|
|
Reference |
A MARKET SEGMENT served by a COMPETITOR. |
|
|
Reference |
Specifies a Strength, Weakness, Opportunity, or Threat in a MARKET SEGMENT served by a COMPETITOR. |
|
|
Reference |
A comparison or relationship between an enterprise-s PRODUCT with a COMPETITORs' Product. Information about the correlation may include MARKET SEGMENTs, Product Offering life cycle stage, Jurisdiction, or definable COMP PROD CRRL CHARACTERISTICs. |
|
|
Reference |
General (non-MARKET SEGMENT specific) Strength, Weakness, Opportunity, or Threat when compared to a COMPETITOR. |
|
|
Reference |
A classification of a COMPETITOR, such as by size, product lines offered, and so forth. |
|
|
Reference |
Complex Address describes the internal address for a complex (for GEOGRAPHY COMPLEX). For example, the internal road, building number, and so on. |
|
|
Reference |
Part of a Product Price representing a single element of the price. |
|
|
Reference |
A type of COMP INTEL CHARACTERISTIC that is formed by aggregating other COMP INTEL CHARACTERISTIC, which may be Composite or Atomic COMP INTEL CHARACTERISTIC. |
|
|
Reference |
A special type of PRODUCT RATING PLAN to represent a group of rating plans together forming another new rating plan. |
|
|
Reference |
Defines the relationship of which PRODUCT RATING PLAN each COMPOSITE PRODUCT RATING PLAN contains. |
|
|
Reference |
A group of services together forming a new service. |
|
|
Reference |
Defines the relationship between COMPOSITE SERVICE and atomic service. Composite service inclusion defines how the COMPOSITE SERVICE is formed. |
|
|
Reference |
Tracks the relationship of which atomic service type each composite service type includes. |
|
|
Reference |
A Product Price that is made up of parts. The parts may be other Composite Prod Prices or Component Prod Prices. |
|
|
Reference |
This is the abstract base entity for all composite entities that are inherently manageable and form a PRODUCT. The key difference between network element and COMPOUND ELEMENT is that network element describes either a Physical or a Logical entity. In contrast, COMPOUND ELEMENT describes managed entities that are collections of other managed entities. A key point is that each managed entity that is part of a COMPOUND ELEMENT can be individually managed as either a PHYSICAL ELEMENT or a LOGICAL ELEMENT. |
|
|
Reference |
An entity that is individually manageable. A Compound Element Collection is an aggregate entity consisting of NETWORK ELEMENT and optionally Compound Element Collection entities. As such, a Compound Element Collection represents a set of PHYSICAL ELEMENTs and LOGICAL ELEMENTs that collectively represent a managed entity. For example, a Network is a subclass of Compound Element Collection. A Network can be made up of other Networks and SubNetworks. Each Network or SubNetwork can be made up of physical and logical components, gathered and represented by an Element Collection. Each node in the network can be represented by a NETWORK ELEMENT. |
|
|
Reference |
Defines the semantics of aggregating COMPOUND ELEMENT into a COMPOUND ELEMENT. |
|
|
Reference |
Defines the semantics of the COMPOUND ELEMENT aggregation. Compound Element Detail is abstract, because only its subclasses should be instantiated. There are three concrete subclasses of this class, which are used to represent the aggregation of PHYSICAL ELEMENT, LOGICAL ELEMENT, and COMPOUND ELEMENT into this particular COMPOUND ELEMENT. |
|
|
Reference |
This is a concrete entity that defines the semantics of aggregating LOGICAL ELEMENT into a COMPOUND ELEMENT. |
|
|
Reference |
This is a concrete entity that defines the semantics of aggregating PHYSICAL ELEMENT into a COMPOUND ELEMENT. |
|
|
Reference |
This entity is a role that is defined by the interaction between PHYSICAL ELEMENT ROLEs and LOGICAL ELEMENT ROLE. There must be at least one or more PHYSICAL ELEMENT ROLEs and one or more LOGICAL ELEMENT ROLE to form a Compound Element Role. However, neither a PHYSICAL ELEMENT ROLE nor a Logical Element Role has to belong to a Compound Element Role. |
|
|
Reference |
Implements the relationship between COMPOUND ELEMENT and network element role. |
|
|
Reference |
Implements the relationship between COMPOUND ELEMENT and network element role. |
|
|
Reference |
This is the abstract base entity that defines the invariant characteristics and behavior, attributes, methods, constraints, and relationships, of a COMPOUND ELEMENT. The key difference between a Compound Element Spec and either a PHYSICAL ELEMENT SPEC and a LOGICAL ELEMENT SPEC is that a PHYSICAL ELEMENT SPEC and LOGICAL ELEMENT SPEC define templates for specifying the invariant characteristics and behavior of PHYSICAL ELEMENTs and LOGICAL ELEMENTs, respectively. In contrast, a Compound Element Spec describes templates that contain at least one PHYSICAL ELEMENT SPEC and at least one LOGICAL ELEMENT SPEC. Optionally, one or more Compound Element Specs may also be specified. Thus, a Compound Element Spec is in effect a "shorthand notation" for specifying complementary PHYSICAL ELEMENT SPECs and LOGICAL ELEMENT SPECs. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building COMPOUND ELEMENT objects. The purpose of this entity is to track specifications of COMPOUND ELEMENTs separately from other types of Element Specifications. This entity inherits the Modifies Element Spec aggregation, and therefore can be used with the corresponding COMPOUND ELEMENT entity. The key difference between a COMPOUND ELEMENT SPEC and either a PHYSICAL ELEMENT SPEC and a Logical Element Type is that a PHYSICAL ELEMENT SPEC and Logical Element Type define templates for specifying the invariant characteristics and behavior of PHYSICAL ELEMENTs and LOGICAL ELEMENTs, respectively. In contrast, a COMPOUND ELEMENT SPEC describes templates that contain at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type. Optionally, one or more COMPOUND ELEMENT SPECs may also be specified. The difference between a Compound Element Spec Atomic entity and a COMPOUND ELEMENT SPEC COMPOSITE entity is that a Compound Element Spec Atomic entity is designed to be a standalone entity. Note that it still aggregates at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type; however, the result is that this Compound Element Spec Atomic entity can be used by itself.) In contrast, a COMPOUND ELEMENT SPEC COMPOSITE entity is made up of one or more COMPOUND ELEMENT SPECs, one of which must be a Compound Element Spec Atomic entity. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building composite COMPOUND ELEMENT objects. The purpose of this entity is to track specifications of COMPOUND ELEMENTs separately from other types of Element Specifications. This entity inherits the modifies Element Spec aggregation, and therefore can be used with the corresponding COMPOUND ELEMENT entity. The key difference between a COMPOUND ELEMENT SPEC and either a PHYSICAL ELEMENT SPEC and a Logical Element Type is that a PHYSICAL ELEMENT SPEC and Logical Element Type define templates for specifying the invariant characteristics and behavior of PHYSICAL ELEMENTs and LOGICAL ELEMENTs, respectively. In contrast, a COMPOUND ELEMENT SPEC describes templates that contain at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type. Optionally, one or more COMPOUND ELEMENT SPECs may also be specified. The difference between a COMPOUND ELEMENT SPEC ATOMIC entity and a Compound Element Spec Composite entity is that a COMPOUND ELEMENT SPEC COMPOSITE entity is designed to be a standalone entity. (Note that it still aggregates at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type; however, the result is that this COMPOUND ELEMENT SPEC ATOMIC entity can be used by itself.) In contrast, a Compound Element Spec Composite entity is made up of one or more COMPOUND ELEMENT SPECs, one of which must be a COMPOUND ELEMENT SPEC COMPOSITE entity. |
|
|
Reference |
Concrete entity that links TERMINATION POINT to COMPOUND ELEMENT. For example, it will describe characteristics and behavior of the TERMINATION POINTs that comprise this particular Element Port in terms of dependencies and how a TERMINATION POINT interacts with other TERMINATION POINTs. |
|
|
Reference |
A Element Unit is an entity that is individually manageable. The Compound Element Unit is an aggregate entity consisting of both physical and logical aspects of a managed Element. For example, a ROUTER is a Element Unit. Different PHYSICAL ELEMENT objects can model the physical aspects of the ROUTER in detail. For example, its CARDs, the number and type of PHYSICAL PORTs that are on each CARD, and so forth), and different LOGICAL ELEMENT objects can model the logical aspects of the ROUTER in detail (For example, what Software it is running, how many DEVICE INTERFACEs of what type are currently enabled, if there are any outstanding Faults or Alarms, and so forth). Resource Element aggregates all PHYSICAL ELEMENT and LOGICAL ELEMENT objects, enabling a high-level view of the physical and logical aspects of the Element to be provided. |
|
|
Derived |
Statistics about all connections and disconnections from each ACCESS METHOD on the network per day. This is related to the network usage or traffic. This entity is not related to counting "subscriptions" to a given service. |
|
|
Aggregate |
Monthly aggregation of all connections and disconnections on the network per day, for network usage or traffic analysis. |
|
|
Reference |
This is a class of managed objects responsible for the transparent transfer of information between CONNECTION TERMINATION POINTs. A Connection is a component of a Trail. Several connections can be bundled into a higher rate trail. A sequence of one or more Connections are linked to form a Trail. A Connection may be either uni- or bi-directional. |
|
|
Reference |
This is an actual or potential end point of a Network connection. For example, this can represent a logical channel or a timeslot on a physical link. All PHYSICAL PORTs connect to at least one type of CTP. |
|
|
Reference |
A communication that occurs as part of a PERFORMANCE CONSEQUENCE. A Notification is typically one-sided, in that no Response is expected. For example, an alert be raised as the result of a PERFORMANCE OBJECTIVE being violated. |
|
|
Reference |
The invariant characteristics that define a communication (notification) that occurs as part of a PERFORMANCE CONSEQUENCE. A Notification is typically one-sided, in that no Response is expected. For example, an alarm may be raised as the result of a PERFORMANCE OBJECTIVE being violated. |
|
|
Reference |
Lists of potential and existing CUSTOMERs for CAMPAIGNs. Contact lists can be created by the TELCO from marketing activity, running certain models, or obtained from another organization. |
|
|
Lookup |
Lookup for possible reasons for changing the CONTACT LIST. |
|
|
Base |
Subtype of COST, which applies to a specified CONTACT LIST (usually this is a cost associated with the purchase and maintenance of a contact list). |
|
|
Lookup |
A categorization of the recurrence of a CONTACT LIST. For example:
|
|
|
Lookup |
Describes the various roles a contact individual may play in the relationship with the operator. |
|
|
Reference |
Keeps all downloadable content provided to the customer through the operator's network. For example:
|
|
|
Base |
EVENT in which content was downloaded. |
|
|
Reference |
Price for downloading/ordering the content. This price is for individual content clip. There might be other contents priced as a flat rate rather than different price for each content. In this case, the pricing information should be in PRODUCT RATING PLAN. |
|
|
Lookup |
Lookup for types of content pricing. For example:
|
|
|
Reference |
Provider for content that would be consumed by end user. The contents could be video, audio clips, or text content. |
|
|
Lookup |
Lookup for content types. For example:
|
|
|
Reference |
Legal agreement between a Communications Service Provider and an account. |
|
|
Base |
Approval for the CONTRACT from the operator's authorized employee, if the contract requires higher level approval or review. |
|
|
Reference |
Defines relationship(s) between contracts. |
|
|
Lookup |
Lookup for reasons of why two contracts are related. For example: The reason for one contract to be replaced by another:
The reason for one contract to depend on another:
|
|
|
Lookup |
Lookup for types of assignment between two contracts. For example:
|
|
|
Lookup |
Lookup to classify the initiator of the contract change. |
|
|
Lookup |
Lookup of all the type of contract changes. For example:
|
|
|
Derived |
Derived information about a customer's current/future contract for analytical purpose. This entity captures only changed, current or future, contracts. |
|
|
Reference |
The document(s) provided by the customer when a contract was signed. For example:
|
|
|
Derived |
Derived information about a customer's current/future contract for analytical purpose. The entity only contains changed contract (current or future). |
|
|
Reference |
Detail items for the CONTRACT. Each item may use a different PRODUCT. |
|
|
Aggregate |
Derived information about a customer's current/future contract for analytical purpose. The entity only contains changed contract (current or future). |
|
|
Reference |
To accommodate special link or additional usage of product in contract. |
|
|
Base |
The status history of the CONTRACT. |
|
|
Lookup |
Lookup for description of the contract status change. For example:
|
|
|
Lookup |
Lookup for all possible types of CONTRACT STATUS. For example:
|
|
|
Lookup |
Lookup for all possible terms which may be attached to a CONTRACT. For example:
|
|
|
Base |
The value of terms attached to the CONTRACT. For example:
The value can vary at different time period of contract. For example, the monthly fee might be 100 for the first six months and 80 for the last six months. A penalty calculation can also be based on the months left in contract. |
|
|
Lookup |
Lookup for contract types. |
|
|
Reference |
Defines a DEVICE INTERFACE role that functions as a Core Interface, that is, an interface in the core of the network. The objective of this role is to enable the definition of POLICYs such that all Core Interfaces in a particular Domain can receive the same common configuration commands. |
|
|
Base |
Costs that have been incurred from operations and events at trackable levels. For example:
|
|
|
Reference |
Cost Center of a COURIER or provider to which costs can be charged. |
|
|
Base |
The budget of each COST CENTER at a specific financial period. |
|
|
Aggregate |
Statistics of various costs incurred to the customer. These details are important for analysis such as:
|
|
|
Derived |
Monthly aggregation of various cost incurred to the customer. These details are important for analysis such as:
|
|
|
|
Aggregate |
Monthly aggregation of all expenses by each business unit inside the carrier. |
|
Derived |
Statistics of all expenses by each business unit inside the carrier. These values can be useful for auditing and budgeting purposes. |
|
|
Lookup |
Lookup of all possible reasons why the cost occurred. For example:
|
|
|
Lookup |
Lookup to further classify COST TYPEs. For example:
|
|
|
Lookup |
Lookup for types of costs. For example, the cost is to the CUSTOMER, CHANNEL, COURIER, or to the EMPLOYEE (Mobile Monthly Claim or Purchase). |
|
|
Reference |
The party who provides the Courier service for the Telecom Operator. |
|
|
Base |
Subtype of COST which applies to a COURIER for delivering products or invoices to the customer. |
|
|
Reference |
Defines required logical features to implement the specific role of a CPE (Customer Premise Edge) device, as used in a PRODUCT or SERVICE. |
|
|
Reference |
List of credit categories available that may be assigned to customers. For example:
|
|
|
Aggregate |
Credit category aggregation over all customers at each month. |
|
|
Derived |
Credit category assigned to each customer at each month. The credit categories are defined in the credit category dimension. |
|
|
Reference |
Provides reference financial rating scores for each customers to the service provider. This information is also called the "Credit Rating Agency". |
|
|
Lookup |
Lookup for currencies that may be used in a transaction. |
|
|
Base |
Exchange rate against the primary currency, as determined by exchange rate type and value date. |
|
|
Reference |
Assigns currency usage to a geographic area. |
|
|
Reference |
Information pertaining to customers. |
|
|
Derived |
Aggregate daily new customer count by PRODUCT. |
|
|
Aggregate |
Monthly summary of newly acquired customers by PRODUCT. |
|
|
Derived |
Defines which CUSTOMER belongs to which CUSTOMER COMMUNITY. |
|
|
Lookup |
Lookup for Customer Classification codes. For example:
|
|
|
Reference |
Assign customer to a customer class. A customer may belong to different customer classes because of their usage behavior at different times, therefore customer to customer class is a many to many relationship. |
|
|
Reference |
The Customer Communities identified by mining algorithm. |
|
|
Base |
Defines which CUSTOMER belongs to which CUSTOMER COMMUNITY. |
|
|
Base |
Subtype of COST which applies to a customer. For example, the cost of a gift that is sent to a customer. |
|
|
Aggregate |
Statistics on Customer fraud and debt collection. |
|
|
Derived |
Monthly summary of customer fraud and debt collection. |
|
|
Reference |
Various types of customer proof documents provided for a CUSTOMER ORDER, contract, and so on. |
|
|
Derived |
Statistics related to customer equipment installation activities for each customer. These statistics typically include: modems, routers, or DSL boxes for internet and Television equipment |
|
|
Aggregate |
Monthly summary of customer equipment installation activities. These statistics typically include: modems, routers, or DSL boxes for internet and Television equipment. |
|
|
Reference |
This is the base entity for defining CUSTOMER FACING SERVICEs. A CUSTOMER FACING SERVICE is an abstraction that defines the characteristics and behavior of a particular SERVICE as seen by the Customer or other appropriate PARTY ROLE. Thus, this PARTY ROLE purchases, leases, uses, and/or is otherwise directly aware of this type of SERVICE. This is in direct contrast to RESOURCE FACING SERVICEs which support CUSTOMER FACING SERVICEs but are not seen or purchased directly by the Customer. For example, a VPN is an example of a CUSTOMER FACING SERVICE, while the sub-services that perform different types of routing between network devices making up the VPN are examples of RESOURCE FACING SERVICEs. |
|
|
Reference |
Defines a SERVICE in terms of a set of SERVICE ROLEs for a CUSTOMER FACING SERVICE. This entity defines SERVICE ROLEs that represent the variable characteristics of a CUSTOMER FACING SERVICE in terms of the roles that this SERVICE plays. This entity enables the CUSTOMER FACING SERVICE to be managed abstractly using SERVICE ROLEs. The Customer Facing Service Role also helps define the SERVICE in terms of the functions that it has or provides. |
|
|
Lookup |
This is the base entity for defining Customer Facing Service Specifications. A Customer Facing Service Specification is an abstraction that defines the invariant characteristics and behavior of a particular CUSTOMER FACING SERVICE as seen by the Customer. The invariant portion serves as a single common basis to build a set of variable CUSTOMER FACING SERVICEs that all use this common Customer Facing Service Specification. |
|
|
Lookup |
This entity defines CUSTOMER FACING SERVICE SPECs that do not have any subordinate CUSTOMER FACING SERVICE SPECs. In other words, a Customer Facing Service Spec Atomic is a standalone CUSTOMER FACING SERVICE SPEC, and does not require any supporting CUSTOMER FACING SERVICE SPECs to define the invariant characteristics (that is, non-changing attributes, methods, relationships, and constraints) of any CUSTOMER FACING SERVICEs that it serves as a template for. |
|
|
Lookup |
This entity defines an integrated set of CUSTOMER FACING SERVICEs that collectively meets the needs of a SERVICE requested by a Customer. For example, the Customer may have requested GoldService, which is a SERVICE PACKAGE that defines a set of SERVICE BUNDLEs, each of which has its own QoS. Each individual CUSTOMER FACING SERVICE that is part of the SERVICE PACKAGE can be derived from a CUSTOMER FACING SERVICE SPEC. In this case, a Customer Facing Service Spec Composite will aggregate all of the individual CUSTOMER FACING SERVICE SPECs into a single named object. This object is a standalone object. However, it consists of other Customer Facing Service Spec Composite and/or the CUSTOMER FACING SERVICE SPEC ATOMIC entities. That is the primary difference between this entity and the Customer Facing Service Spec Atomic entity. |
|
|
Reference |
Defines a Service Specification, in terms of a set of Service Specification Roles, for a CUSTOMER FACING SERVICE. This is the base entity for defining Service Specification Roles that are used to represent the invariant characteristics of a CUSTOMER FACING SERVICE. This entity enables the CUSTOMER FACING SERVICE to be managed abstractly using Service Specification Roles. The Customer Facing Service Spec Role also helps define the Service Specification in terms of the functions that it has or provides. |
|
|
Reference |
Keeps the historical versions of CUSTOMER FACING SERVICE SPEC. |
|
|
Base |
The activities to install services at the customer site. For example:
|
|
|
Base |
On site installation for the customer with particular equipment instance. |
|
|
Base |
Details regarding customer service. |
|
|
Base |
The activities of providing on site support to a customer. |
|
|
Lookup |
The lookup code for grouping the customers based on criteria defined by the service operator. |
|
|
Reference |
A grouping of the customers based on criteria defined by the service operator. |
|
|
Reference |
Subtype of CUSTOMER (and PARTY), which contains details of individuals as opposed to organizations. |
|
|
Lookup |
The band of customer life time value that is predicted from the data mining model. For example, 0~100 USD, 100~200 USD, and so on. |
|
|
Derived |
The result measures from mining analysis, including churn probabilities, Life Time Value (LTV) mining, and other result measures. |
|
|
Reference |
Event celebrated or observed by a customer. For example:
|
|
|
Lookup |
Lookup for occasion type. For example: Wedding Anniversary, Birthday, Company founding anniversary, and so on. |
|
|
Base |
Orders placed by customers. This customer order is currently for service providers shop service, where a customer can place an order for a handset, a broadband installation request, or make some other order. |
|
|
Reference |
The document provided while submitted CUSTOMER ORDER. |
|
|
Base |
Details regarding items in the CUSTOMER ORDER. |
|
|
Base |
Current state of an order line item. |
|
|
Base |
Payments applied to a CUSTOMER ORDER. |
|
|
Lookup |
Lookup for possible priorities which can be assigned to a CUSTOMER ORDER. |
|
|
Base |
Current state of a CUSTOMER ORDER. |
|
|
Lookup |
All type of reason for customer order state and customer order line item state changes. |
|
|
Reference |
Subtype of CUSTOMER (and PARTY), which contains details of organizations as opposed to individuals. An organization can also consist of one individual only (for example: independent). |
|
|
Reference |
Detail information about a customer that may be deemed private. |
|
|
Lookup |
Entity contains a customer classification in revenue terms. For example: Customer with charges between $100 to $200. |
|
|
Reference |
Assigns a revenue band to a customer. |
|
|
Lookup |
Lookup for types of revenue a customer may bring to the operator. For example:
|
|
|
Reference |
Scores or Score ranges that may be assigned to a customer based on credit, behavior, or other criteria. For example:
|
|
|
Reference |
Market or customer segments to which customer may be assigned. |
|
|
Reference |
The segmentation model used to profile the customers. For example:
|
|
|
Lookup |
Lookup for the various customer feelings as reported during a party interaction (on the phone, as email, or from simple mail). The value can be used for text mining. For example:
|
|
|
Reference |
Assigns SIC/NASIC code to customers. |
|
|
Reference |
Initial source or contact with customer. For example:
|
|
|
Lookup |
Lookup for type of customer. For example: Individual or Corporate. |
Table 2-24 D to F Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Base |
Data Service Events. For example
|
|
|
Derived |
Daily aggregate of data usage. |
|
|
Aggregate |
Monthly aggregate of data usage. |
|
|
Reference |
Defines day, the lowest level of all calendars. |
|
|
Reference |
Weather, external and internal conditions that may have impacted performance on a given day at a given location. |
|
|
Reference |
Documents how todate transformation can be implemented at day level. |
|
|
Reference |
Transformation for a day. For example, maps a day last year to a corresponding day this year, or a day last year, to a day last month, and so on. |
|
|
Reference |
A deal refers to a special offer from a supplier to the telecom provider. The deal generally provides allowances, discounts, special favorable terms of payment or other incentives to motivate the service provider to buy more products or services from a supplier. |
|
|
Reference |
Identifies a specific product or service that is offered as part of a deal to the service provider and defines how the deal cost is to be handled. |
|
|
Reference |
Identifies a specific product or service that is offered as part of a deal to the service provider and defines how the deal cost is to be handled. |
|
|
Reference |
The PARTY who resells products from the operator. |
|
|
Reference |
Assigns DEALER to a discount group(s). |
|
|
Lookup |
Ranges of time used to group debt based on the age of the debt. For example:
|
|
|
Base |
A special type of interaction to collect defaulted payment from a customer by the in-house debt collector. |
|
|
Base |
The assignment of a debt collection case to an external debt collection agency. |
|
|
Base |
Grouping of collection assignments sent to collector. |
|
|
Reference |
A feature or quality used to make recognizable or to define somebody or something, such as age, income, education, revenue, and so forth. |
|
|
Reference |
A single value or range of values that defines a DEMOGRAPHIC CHARACTERISTIC. |
|
|
Reference |
User defined demographic attributes that can be assigned values. |
|
|
Reference |
The domain of classifications used to group profile information about a PARTY. For example:
And other relevant demographics and psychographics. |
|
|
Reference |
Derived value of the customer based on predetermined criteria. |
|
|
Lookup |
Lookup for the types of destination associated with CALL SOURCE DESTINATION. For example:
|
|
|
Reference |
This is a concrete entity that represents the (logical) interface or sub-interface of a device. This entity is not a transmission entity; rather, DEVICE INTERFACEs are used to program SERVICEs and LOGICAL ELEMENTs on a Device. For example, use a Device Interface to program a logical connection from a device to a network medium. Different types of Device Interfaces exist for the different types of network media. For example IP compared with ATM, that are used in a network to enable such media to be programmed. The combination of a LOGICAL DEVICE and a Device Interface is what a developer programs to define SERVICEs that run on the device. |
|
|
Reference |
In general, there are multiple ways to manage a DEVICE INTERFACE. The first distinction lies in what is being managed. the model defines two types of management commands categories: configuration and operational. Configuration commands are used to configure the DEVICE INTERFACE (and also the LOGICAL DEVICE for commands that affect multiple specific DEVICE INTERFACEs). Operational commands are used to monitor and troubleshoot the software, network connectivity, and the Device itself. |
|
|
Lookup |
Defines which PHYSICAL PORT can support which DEVICE INTERFACE. |
|
|
Reference |
Represents different types of roles that can be associated with a particular DEVICE INTERFACE. |
|
|
Reference |
Defines the relationship between DEVICE INTERFACE and TERMINATION POINT. |
|
|
Lookup |
Lookup for the various reasons the current status is direct debit payment. For example:
|
|
|
Reference |
Discount groups that employees or partners may be a part of. |
|
|
Reference |
A discount, a reduction of price, for a SUBSCRIPTION. |
|
|
Lookup |
Distance ranges to characterize network events by geographical distance. |
|
|
Lookup |
Lookup for all reasons for diverting a call or retrieving a call from a Mailbox. For example:
|
|
|
Lookup |
Lookup for types for diverting a call or retrieving a call. For example:
Subscriber's calls are diverted to voice mail or to a Unified Messaging Service (UMS) mailbox as specified by the subscriber instructions or settings. For example, calls can be diverted when a subscriber is busy on another call, or when the subscriber has switched off the handset, or when a subscriber is not reachable. The subscriber can later retrieve all calls that are stored on the mailbox by accessing the mailbox through specified numbers or using the Internet, in case of UMS. All this traffic generated by diverted calls and retrieved calls is to be analyzed based on the type of call such as diverted or retrieved. The Divert Retrieve type helps in achieving this analysis by organizing calls as diverted or retrieved calls. |
|
|
Lookup |
Lookup for possible document condition types. For example:
|
|
|
Lookup |
Lookup for document types. For example:
|
|
|
Lookup |
The group of DOCUMENT TYPEs of which customer may provide to service provider for identification. For example:
|
|
|
Reference |
Assigns different DOCUMENT TYPEs into different DOCUMENT TYPE GROUPs. |
|
|
Reference |
The xDSL modem to implement Broadband on copper wire (router). |
|
|
Reference |
Defines a DEVICE INTERFACE role that functions as an Edge Interface; that is, an interface on the edge of the network. The objective of this role is to enable the definition of POLICYs such that all Edge Interfaces in a particular Domain can receive the same common configuration commands. |
|
|
Lookup |
Demographic education levels that may be assigned to customers. |
|
|
Reference |
A characteristic quality or distinctive feature of an Element Specification. The characteristic can take on a discrete value, such as color, can take on a range of values, for example, sensitivity of 100-240 mV, or can be derived from a formula for example, usage time (hrs) = 30 - talk time *3. Certain characteristics, such as color, may be configured during the ordering or some other process. |
|
|
Reference |
A use of the Element Spec Characteristic by an Service Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Element Spec Characteristic. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between or among Element Spec Characteristics. |
|
|
Reference |
A number or text that can be assigned to an Element Spec Characteristic. |
|
|
Reference |
A use of the Element Spec Characteristic Value by an Entity Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Element Spec Characteristic Value. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between or among Element Spec Characteristic Values. |
|
|
Reference |
Specifies all the Email mail boxes allocated to CUSTOMER. |
|
|
Reference |
Subtype of individual indicating an employee of the provider. |
|
|
Base |
Worked shifts by hourly employees. |
|
|
Base |
Worked shifts by salaried employees. |
|
|
Base |
Subtype of COST, which applies to employee. For example, salary and bonus for employee. |
|
|
Lookup |
The various designations present in an organization for the employees. For example:
|
|
|
Reference |
Assigns EMPLOYEE to DISCOUNT GROUP(s). |
|
|
Base |
The expense reports submitted by employees, including contractors, to claim their business expenses. The EMPLOYEE (Party) and PAYMENT CHANNEL (channel) are captured by its super entity EVENT. The expense submit date is the event begin date. |
|
|
Base |
The detail line item of each EMPLOYEE EXPENSE REPORT. |
|
|
Base |
The different state of a given EMPLOYEE EXPENSE REPORT. For example:
|
|
|
Reference |
||
|
Lookup |
Relevance of job role assignment to employee. For example: Primary, Secondary, and so on. |
|
|
Reference |
Specifies the languages the employee can use to serve customers, especially for call center agents and sales representatives. |
|
|
Reference |
Detail information about the EMPLOYEE that may be deemed private. |
|
|
Reference |
Planned staffing schedule of location, role, shift, and employees. |
|
|
Base |
List the trainings an employee has received. The employee training record is normally meant to apply to the call center agent, who is trained on specific products and or services. |
|
|
Lookup |
Lookup of employee type. For example:
|
|
|
Reference |
This entity represents entities that cannot be directly managed. For example, a hub. |
|
|
Reference |
This is an abstract base entity that defines the concept of various types of roles for entities that describe the function of the entities. |
|
|
Reference |
This is an abstract base entity that defines the invariant characteristics, attributes, methods, constraints, and relationships, of another entity. |
|
|
Reference |
The devices, delivered by COURIER or collected at the DEALER shop, that a CUSTOMER can use to access services. The device might be Cell Phone, Fixed Line Phone, Fax Machine, and so on. The devices might be lent or sold to the customer. The equipment entity is a subtype of PRODUCT. |
|
|
Reference |
Facility housing devices. |
|
|
Base |
Subtype of COST, which collects all costs that are specifically related to a given EQUIPMENT CENTER (facility rent, taxes, and so on). |
|
|
Reference |
The function of the EQUIPMENT. For example:
|
|
|
Reference |
Assigns functionality to EQUIPMENT. |
|
|
Reference |
Represents physical objects that are both manageable and able to host, hold, or contain other physical objects. Examples of physical objects that can be represented by instances of this object class are RACKs, CHASSISs, Shelves, and SLOTs. The difference between subclasses of Equipment Holder, such as a SLOT or a CHASSIS, and subclasses of EQUIPMENT that have a Holder role, such as a CARD, is that the subclasses of Equipment Holder are dedicated to holding other Hardware. The subclasses of EQUIPMENT that have a holder role have a holding capability as a secondary capability, usually for expansion. Their primary function, however, is not to hold other objects. |
|
|
Reference |
Implement communications. For example:
|
|
|
Reference |
Subtype of CONTRACT in which customers lease some EQUIPMENT. This equipment still belongs to the service provider. When a contract terminates the device should be returned to the service provider. For example:
|
|
|
Base |
A history of the status for an EQUIPMENT INSTANCE. For example:
|
|
|
Lookup |
Lookup for type of specific equipment instance status type. For example:
|
|
|
Reference |
A subtype of SUBSCRIPTION to track tangible device usage by the customer. |
|
|
Lookup |
The lookup code for type of (customer side) equipment. For example:
|
|
|
Base |
The errored/recycled mediated event record from billing engine. |
|
|
Base |
The errored/recycled rated event record from billing engine. |
|
|
Base |
The errored/recycled/rejected raw event record from the mediation process. |
|
|
Base |
Describes the interactions with the Communications Service Provider. Event contains only "non-network" events (anything other than a call data record). An event can occur related to a provider. For example, for equipment down or a service disruption. An event can occur related to a CUSTOMER. For example, for a service order or a bill payment. Events store customer behavior to make special campaigns or to analyze the cost of customers. Normally an event incurs some cost and may generate revenue for the operator. The information specific to the type of event, or event interaction, is stored in corresponding event subtypes. |
|
|
Base |
Occurrence of Access Method Usage. |
|
|
Base |
Events occurring on an account. For example:
|
|
|
Base |
Describes relationship between unique events. |
|
|
Lookup |
Lookup for all possible reasons why a relationship exists between two EVENTs. For example:
|
|
|
Lookup |
Lookup for all types of relationships between two EVENTs. |
|
|
Lookup |
Lookup for EVENT CATEGORY which is further grouped into EVENT TYPE. For example:
|
|
|
Base |
The chat history between the service representative and the CUSTOMER. |
|
|
Base |
The chat history details between the service representative and the CUSTOMER. Each chat message is saved as one record. |
|
|
Base |
Subtype of "Non Network Events", corresponding to the rental of a fixed line (broadband or phone line). The rental normally incurs charges for various type of activities. For example:
|
|
|
Lookup |
Lookup for the classification for the types of EVENTs that can occur. For example:
|
|
|
Base |
EVENT that happened in a CONTRACT. For example, an agreement breach event. |
|
|
Base |
Subtype of COST, which is specifically related to a given EVENT. This cost is usually for a non-network event such as an interaction with a customer. For example, for on-site maintenance after a service issue or a break-down. |
|
|
Reference |
The expressions that determine what, if any, constraints are to be applied to this Policy Event Set. This entity also defines additional semantics to help identify the type of this event. |
|
|
Base |
Event in which payroll payment was made to an employee (excludes sales commission). Subtype of EVENT. |
|
|
Base |
||
|
Base |
Financial event involving an account or billing statement. Subtype of EVENT. |
|
|
Base |
Events affecting a Geographic Area that may have an impact on a provider's business. Subtype of EVENT. For example:
|
|
|
Base |
A gift redemption event occurred for a contract or subscription; normally because of a product market plan promotion. Operators may also give away gift items because of events such as a wrong billing. The redemption does not involve a LOYALTY PROGRAM. |
|
|
Base |
The delivery of invoice to customer. For example:
|
|
|
Reference |
Assigns an address location to the EVENT. |
|
|
Base |
Events associated with each event or transaction on a customer loyalty program. For example:
|
|
|
Base |
Subtype of EVENT LOYALTY PROGRAM, where a customer receives loyalty program points, a credit, based on network usage, a payment, or some other event. |
|
|
Base |
Subtype of EVENT LOYALTY PROGRAM, where a customer uses loyalty program points, a credit, to redeem gift items including cash placed in their account balance or some other redemption gift item such as a toy. |
|
|
Base |
Many to many relationship assigning a party or multiple parties to event(s). |
|
|
Base |
Interactions or communications with the customer. For example:
|
|
|
Base |
Subtype of EVENT PARTY INTERACTION which represents all phone call interactions from the customer with detailed information including:
|
|
|
Base |
Subtype of EVENT PARTY INTERACTION which represents email interaction from customers. |
|
|
Base |
When multiple threads are discussed in a single EVENT PARTY INTERACTION, this line item lists the involved threads and other information including accounts, subscriptions, and so on. This is also the M:M relationship between the PARTY INTERACTION THREAD and the event. |
|
|
Base |
Subtype of EVENT PARTY INTERACTION which represents the interaction with customers through letters. |
|
|
Base |
Tracks multiple employees who participate in a same interaction with a customer |
|
|
Base |
Visits to a store by a customer. Subtype of EVENT. |
|
|
Base |
Event in which party profile information was modified or updated. |
|
|
Reference |
Role played by a PARTY in an EVENT. For example:
|
|
|
Base |
Actions involving PREPAID MOBILE EVENT TYPE account. Subtype of EVENT ACCOUNT. For example:
|
|
|
Base |
Events associated with an offer or PRODUCT PACKAGE. Subtype of EVENT. |
|
|
Lookup |
Lookup for event reasons. For example: arrearage. |
|
|
Lookup |
Lookup for event reason categories. Categories are further grouped into event reasons. |
|
|
Reference |
The domain of results that may occur in the resolution of an EVENT. |
|
|
Lookup |
Lookup for possible response reasons that may be used in an EVENT. |
|
|
Lookup |
Lookup for the description of a result or any events. For example:
|
|
|
Base |
||
|
Base |
Lookup for event status. For example:
|
|
|
Lookup |
Lookup for event status reasons. For example:
|
|
|
Lookup |
Lookup for EVENT STATUS. For example:
|
|
|
Base |
Events associated with a subscription. Subtype of EVENT. For example:
|
|
|
Base |
Events involving temporal provisioning and relinquishment of products and services to current subscription base. |
|
|
Reference |
Tracks the execution, evaluation of POLICY RULE on each POLICY EVENT. |
|
|
Lookup |
Lookup for event type. For example:
|
|
|
Base |
The event of a customer registering at Web site to apply for service. |
|
|
Base |
Subtype of Customer Interaction event, to track the customer visit on a service provider Web site. |
|
|
Reference |
The attribute exclusionFunction is designed to be populated from an external management system, and represents the criteria for excluding one or more Element Ports. A predefined exclusion function is to limit the role that a Element Port plays to an edge role. However, this entity enables additional functions to be used to exclude Element Ports. |
|
|
Base |
The involvement of different PARTYs in a given EMPLOYEE EXPENSE REPORT. For example:
|
|
|
Lookup |
Lookup for the types of STATE which an EMPLOYEE EXPENSE REPORT may be in. For example:
|
|
|
Lookup |
Lookup for type of expense being claimed. For example:
|
|
|
Reference |
A source of information that helps define the credit worthiness of the customer. |
|
|
Reference |
Indicate which external agency or institute provided the credit profile for the given customer. |
|
|
Derived |
Daily collections by external collector. |
|
|
Aggregate |
Monthly collections by external collector. |
|
|
Reference |
Source from which the demographic information or customer information is obtained. |
|
|
Reference |
All operators the Service Provider does business with, including inland competitors or roaming partners. |
|
|
Lookup |
Lookup for types of external organizations. |
|
|
Reference |
Stores the information about the factor company, which is the financial instrument holding the receivables. |
|
|
Lookup |
Lookup for available types of network fault resolution. |
|
|
Lookup |
Lookup for available types of faults. |
|
|
Reference |
The FDA is the Fibre Distribution Area. The FDA is an aggregated fiber broadband geographical area served. Each area served is one "Network Site". |
|
|
Lookup |
Lookup for available result types for customer field activities that are performed by support engineers. For example:
|
|
|
Lookup |
Lookup for types of customer field activities that may be performed by support engineers. For example:
|
|
|
Reference |
Defines half-month in a fiscal calendar. |
|
|
Reference |
Defines half-year in a fiscal calendar. |
|
|
Reference |
Defines month in a fiscal calendar. |
|
|
Reference |
Defines quarter in a fiscal calendar. |
|
|
Reference |
Defines week in a fiscal calendar. |
|
|
Reference |
Defines year in a fiscal calendar. |
|
|
Reference |
Abstracts the different routing capabilities necessary for a LOGICAL DEVICE to have. This helps simplify the modeling of (especially) network devices, which have many different sets of capabilities. For example, most routers can do routing, forwarding, and firewalling of traffic. By modeling these capabilities as three roles, router functionality is both abstracted and categorized, so that the differences between firewalling done by a router and firewalling done by a dedicated firewall device can be differentiated. |
|
|
Reference |
Subtype of PRODUCT that provides detailed information on the fixed line service. |
|
|
Base |
Event involving a call made on a Fixed Line telephone. |
|
|
Reference |
The port ID associated with the telephone plug that provides a customer with fixed line service. The Fixed Line Port connects a customer's phone to a SWITCH. |
|
|
Reference |
Subtype of PRODUCT RATING PLAN associated only with Fixed Lines. |
|
|
Reference |
Subtype of SERVICE for detail information on the fixed line service. |
|
|
Reference |
An abstracted entity to provide common structure for all types of characteristics. All of the various types of characteristics may be applicable to the subject, including product, service, network element, and so on. This entity provides a flexible way to define additional attributes for those entities with complex features. |
|
|
Reference |
Assigns the characteristic to the subject. |
|
|
Reference |
Lookup of ASSIGNMENT TYPE. For example:
|
|
|
Reference |
Relationship between characteristics, for example, one characteristic may conflict with another. |
|
|
Reference |
Lookup of FLEXIBLE CHARACTERISTIC types. |
|
|
Reference |
Possible values that a characteristic may take, including predefined choices or free numeric values. |
|
|
Reference |
Assigns the characteristic value to the applicable subject. |
|
|
Reference |
Relationship between two flexible characteristic values. For example, exclusiveness, same as, and so on. |
|
|
Lookup |
Lookup for all possible classes of fraud profile that customers or dealers may commit. |
|
|
Reference |
FSAM (Fibre Serving Area Module) is an aggregation of FDAs. The FSAM is a group of served areas by the operators of the service, mostly FTTH, or Optical Fiber Broadband. |
Table 2-25 G to J Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Lookup |
Lookup for gender. |
|
|
Reference |
Building level in GEOGRAPHY HIERARCHY. |
|
|
Reference |
Cities defined in a Geography. |
|
|
Reference |
Specifies the complex level in GEOGRAPHY HIERARCHY. The complex includes the complexes, a few building forming an enclosed area, in a city, at Universities, or industrial parks, and so on. |
|
|
Reference |
Countries defined in a Geography. |
|
|
Reference |
Counties defined in a Geography. |
|
|
Reference |
User-defined classification for DEMOGRAPHY ATTRIBUTEs. |
|
|
Reference |
User defined attributes to describe demographic information for a given Geography. |
|
|
Reference |
User defined values corresponding to the DEMOGRAPHY ATTRIBUTEs. |
|
|
Reference |
User defined geographic units. |
|
|
Reference |
Assignment of GEOGRAPHY ENTITYs to a user defined hierarchy level. |
|
|
Reference |
Assigns GEOGRAPHY ENTITYs to GEOGRAPHY HIERARCHY LEVELs. |
|
|
Reference |
User defined geographic hierarchies. |
|
|
Reference |
User defined levels within a geographic hierarchy. |
|
|
Reference |
Assignment of a GEOGRAPHY HIERARCHY level to a GEOGRAPHY ENTITY. |
|
|
Reference |
User defined name and descriptions for GEOGRAPHY HIERARCHY LEVEL. |
|
|
Reference |
User defined attributes associated with a GEOGRAPHY LEVEL. |
|
|
Reference |
Values assigned to the GEOGRAPHY LEVEL ATTRIBUTEs. |
|
|
Reference |
Defines a neighborhood in GEOGRAPHY HIERARCHY. |
|
|
Reference |
Defines a region in a Geography. |
|
|
Reference |
Defines a state in a Geography. |
|
|
Reference |
Defines a city in GEOGRAPHY HIERARCHY. |
|
|
Reference |
Defines a subregion in a Geography. |
|
|
Reference |
Top level of Geography. |
|
|
Derived |
Statistics of all give away items to the customer for promotion or retention purposes. |
|
|
Aggregate |
Monthly aggregation of all give away items given to customers for promotion or retention purposes. |
|
|
Lookup |
Lookup for types of give-aways. |
|
|
Reference |
The GL accounts are defined to track financial status from a specific angle. All GL Journals are posted to various GL Accounts to reflect financial impact of each business transaction. Each account is defined by certain codes and flags, including whether the account is enabled, whether detail posting or detail budgeting is allowed, and others. |
|
|
Reference |
Defines the relationship between two GL ACCOUNTs to form an Account Hierarchy. It stores lists of the detail accounts associated with each summary account. |
|
|
Reference |
Defines different types of GL ACCOUNT, including: Cash, Bank, Equipment, and so on. |
|
|
Lookup |
Lookup for types of GL ACCOUNTs. For example:
|
|
|
Base |
Specifies actual, budget, and encumbrance balances for detail and summary accounts. |
|
|
Reference |
Subtype of GL SEGMENT linking GL ACCOUNT to a specific COST CENTER. |
|
|
Base |
Specifies journal entries. |
|
|
Base |
Specifies journal entry batches. |
|
|
Lookup |
Lookup for journal entry categories. Specifies the category name and description. Each journal entry in the General Ledger is assigned a journal entry category to identify its purpose. For example:
|
|
|
Base |
Specifies the journal entry lines to track changes to each GL ACCOUNT made by a certain GL JOURNAL ENTRY. There is a one-to-many relationship between GL JOURNAL ENTRYs and journal entry lines. |
|
|
Base |
Defines the relationship between GL JOURNAL ENTRY LINEs and GL SUBLEDGER JOURNAL ENTRY LINEs. Represents individual transactions from subledgers that have been summarized into General Ledger journal entry lines. |
|
|
Reference |
Defines information about the ledgers and the ledger sets defined in the Financial system. A GL Ledger is defined by 4C, chart of accounts (COA), functional currency, accounting calendar, and Accounting method. |
|
|
Reference |
Assigns the GL ACCOUNTs to GL LEDGERs to form the Chart Of Account (COA). |
|
|
Reference |
Assigns the GL ACCOUNT to corresponding ORGANIZATION BUSINESS UNIT. |
|
|
Reference |
Specifies information about the accounting periods defined with an Accounting Calendar. |
|
|
Reference |
Assigns the GL ACCOUNT to corresponding PRODUCT. |
|
|
Reference |
Assigns the GL ACCOUNT to corresponding PROJECT. |
|
|
Reference |
Groups or Categories referred from General Ledger to classify all revenue related activities. |
|
|
Reference |
Each GL ACCOUNT contains a few independent segments, which are determined by the Financial System setup. For example, telecom operators may setup their GL Account in this format: <Country, Cost Center, Account, SubAccount> 1 Y3G1 US 1001 2000 2 Y1C1 JP 1001 3000 3 Y2C1 CN 2001 4000 In this example, Country, Cost Center, and so on, are all different GL Segments. Account 1001 may stand for Cash, while 2001 stands for Bank, and 4000 stands for a specific bank account, and so on. Each of the GL ACCOUNTs may be linked (rolled up) to a specific business entity (Concept), such as organization business unit, project, and so on, through the subentities of GL Segment. Note: Do not confuse Account in this description with ACCOUNT, which is customer account. |
|
|
Lookup |
Lookup for type of GL SEGMENT. For example:
|
|
|
Reference |
Specifies the subsidiary ledger, and represents original business transaction information that varies depending on the application. |
|
|
Base |
Represents subledger journal entries. The subledger Journal Ledger records the transaction at original level, that is each invoice, or each Purchase Order should have one entry in subledger journal entry. |
|
|
Base |
Represents the subledger journal entry lines. There is a one-to-many relationship between subledger journal entry headers and subledger. The GL Subledger Journal Entry Line breaks down the GL SUBLEDGER JOURNAL ENTRY into different GL ACCOUNTs. |
|
|
Derived |
Statistics on the PCU (Packet Control Unit) for the GPRS (General Packet Radio Service) such as bytes sent, bytes received, the transferred data volume, and so on. |
|
|
Aggregate |
Monthly aggregation of statistical values on PCU (Packet Control Unit) for the GPRS (General Packet Radio Service). For example:
|
|
|
Reference |
Subtype of PRODUCT, with more information about GPRS (General Packet Radio Service). The service provider provides various services such as Internet, WAP to its customers or subscribers over GPRS. The information about the usage of these services is to be analyzed at individual and aggregate level. The GPRS service dimension organizes all GPRS services. |
|
|
Derived |
Daily summation regarding GPRS services provided to subscribers. |
|
|
Aggregate |
Monthly summation regarding GPRS services provided to subscribers. |
|
|
Base |
Specifies the GPRS Session Event. This describes most of the fields you find in the GPRS S-CDRs and G-CDRs as defined by ETSI. |
|
|
Reference |
Half-hours defined as part of time. |
|
|
Reference |
Todate transformation information at the half-month level. |
|
|
Reference |
Transformations with respect to half-month. For example:
|
|
|
Reference |
Cumulative time transformations at the half-year level. |
|
|
Reference |
Transformations with respect to half-year. For example:
|
|
|
Reference |
Instance of a handset. |
|
|
Reference |
Models of handsets. |
|
|
Derived |
Daily Aggregate of Handset Stock statistics by CUSTOMER, SALES CHANNEL, and SALES CHANNEL REPRESENTATIVE. |
|
|
Aggregate |
Monthly Summary of Handset Stock statistics by SALES CHANNEL and SALES CHANNEL REPRESENTATIVE. |
|
|
Derived |
Daily summation of handset distributions involving gift, discount, or loyalty voucher points. |
|
|
Aggregate |
Monthly summation of handset distributions involving gift, discount, or loyalty voucher points. |
|
|
Reference |
This entity represents any type of hardware entity that exists as an atomic unit that is not a PHYSICAL LINK or a PHYSICAL CONNECTOR. Hardware is defined as any component that has a distinct physical identity and can be a component of a PHYSICAL DEVICE. An object has a physical identity if it has a physical manifestation that enables it to be held and have a label attached to it. Thus, software, files, protocols, and policies are not physical objects. |
|
|
Reference |
Represents atomic holders of EQUIPMENT that are individually manageable and do not form composite, or nested, Equipment Holders. Each Holder Atomic object can be a FRU. |
|
|
Reference |
Represents Equipment Holders that are made up of other Equipment Holders (that is, instances of this entity and the Holder Atomic entity). This provides the semantics of collecting a set of components, each of which is individually manageable, and being able to manage the set of objects as a whole. This containment is modeled using the Has Holders aggregation. |
|
|
Reference |
The server holding customer account information in Intelligent Network (IN), or Internet Multimedia System (IMS). For example:
|
|
|
Reference |
Hours defined as part of time. |
|
|
Reference |
Captures household information for the household that the individual customer may belong to. |
|
|
Reference |
Subtype of PRODUCT that provides information about IDD service. |
|
|
Base |
Event involving an International Direct Dial (IDD) call. |
|
|
Reference |
IN (Intelligent Network) platforms operated by the telecom service provider. The Prepaid mobile or toll-free business normally relies on IN platform. |
|
|
Derived |
Daily summation of parameters related to the IN PLATFORM functioning and performance on a daily level. |
|
|
Aggregate |
Monthly summation of parameters related to the IN PLATFORM functioning and performance on a monthly level. |
|
|
Reference |
Specifies all the different types of devices, such as VLR, HLR, and SCP servers, which are utilized in a network to decide the call routing in IN Network or Wireless IN Network (IN is Intelligent Network). |
|
|
Reference |
The demographic values for individual customer and customer household. |
|
|
Reference |
Values assigned to user-defined DEMOGRAPHY ATTRIBUTEs. |
|
|
Reference |
Records all names used by the individual party along the history. |
|
|
Lookup |
Lookup for all possible results of initiatives. For example, the result is:
|
|
|
Lookup |
Lookup for available initiative types. |
|
|
Base |
The installment payment scheme for customer bills. |
|
|
Base |
Defined answers, choices, corresponding to initiative questions. |
|
|
Reference |
Channels used for Provider or Customer interactions. For example:
|
|
|
Lookup |
Lookup for available directions for initiatives. For example:
|
|
|
Reference |
The navigation path between each two navigation items. For example, from Welcome Page to Log in page, or from Hot Offering to a specific Product Market Plan advertisement page, and so on. The navigation may change over the time, for example, a product may be on the Hot Offering page for only a short period. |
|
|
Base |
The history of customer navigation path in each interaction call, or web visit. For example, in an IVR call, a customer may go through the following steps:
These actions are realized as three records in the history. |
|
|
Reference |
Specifies all the possible places where customer may go to in the IVR or Web service context. |
|
|
Lookup |
Lookup for the type of Interaction Navigation. For example:
|
|
|
Lookup |
Lookup for the level of Interaction Navigation according to the path depth the item is in. |
|
|
Lookup |
Lookup for the type of INTERACTION NAVIGATION ITEM. For example:
|
|
|
Reference |
Historical versions of INTERACTION NAVIGATION ITEMs. |
|
|
Lookup |
Lookup for the different priorities which can be assigned to each EVENT PARTY INTERACTION. |
|
|
Base |
Responses provided by CUSTOMER to interaction questions. |
|
|
Lookup |
Lookup for interaction reasons. For example:
|
|
|
Lookup |
Lookup for possible responses to customer interaction. For example:
|
|
|
Lookup |
Lookup for available interaction status. For example:
|
|
|
Base |
The history of interaction transfers. |
|
|
Lookup |
Lookup for reasons that an interaction is transferred from one agent to another one. For example:
|
|
|
Lookup |
Lookup for types of interactions between company and CUSTOMER. For example:
|
|
|
Derived |
Daily summary of payment and collection by internal collector. |
|
|
Aggregate |
Monthly summary of payment and collection by internal collector. |
|
|
Base |
Subtype of NETWORK EVENT, which captures customer internet surfing history with detailed URL and time information. |
|
|
Base |
Specifies a unit record of a particular stock ITEM, held in a particular Inventory Location, in a particular Inventory State and controlled or managed by a particular Revenue Center. |
|
|
Base |
Invoices issued to accounts representing request for payment for goods and services for a specified period. |
|
|
Base |
Adjustments made on the INVOICE. |
|
|
Aggregate |
Monthly aggregation of calculated measures for all adjustments made on the INVOICEs. |
|
|
Derived |
Calculated measures for all adjustments made on the INVOICEs. |
|
|
Reference |
Quota of INVOICE ADJUSTMENTs assigned to EMPLOYEE. |
|
|
Lookup |
Lookup for the possible reasons for an adjustment on a customer's or on a partner's bill. For example:
|
|
|
Lookup |
Lookup for available adjustment types that may be applied to customer invoices. For example:
|
|
|
Aggregate |
Monthly aggregation of all INVOICEs to post paid customers at customer type level. |
|
|
Reference |
The format specification, including header, font, and so on, of each invoice delivered to the customer. |
|
|
Lookup |
Lookup for available delivery types of INVOICE to customer. For example:
|
|
|
Base |
Discount applied to INVOICE. |
|
|
Lookup |
Lookup for available discount reasons. |
|
|
Lookup |
Lookup for available discount types that may be applied to customer invoice. |
|
|
Derived |
Statistics on Invoices for further aggregation. Postpaid customers are billed/invoiced for the usage of services on monthly basis, that is, bill for every subscriber based on his package, category, and usage is calculated, printed and sent to the customer account address for payment. |
|
|
Base |
Any line that appears on the INVOICE which is specific to the product components a customer has. The invoice item is not necessarily associated with a monetary charge or a credit (but invoice item usually does have an associated monetary charge or credit). The invoice item is usually a billable item to a given account, onto which usage or other events are charged. The unbillable items that could be part of the invoice item are "Loyalty Points", "Free Unit Amount/Rollover", and so on. For example:
|
|
|
Base |
Additional details regarding INVOICE ITEM including Product Usage Level. |
|
|
Lookup |
Lookup for invoice item detail types (item detail is the description of each column of a given item in a bill). The invoice item detail type may be classified in a mobile line. For example:
|
|
|
Base |
Define the relationship between INVOICE ITEMs. |
|
|
Lookup |
Lookup for invoice item types. For example:
|
|
|
Base |
Matches the payment to an INVOICE. |
|
|
Base |
Payment terms of each INVOICE. For example:
|
|
|
Lookup |
Lookup for available types of payment terms. |
|
|
Base |
Status history for an INVOICE, for example, the invoice may experience a status change from open to closed, or from open to extended. |
|
|
Lookup |
Type of INVOICE status. For example:
|
|
|
Base |
The Tax item applied to the INVOICE. |
|
|
Lookup |
Lookup for type of INVOICE according to invoice generation process. For example:
|
|
|
Reference |
Represents an IP address. The IP Address can be either in v4 or v6 form, and can be formatted as dotted decimal or CIDR. One or more host aliases can also be supplied. |
|
|
Reference |
Subtype of ACCESS METHOD POOL, which lists all IP addresses available to customers. |
|
|
Reference |
A portion of a network that shares a common address component. On TCP/IP networks, subnets are defined as all devices whose IP addresses have the same prefix. For example, all devices with IP addresses that start with 100.100.100 would be part of the same subnet. |
|
|
Reference |
Refines the generic IP ADDRESS to add formatting capabilities that are specific to IPv4. |
|
|
Reference |
Internet Service Provider (ISP). |
|
|
Reference |
The business that the ISP may provide. For example:
This only covers ISP specific business (not Application Provider business). |
|
|
Reference |
Relates an ISP to the Communications Service Provider through a "business" relationship. This entity assigns the definition of the relationship, in entity ISP BUSINESS, with the corresponding ISP. |
|
|
Lookup |
Lookup for high level of ISP business type. For example, Cooper Line Internet Connection (may further divided as DSL, ISDN), Colocation, DNS Name, and so on. For example:
|
|
|
Lookup |
Lookup for types of ISPs. |
|
|
Base |
Records traffic details of each session the user conducts with the Internet Service Provider ISP. The entity documents the connect and disconnect date and time and the number of local and international bytes downloaded, and uploaded. There will typically be multiple rows for each long running session. The entity will be implementation dependent, but normally there will be a record generated each hour, all records for the one session will have the same connect and disconnect date times, but the event start/end datetimes will identify the period that the usage (bytes) covers. |
|
|
Reference |
Identifies the user names associated with the Internet Service Provider (ISP) subscription. |
|
|
Reference |
Details describing the item or PRODUCT. |
|
|
Lookup |
Lookup for type of item (PRODUCT). |
|
|
Base |
Specifies the IVR interaction navigation history. |
|
|
Lookup |
The IVR MENU ITEM, which can be used to construct the whole IVR navigation system. Each IVR MENU ITEM represents a group or a specific business function. |
|
|
Reference |
The occupation of the customer, which is the principal activity the customer performs to earn money. |
|
|
Reference |
Job Roles defined in the company that may be assigned to employees. For example:
|
|
|
Base |
Cross-Reference from GL SUBLEDGER JOURNAL ENTRY LINE to CUSTOMER ORDER LINE ITEM. |
|
|
Base |
Cross-Reference from GL SUBLEDGER JOURNAL ENTRY LINE to INVOICE ITEM. |
Table 2-26 K to N Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Reference |
A measure of a specific aspect of the performance of a SERVICE (network or non-network) or a group of SERVICEs of the same type. |
|
|
Reference |
A measure of a specific aspect of the performance of a product, subscription, or a service. A Key Quality Indicator (KQI) draws data to compute the measure from several sources, including KPIs. |
|
|
Reference |
A Local Area Network (LAN) is a computer network covering a specific local area, such as a home, office, or small group of buildings. The LAN provides communication between computers and devices. |
|
|
Reference |
LAN Protocols operate at the lowest two levels of the OSI model, that is, physical and data link, and are used to define communications over different types of local area media. |
|
|
Lookup |
Languages spoken or written within the company or in interactions with CUSTOMERs. |
|
|
Reference |
A special type of speaking or written language dialect. |
|
|
Reference |
A Layer Network is defined by the complete set of Access Groups of the same type that may be associated for transferring information. The information transferred is characteristic of the layer network and is termed characteristic information. The associations of the trail terminations, that form a trail, in a layer network may be made and broken by a layer network management process thus changing its connectivity. A separate, logically distinct layer network exists for each trail termination type. The topology of a layer network is described by access groups, subnetworks, and the links between them. |
|
|
Lookup |
Lookup for various states which a legal process could be in, as part of a party interaction (usually after an inability to find an agreement to pay debts). |
|
|
Lookup |
Lookup for available types of letters that may be sent to CUSTOMERs. For example:
|
|
|
Derived |
Statistics for the number of lines activated and terminated every day for each ORGANIZATION BUSINESS UNIT. |
|
|
Aggregate |
Monthly aggregation of numbers of lines activated and terminated for each ORGANIZATION BUSINESS UNIT. |
|
|
Reference |
The local place within a given geographical address location to locate a specific object, such as a NETWORK ELEMENT. |
|
|
Reference |
This entity represents the minimum and maximum requirements, limits, or other variable features of different types of Managed Entities. |
|
|
Reference |
This entity represents logical concepts and services that can be managed that are associated with the device as a whole. Logical Device represents a convenient aggregation point for combining different aspects of a device (For example, software contained in the device, protocols that the devices runs, the set of services that it offers, and so forth). The Logical Device also enables the device itself to have a single logical manifestation. Conceptually, this represents the "brains" of the Device. For example, the Logical Device represents the set of entities required for a ROUTER to know how to route packets. |
|
|
Reference |
Entity for representing logical concepts and services that can be managed which are associated with the device as a whole. Represents a convenient aggregation point for combining different aspects of a device (For example, software contained in the device, protocols that the devices runs, the set of services that it offers, and so forth). The Logical Device Atomic also enables the device itself to have a single logical manifestation. Represents all logical devices that are atomic in nature (For example, not made up of multiple distinct logical devices that can be separately managed). |
|
|
Reference |
Entity for representing logical concepts and services that can be managed which are associated with the device as a whole. Represents a convenient aggregation point for combining different aspects of a device (For example, software contained in the device, protocols that the devices runs, the set of services that it offers, and so forth). The Logical Device Composite also enables the device itself to have a single logical manifestation. Represents all logical devices that are composite in nature (For example, made up of multiple distinct logical devices that can be separately managed). The composite pattern enables Logical Device Composite objects to be made up of LOGICAL DEVICE objects (that is, either LOGICAL DEVICE ATOMIC and/or Logical Device Composite objects). |
|
|
Reference |
This is an association class, and defines the semantics of the Logical Device Uses OS association. This is a complex class, and consequently only a few simple attributes are shown in this viewpoint in order for the reader to get a flavor of the types of parameters defined in this class. |
|
|
Reference |
Defines required logical features to implement the different roles played by different LOGICAL DEVICEs that are used in a PRODUCT or SERVICE. |
|
|
Reference |
Entity for all Logical Device Role Specifications. The Logical Device Role Spec entity enables relationships to be defined between it and other classes in the core model. This helps prevent relationship explosion. The Logical Device Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with LOGICAL DEVICEs in the model. |
|
|
Reference |
This entity describes different logical aspects of devices (For example, DEVICE INTERFACEs) that constitute a PRODUCT. The Logical Element has two main purposes.
|
|
|
Reference |
This is an association entity defined in the LOGICAL ELEMENT model. The Logical Element Physical Support represents the semantics. For example, depends on, uses, and other relationships, that exist when one or more LOGICAL ELEMENTs are used to support a PHYSICAL ELEMENT. This entity should be extended to model the particular semantics involved. When extended, the type OfDependency attribute must be included, since it is a mandatory attribute. However, new values may be added to its enumerated list of values. |
|
|
Reference |
This entity defines the concept of various types of roles that can be associated with LOGICAL ELEMENTs. |
|
|
Reference |
Implements the semantics of the Roles Describe Logical Element aggregation. |
|
|
Reference |
Entity for all LOGICAL ELEMENT ROLE specification subclasses. The Logical Element Role Spec enables relationships to be defined between it and other classes. This helps prevent relationship explosion. The Logical Element Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with LOGICAL ELEMENTs. |
|
|
Lookup |
This entity defines the invariant characteristics and behavior (attributes, methods, constraints, and relationships) of a LOGICAL ELEMENT. |
|
|
Lookup |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building LOGICAL ELEMENT objects. The purpose of this entity is to track specifications of LOGICAL ELEMENTs separately from other types of Element Specifications. This entity inherits the Modifies Element Spec aggregation, and therefore can be used with the corresponding LOGICAL ELEMENT entity. The difference between this entity and the Logical Element Type Composite entity is that this entity represents standalone specifications of LOGICAL ELEMENT objects. The Logical Element Type Composite entity represents a hierarchy of specifications of LOGICAL ELEMENT objects. |
|
|
Lookup |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building LOGICAL ELEMENT objects. The purpose of this entity is to track specifications of LOGICAL ELEMENT separately from other types of Element Specifications. This entity inherits the Modifies Element Spec aggregation, and therefore can be used with the corresponding LOGICAL ELEMENT entity. The difference between this entity and the Logical Element Type Atomic entity is that this entity represents a hierarchy of specifications for LOGICAL ELEMENTs. The Logical Element Type Atomic entity represents a single standalone specification of a LOGICAL ELEMENT. |
|
|
Reference |
This defines the invariant attributes, methods, constraints, and relationships that exist between a particular Logical Element Type and the PHYSICAL ELEMENT SPEC that it depends on. |
|
|
Reference |
The purpose of this entity is to track Logical Element Type specifications separately from other types of Element Specifications. This entity inherits the modifiesElementSpec aggregation, and therefore can be used with the corresponding Logical Element Type specification entity. |
|
|
Reference |
An abstract entity that serves as the superclass for all virtual interfaces. Logical interfaces are also called virtual interfaces. This is because a logical interface has no hardware associated with it, and a logical interface is not physically connected to a network. A logical interface serves as a convenient aggregation point for running different relationships that affect its subclasses, thereby avoiding having to instantiate multiple relationships that are essentially the same. |
|
|
Lookup |
Abstract ENTITY for all lookup entities. |
|
|
Reference |
Loyalty programs available to which customers may be members of. |
|
|
Reference |
Channel through which a customer can join, change, or redeem the loyalty program. For example:
|
|
|
Derived |
Daily aggregate of LOYALTY PROGRAM statistics by CUSTOMER, PRODUCT, SALES CHANNEL, LOYALTY PROGRAM CHANNEL, SALES CHANNEL REPRESENTATIVE, AGE ON NET BAND, CREDIT CATEGORY. |
|
|
Lookup |
Lookup for the types of award updates that can be given to the PARTY. For example:
|
|
|
Lookup |
Lookup for types of LOYALTY PROGRAM events that could be used in a LOYALTY PROGRAM. |
|
|
Aggregate |
Monthly summary of LOYALTY PROGRAM statistics by PRODUCT, SALES CHANNEL, LOYALTY PROGRAM CHANNEL. |
|
|
Lookup |
Lookup for available roles or responsibilities that may be assigned to a PARTY participant of a LOYALTY PROGRAM. For example:
|
|
|
Base |
Balance points awarded to a PARTY in a LOYALTY PROGRAM. |
|
|
Lookup |
Reasons why a customer terminated the participation of a given LOYALTY PROGRAM. |
|
|
Reference |
Mailbox allocated to a CUSTOMER. |
|
|
Lookup |
Lookup for type of management action that can be performed on a product market plan. For example:
|
|
|
Reference |
This is an abstract entity that represents entities in a managed environment that have the following semantics in common: |
|
|
Reference |
This entity adds additional semantics to the Hardware base entity. These semantics provide management information on the hardware. For example, attributes defined by this entity can provide the administrative and operational state of the entity, and tell whether it has any alarms. |
|
|
Reference |
This entity describes different types of logical entities that are or help form connections that transmit and/or receive information. This represents a superclass to various ITU specs (For example, G.805 and M.3100) and the IETF concepts, such as those found in various RFCs, so that it can unite ITU and IETF concepts. |
|
|
Reference |
Represents a special grouping of ENTITYs that has two important properties. First, it is used to partition managed objects into a meaningful logical grouping. Second, it provides a means to show how management functions are distributed and scaled. |
|
|
Reference |
A Management Protocol is an abstract superclass for protocols that are dedicated to exchanging management information between network devices. This type of protocol is an application layer protocol, and is used for configuring, monitoring, and gathering information about devices. |
|
|
Lookup |
Lookup for marital status that may be assigned to an individual. |
|
|
Reference |
A geographic area or region or other connotation for which demographic data are available. |
|
|
Reference |
Hierarchical levels of market area. |
|
|
Derived |
Monthly porting count between operators. Provides summary information about succeeded Number Porting between operators. |
|
|
Reference |
Defines the customer document requirements of each PRODUCT MARKET PLAN. |
|
|
Base |
The management history of market plan by the employee. |
|
|
Reference |
Stores the document that allows the customer to access a market plan specific to a certain category of customers (such as Students, Seniors, or unemployed). These market plans usually require a document that proves the validity of the request (for example, income certification or identification documents) that this entity stores. |
|
|
Reference |
The detail term value according to each term for the market plan, including monthly charge. |
|
|
Reference |
A grouping of Parties, Geographic Areas, Sales Channels, and so forth. MARKET SEGMENTs are the target of Marketing Campaigns, PRODUCT MARKET PLAN, Product Promotions, Product Placements, and Product Programs from both internal and external, COMPETITORs, and other Providers, perspective. |
|
|
Reference |
A characteristic quality or distinctive feature of a MARKET SEGMENT. The characteristic can be take on a discrete value, such as sex, can take on a range of values, (for example, household income of $50,000 - $100,000), or can be derived from a formula (for example, number of households = number of customer party roles). |
|
|
Reference |
A number or text that can be assigned to a MARKET SEGMENT CHARACTERISTIC. |
|
|
|
Reference |
The inclusion relationship between two MARKET SEGMENTs. |
|
Aggregate |
Defines the market information. Monthly summation of Geographic Market Share for a PRODUCT MARKET PLAN. |
|
|
Derived |
Defines the market information. Sales Revenue by Month, Address, and Business Unit. |
|
|
Reference |
A categorization of performance measures by MARKET SEGMENT. PERFORMANCE is measured for the Service Provider and a Service Provider's COMPETITORs in the market place. |
|
|
|
Reference |
Relationship between two market statistics. |
|
Reference |
This entity serves as the superclass for all virtual interfaces. Logical Interfaces are also called virtual interfaces. This is because a Logical Interface has no hardware associated with it, and it is not physically connected to a network. The Media Interface serves as a convenient aggregation point for running different relationships that affect its subclasses, thereby avoiding having to instantiate multiple relationships that are essentially the same. |
|
|
Reference |
Any form of media in which a CAMPAIGN MESSAGE may appear. For example:
|
|
|
Reference |
Relation of one MEDIA OBJECT to another MEDIA OBJECT. |
|
|
Base |
Costs incurred in the usage of a MEDIA OBJECT. Subtype of the COST that collects all costs related to a specific media (Newspaper, Television spots, Fliers, and so on). |
|
|
Lookup |
Lookup for available types of MEDIA OBJECTs. For example:
|
|
|
Base |
The mediated call event with original device information, dropped call, and missed call information, which is normally ignored by rating engine. The call event are collected before the calls are rated by rating engine. |
|
|
Lookup |
Lookup for category of mediation status, such as successfully mediated or failed. |
|
|
Lookup |
Lookup for reasons why the network event is at certain mediation status. For example:
|
|
|
Lookup |
Lookup of the mediation status of a given raw network event. For example:
|
|
|
Reference |
Defines minutes as part of time. |
|
|
Base |
Subtype of Account Balance describing the number of 'Free' or 'Prepaid' minutes allocated to Subscriber in a given month. |
|
|
Reference |
Subtype of VALUE ADDED SERVICE and PRODUCT, which contains the information relative to the Multimedia Messaging Service (MMS). Do not confuse with the MMS EVENT itself. |
|
|
Base |
Subtype of NETWORK EVENT, which collects all information of calls of type Multimedia Messaging Service (MMS). |
|
|
Reference |
The Mobile Switching Center (MSC) is a sophisticated telephone exchange which provides circuit-switched calling, mobility management, and GSM services to the mobile phones roaming within the area that it serves. This includes voice, data and fax services, and SMS and call divert services. |
|
|
Lookup |
Lookup for the model types of items. There may be different "types" for a given model. For example, for a handset a model may allow "Bluetooth" or not. |
|
|
Reference |
Defines related calendar elements for performing to-date time transformations. |
|
|
Reference |
Transformations with respect to a month. For example:
|
|
|
Derived |
Parameters, configurations, and runtime statistics related to the MSC (Mobile Switch Center) functioning and performance. |
|
|
Aggregate |
Monthly aggregation of parameters, configurations, and runtime statistics related to the MSC (Mobile Switch Center) functioning and performance. |
|
|
Reference |
Subtype of VALUE ADDED SERVICE and PRODUCT, which contains the information relative to the music downloading service. |
|
|
Reference |
Specifies classifications in the North American Classification System (NAICS). |
|
|
Reference |
Lowest level classification for Industry in the North American Industry Classification System (NAICS). |
|
|
Reference |
Lookup for Classification Groups in the North American Industry Classification System (NAICS). |
|
|
Reference |
Lookup for Industry Sectors in the North American Industry Classification System (NAICS). |
|
|
Reference |
Lookup for Industry Sub-sectors in the North American Industry Classification System (NAICS). |
|
|
Lookup |
Lookup for available nationalities. |
|
|
Reference |
The negotiated service level spec, compared to predefined SLA spec. |
|
|
Reference |
Names and Service Providers for relevant Networks. The full details of a service provider are found in the PARTY and Organizations entities. A Network is a managed object that represents an aggregation of interconnected telecommunications and management objects capable of exchanging information. The reason that a Network is subclassed from Element Collection is that it is important that a Network represents physical and logical characteristics and behavior of this collection of telecommunications and management objects. A Network has the additional semantics of having one or more common characteristics and/or behavior. For example, a network may be owned by a single customer or provider, or be associated with the delivery of a specific set of services. A network may be nested within another (larger) network, thereby forming a containment relationship. An example of a network that is contained in another network is a transmission sub-network. The Network is owned by a single Administration and can only perform transmission functions. |
|
|
Reference |
Represents the generic concept of a network address. The Network Address subclasses define different types of addresses of different technologies, such as an IP ADDRESS or an IPXAddress. The use of a Network Address lies in its ability to serve as a convenient point for sourcing and terminating relationships. This eliminates undue duplication of relationships that interact with the subclasses of NETWORK ADDRESS. |
|
|
Reference |
Defines the semantics of how this NETWORK ADDRESS is contained in this particular DEVICE INTERFACE. |
|
|
Lookup |
Lookup for the type of network addresses, that is, the invariant characteristics that define a NETWORK ADDRESS. For example, IPv4, IPv6, IPX, and so on. |
|
|
Reference |
Defines the relationship between NETWORKs. For example:
|
|
|
Lookup |
Lookup for type of network relationship. For example:
|
|
|
Reference |
Represents a standalone Network. Network Atomics may be combined into larger Networks by aggregating them into an appropriate Network Composite object. |
|
|
Derived |
Statistics of network availability measures and all outages that happened to the operator's network. |
|
|
Aggregate |
Monthly aggregation of network availability statistics and all outages that happened to the operator's network. |
|
|
Reference |
The network capacity of a given network route, trail, or connections. |
|
|
Reference |
Represents an aggregation of Network Atomic and possibly Network Composite objects. Each Network Atomic object represents a standalone Network; these can be combined to build larger Networks by choosing the appropriate type of Network Composite object to aggregate Network Atomic objects. Note that a Network Composite object can also aggregate Network Composite objects. |
|
|
Reference |
A Network Domain represents a set of Managed Physical Entities that share a common set of administrative and operational characteristics. Primary among these is the use of a common naming methodology. A Network Domain partitions Managed Entity instances into logical groupings. For example, operational and/or administrative groups, that are controlled by one or more common managers. Network Domains provide one way to administer and control the operational characteristics of a set of Managed Entities. |
|
|
Reference |
Assigns NETWORK ELEMENT into NETWORK DOMAIN. |
|
|
Reference |
All elements belonging to the network (normally, only of the Communications Service Provider) to deliver the communication services. |
|
|
Reference |
The business interaction role which can be assigned by a NETWORK ELEMENT. |
|
|
Lookup |
Category of network elements to further classify NETWORK ELEMENT TYPEs. |
|
|
Base |
Subtype of the COST, which associate a specific cost to a given NETWORK ELEMENT (purchase, maintenance, recycling, and so on). |
|
|
Base |
Assignment of a NETWORK FAULT to a SUBSCRIPTION. |
|
|
Reference |
Defines the semantics of the Owns Element association. In contrast with the Administers Element association, this can be any type of PARTY ROLE, because the issue is ownership, not administration. Administration involves a specific skill set, whereas ownership does not. The semantics of this association includes specifying the time period that this PARTY ROLE can own the Element, along with granting permission to a Value Network Role to administer the Element. |
|
|
Reference |
Defines the relationship between party and its managed NETWORK ELEMENT. |
|
|
Reference |
Defines the semantics of the Administer Element association. This defines that a Value Network Role, and not just any type of PARTY ROLE, is allowed to Administer a Device. The semantics of this association includes specifying the time period that this Value Network Role can administer the Element, along with gaining permission from the Owner of the Element for being able to administer the Element. |
|
|
Reference |
The relationship between two NETWORK ELEMENTs. For example, in GSM, multiple BTSs are connected to a BSC, in Broadband, several customer lines may be connected to a DSLAM. |
|
|
Lookup |
The Type of NETWORK ELEMENT RELATIONSHIP. For example:
|
|
|
Reference |
This entity defines the concept of various types of roles associated with Resources (both physical and logical). |
|
|
Reference |
Implements the semantics of the Network Element Takes On Roles relationship. The Network Element Role Assignment also serves as the parent entity for defining the classes that implement the Roles Describe Physical Element, Roles Describe LOGICAL ELEMENTs, and Roles Describe Compound Element relationships. |
|
|
Reference |
Defines the semantics of the Element Roles Managed By Party Role association. The Element Roles Managed By Party Role association defines the set of Element Roles that are managed by a particular PARTY ROLE. Oftentimes, there are important functional differences between different types of Elements that require very different skill sets, methods, and so forth to be used by the PARTY ROLE that is managing that Element. For example, different management personnel may be assigned to manage core routers compared to edge routers. This applies not just to the router as a whole, but to its physical, for example, line cards, and logical. For example, DEVICE INTERFACEs, components. The Network Element Role Party Assignment entity captures these semantics. |
|
|
Reference |
This is the abstract base entity for all Element Role Specification subclasses. The Network Element Role Spec enables relationships to be defined between it and other network element roles. This helps prevent relationship explosion. The Network Element Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with Elements (both physical and logical). |
|
|
Base |
Network element State History tracks the state history of each NETWORK ELEMENT, for example, power off, in use, decommissioned, and so on. |
|
|
Lookup |
Lookup for reasons why the NETWORK ELEMENT is at certain state. For example:
|
|
|
Lookup |
Lookup of the NETWORK ELEMENT STATE of a given NETWORK ELEMENT. For example:
|
|
|
Reference |
This entity defines the invariant characteristics and behavior (attributes, methods, constraints, and relationships) of a Managed Element. |
|
|
Reference |
Represents the ability to distinguish between different instances of Element Specifications. The Network Element Type Version represents a particular form or variety of a Element Specification that is different from others or from the original. The form represents differences in attributes, methods, relationships, and/or constraints that characterize this particular Element Specification, but which are not enough to warrant creating a new Element Specification. |
|
|
Reference |
Defines the semantics of the modifiesElementSpec aggregation. Specifically, it enables an application to define which set of versions of this Element Specification are appropriate for a given task. |
|
|
Reference |
An occurrence of employing a Element for its intended purpose. |
|
|
Lookup |
A detailed description of a network element usage event (for example, a purchase or a lease of a resource). |
|
|
Base |
Abstracted event for all events that happened to the operator network because of customer usage; network events are usually the basis for customer billing. |
|
|
Base |
The balance impact of a given NETWORK EVENT on ACCOUNT BALANCE BUCKET. For example, one voice call leads to deduction of 10 cents from the account balance bucket of: "USD 100 effective 20110101, expire 20120101". |
|
|
Base |
How the NETWORK EVENT impacts the account balance. For example, one voice call leads to a deduction of 10 cents from Cash Account balance. |
|
|
Base |
Defines the relationship between one NETWORK EVENT and another NETWORK EVENT. |
|
|
Reference |
A detailed description of an attribute that defines a particular type of NETWORK EVENT, described by its name, category, type, presence, and a set of allowed values. |
|
|
Reference |
How the NETWORK EVENT type utilize a characteristic. |
|
|
Reference |
The relationship between NETWORK EVENT CHARACTERISTICs, such as aggregation, migration, substitution, dependency, or exclusivity. |
|
|
Reference |
A category representing a high-level aspect of the network event information described by the characteristic. |
|
|
Reference |
A value of a NETWORK EVENT CHARACTERISTIC that represents an attribute value for the event. |
|
|
Reference |
A use of the Characteristic Value by a NETWORK EVENT to which additional properties, attributes, apply or override the properties of similar properties contained in NETWORK EVENT CHARACTERISTIC VALUE. |
|
|
Reference |
The relationship between or among NETWORK EVENT CHARACTERISTIC VALUEs, such as aggregation, migration, substitution, dependency, or exclusivity. |
|
|
Lookup |
Lookup for possible status of NETWORK EVENTs. For example:
|
|
|
Lookup |
Lookup for available types of NETWORK EVENTs. |
|
|
Reference |
A particular form or variety of a NETWORK EVENT TYPE that is different from others or from the original. The form represents differences in properties that characterize a NETWORK EVENT TYPE, that are not enough to warrant creating a new NETWORK EVENT TYPE. |
|
|
Base |
Records each registered fault. |
|
|
Lookup |
The different priorities which can be assigned to each NETWORK FAULT. |
|
|
Base |
The services may be affected by the NETWORK FAULT. |
|
|
Base |
The status history of a NETWORK FAULT. For example:
|
|
|
Base |
Links a network issue to all subscriptions impacted, which allows you to list the customer and service impacted by a network fault. |
|
|
Reference |
Defines a series of locations a network route may pass. |
|
|
Reference |
The points a NETWORK ROUTE may pass through. |
|
|
Reference |
Assignment of NETWORK ROUTE POINTs to their NETWORK ROUTE. Multiple NETWORK ROUTEs may share the same NETWORK ROUTE POINT. |
|
|
Reference |
Defines the relationship between NETWORK TOUCHPOINT and SERVICE COVERAGE AREA. |
|
|
Reference |
Specifies a place where NETWORK ELEMENTs are located or installed. |
|
|
Reference |
Point of service site for a subscriber to access a CELL SITE or FIXED LINE PORT. The site is a geographical point instead of area, therefore, it belongs to some geographical entity. For example, a city or a town rather than a type of the GEOGRAPHY ENTITY. For example:
|
|
|
Lookup |
Lookup for available classes of NETWORK TOUCHPOINT. For example:
|
|
|
Aggregate |
Monthly summary of NETWORK TOUCHPOINTs by CUSTOMER, NETWORK, Address, and so on. |
|
|
Derived |
Monthly summary of NETWORK TOUCHPOINTs by NETWORK, County, and so on. |
|
|
Lookup |
Lookup for Available Status codes and descriptions of NETWORK TOUCHPOINT. |
|
|
Lookup |
Lookup for the type of NETWORK TOUCHPOINT. For example:
|
|
|
Lookup |
Lookup for the types of NETWORK. Will include:
|
|
|
Lookup |
Lookup for types of notification a subscriber may receive when a call is received by or diverted to a UMS or VMS mailbox. For example:
The UMS Notification Type dimension helps to organize the notifications data by notification type, along with other dimensions. |
|
|
Reference |
The mobile MSISDN number of ported number. |
|
|
Base |
The Number Porting (NP) Request submitted by a customer (Porting In) or a recipient operator (Porting Out). |
|
|
Base |
Request Line Item within a Number Porting (NP) request. |
|
|
Base |
State history for Number Porting (NP) request line items. |
|
|
Lookup |
Lookup for type of Number Porting (NP) line item state. For example:
|
|
|
Base |
State history for the Number Porting (NP) request. |
|
|
Lookup |
Lookup for type of state for Number Porting (NP) request. For example:
|
|
|
Lookup |
Lookup for type of Number Porting (NP) Request. For example:
|
|
|
Lookup |
Step involved in the Number Porting (NP) request. For example:
|
|
|
Reference |
Defines the codes associated to a given area; these codes are typically used for calls to a fixed line number. For example:
A number area could also be associated to other operators, and not to a geographical area. For example, 9 in France. |
|
|
Reference |
Country number. For example:
|
|
|
Lookup |
Lookup for available classifications for the network technology, used in relation to subscriptions. For example:
|
|
|
Derived |
Aggregation of daily Porting Requests (in/out). |
|
|
Aggregate |
Monthly summary of Porting Requests (in/out). |
Table 2-27 O to R Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Lookup |
Lookup of call classifications:
|
|
|
Reference |
An Operating System is a concrete entity that represents either software and/or firmware that runs the LOGICAL ELEMENT. This entity implements and/or manages the Elements, tasks, file systems, security, and data available on the LOGICAL ELEMENT. Note that an Operating System is distinct from software applications that are run on the Element. All applications and software must communicate with the Operating System for all operations that they need. |
|
|
Lookup |
Classification group for operators. For example, the group can be classified as:
|
|
|
Lookup |
Lookup for operator type to classify operators. For example:
International operators normally have multiple subsidiaries whose relationship is modeled in the party relationship. |
|
|
Reference |
Provides geometry information. |
|
|
Reference |
Lookup for the status that a given order line item, in a command, can be assigned. For example:
|
|
|
Lookup |
Lookup for the type of Order State. For example:
|
|
|
Lookup |
Lookup for the type of Order Status. For example:
|
|
|
Lookup |
Lookup for type of CUSTOMER ORDER. For example:
|
|
|
Reference |
An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION CHAIN. The Organization Area entity is the parent of one or more ORGANIZATION REGIONs. |
|
|
Reference |
The name of Company, Organization, or subsidiary that is recognizable to the consumer or the name of the store as it appears on the catalog, web channel, or brick and mortar store. |
|
|
Reference |
Any logical entity that is a part of the enterprise for business analysis and transactions. Classification for a business entity can include company, operation unit, store, or warehouse. |
|
|
Reference |
A business unit of the organization that delivers a limited range of specific communications services or merchandise through any sales channel (Web Site, store, partner stands, and so on). For example, for the SuperTelco example, two Business Units could be defined as:
|
|
|
Base |
Sub-table of COST. This entity associates a specific cost to an ORGANIZATION BUSINESS UNIT (for those costs not covered by EMPLOYEE COST). |
|
|
Lookup |
Lookup for type of ORGANIZATION BUSINESS UNIT. For example:
|
|
|
Reference |
An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION COMPANY. Organization Chain entity is the parent of one or more ORGANIZATION AREAs. |
|
|
Reference |
An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION CORPORATE. Organization Company entity is the parent of one or more ORGANIZATION CHAINs. |
|
|
Reference |
Highest level of ORGANIZATION HIERARCHY. Organization Corporate entity is the parent of one or more ORGANIZATION COMPANYs. |
|
|
Reference |
An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION REGION. Organization District entity is the parent of one or more ORGANIZATION BUSINESS UNITs. |
|
|
Reference |
An ORGANIZATION HIERARCHY LEVEL within ORGANIZATION CORPORATE. |
|
|
Reference |
User defined. Master list of all of the hierarchies in an organization. |
|
|
Reference |
The association entity for the hierarchies and levels. |
|
|
Reference |
Assignment of Hierarchy Levels to ORGANIZATION HIERARCHY. |
|
|
Reference |
Version of ORGANIZATION HIERARCHY. |
|
|
Reference |
Associate selling price to the item. Each organization might have different prices for the same item model. |
|
|
Reference |
List of all the business levels within an organization. |
|
|
Reference |
Values for the user defined attributes associated with an ORGANIZATION HIERARCHY LEVEL. |
|
|
Reference |
Attributes assigned to an ORGANIZATION LEVEL. |
|
|
Reference |
Publicly available and statistical information regarding the internal or external parties, such as DUNS number and number of employees. |
|
|
Reference |
Different types of organization names represent the associated business legal status of their organization. |
|
|
Reference |
An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION AREA. Organization Region entity is the parent of one or more ORGANIZATION DISTRICTs. |
|
|
Reference |
Subtype of the ORGANIZATION BUSINESS UNIT. This entity collects all information on Web sites managed by the operator. This normally includes only public information. |
|
|
Reference |
Location in which goods or merchandise (routers, handsets, computers, and so on) are stored but not sold, before they are sent to the shops or utilized by CSP. For example:
|
|
|
Reference |
User defined attribute definitions and corresponding values regarding demographic statistics as related to an ORGANIZATION BUSINESS UNIT. |
|
|
Reference |
Defines the semantics of the Party Role Licenses OS association. The OS License Assignment attributes help specify the licensing details for this particular OPERATING SYSTEM instance. |
|
|
Reference |
Individual associated with a PARTY organization, other than those defined such as CUSTOMER or EMPLOYEE. |
|
|
Reference |
Defines required logical features to implement the specific role of a P (Provider Core) device, as used in a PRODUCT or SERVICE. |
|
|
Base |
The payment made to the partners, such as vendors, dealers, and so on. The partners may also have accounts in the source system such as Oracle BRM, therefore, this payment may refer to that account. |
|
|
Lookup |
Lookup for types of partner payment transactions. For example:
|
|
|
Reference |
Assigns costs of a given PROMOTION to a Partner or PARTY participating in the promotion. |
|
|
Aggregate |
The monthly summary of financial settlement activities that have happened to partners at higher level. |
|
|
Derived |
Financial settlement activities that have happened to each partner within the month. |
|
|
Lookup |
Lookup for valid reason codes for a partner settlement. |
|
|
Reference |
A party is a real person, organization, branch, subsidiary, legal entity, holding company, or some other entity. Any real thing that you would want to put a name to is a party. The attributes of a party are universal. In other words, they are independent of your selling, or ultimately buying relationship with the party. A party is not necessarily a customer. A party can represent prospects and parts of an ORGANIZATION HIERARCHY, including branches, head offices, corporate conglomerates, that may not necessarily have a billing relationship with the company. Any party that has an active account can be considered a customer. Historical information concerning the party is available in the Parties History. |
|
|
Reference |
Assignment of a PARTY to an ACCOUNT. Depending on type of party, the relationship can be:
|
|
|
Lookup |
Lookup for type of relationship between PARTY and ACCOUNT. Depending on type of party, the relationship can be:
|
|
|
Reference |
Associates one or more Addresses with a PARTY. |
|
|
Base |
The assignment history among ACCESS METHOD, PRODUCT MARKET PLAN, and PARTY. |
|
|
Base |
The status history of assignment among PARTY, ACCESS METHOD, and PRODUCT MARKET PLAN. |
|
|
Reference |
Association of a PARTY with one or more other Parties. The relationships may include relationships between customers or between customers and the telecommunications operator. An example of the later type of relationship, are account management portfolios where an account manager will have a relationship with one or more customers. |
|
|
Lookup |
Lookup for valid reasons parties may be associated with each other. For example:
|
|
|
Lookup |
Lookup for the type of the party relationship. For example:
|
|
|
Reference |
The business interaction role which can be assigned by a PARTY. |
|
|
Reference |
Contact information for a party. |
|
|
Lookup |
Lookup for the type of contact information. For example:
|
|
|
Lookup |
Relationship between PARTY and CONTACT LIST. For example, a party belongs to a contact list. |
|
|
Lookup |
The Role of the PARTY in a CONTACT LIST. |
|
|
Reference |
||
|
Lookup |
Lookup for valid Roles that Parties may be assigned in PARTY CONTRACT ASSIGNMENT. |
|
|
Lookup |
Lookup for type of the PARTY CONTRACT ASSIGNMENT. For example:
|
|
|
Base |
Assignment of cost items to a PARTY. One party may incur multiple costs. For example, for a customer acquisition the customer might be given any of the following items that lead to costs:
Cost might be assigned to multiple parties. For example, for operational cost several organizations may share the same expense on a PROMOTION or CAMPAIGN. |
|
|
Reference |
A demographic profile for a PARTY. |
|
|
Reference |
Defines individual and organization demography value for a given party demographic profile. |
|
|
Lookup |
Lookup for valid EVENT TYPEs that may be assigned to a party profile for the various event types that may be actioned against a party. |
|
|
Reference |
Assigns a PARTY to one or more GEOGRAPHY ENTITYs. |
|
|
Reference |
Identifying information unique to a PARTY. |
|
|
Lookup |
Lookup for valid types of PARTY IDENTIFICATION. For example:
|
|
|
Base |
Grouping of related contact events with a PARTY into a single thread. |
|
|
Base |
The relationship between a PARTY INTERACTION THREAD and the involved SUBSCRIPTIONs. |
|
|
Lookup |
The type of PARTY INTERACTION THREAD. For example:
|
|
|
Reference |
Keeps the language capability score for each party. |
|
|
Lookup |
Lookup for available reason code and description for why a PARTY may be assigned to an address. For example:
|
|
|
Lookup |
The type of relationship between the PARTY and the address. For example:
|
|
|
Reference |
Identifies the LOYALTY PROGRAMs that each customer is enrolled in. |
|
|
Lookup |
Defines all roles which a party plays in a CAMPAIGN, such as management or potential customer. |
|
|
Reference |
Assigns a PARTY to the market segment it belongs to. |
|
|
Reference |
Lists any other known names from the life history of a given party. |
|
|
Base |
Assignment of PARTY to a given Order. For example:
|
|
|
Lookup |
Lookup for available assignment type codes and descriptions pertaining to PARTY ORDER ASSIGNMENT. For example:
|
|
|
Reference |
The characteristic a party profile may take. For example, age, education, and so on. |
|
|
Reference |
The actual value for each PARTY PROFILE CHARACTERISTIC on the party profile. |
|
|
Base |
Response of a PARTY to a PROMOTION. Records the customers response result to the initiative. For example, positive responses:
|
|
|
Lookup |
||
|
Reference |
Assigns party roles for the party. PARTY and PARTY ROLE are an X-X relationship. This relationship may change due to a contract change, or for other reasons. |
|
|
Reference |
Defines the semantics of the Party Role Uses Processes association. Since different PARTY ROLEs have different privileges for working on and running the OPERATING SYSTEM, an association class is needed to accurately model these details. |
|
|
Reference |
Status history of each role that a PARTY has taken. |
|
|
Lookup |
Method used to create the segment, such as K-means clustering in Data Mining. |
|
|
Reference |
||
|
Lookup |
Lookup for valid roles and descriptions a PARTY may be assigned for a SERVICE. For example:
|
|
|
Lookup |
Lookup for available reasons for a PARTY and SERVICE relationship. |
|
|
Reference |
||
|
Lookup |
||
|
Reference |
Defines skills with a score and skill level to each PARTY. |
|
|
Lookup |
Higher level of Party Status. For example:
|
|
|
Lookup |
Lookup for valid reasons that may be assigned for a Party Status change. For example:
|
|
|
Base |
Defines current PARTY status history regarding what Operator may be interested. Historical information captured for all lifetime of the customer or dealer. This information may be calculated from internal data; for example, from a payment, or this information may be obtained from an external source such as a credit rating agency. |
|
|
Lookup |
Lookup for status type of the PARTY. For example:
Credit Class is used to rank Customer Credit. For example, the entity value can be:
Or the customer may be defined as:
The party's credit is based on the underlying accounts held by the party. |
|
|
Reference |
Defines a PARTY's relationship to a SUBSCRIPTION. For example: a customer owns a subscription. |
|
|
Lookup |
Lookup for valid Roles that may be assigned to PARTY in regards to the SUBSCRIPTION. |
|
|
Lookup |
Lookup for party type that classifies involved parties according to their inherent characteristics and structure. For example:
|
|
|
Reference |
The passport as a type of PARTY IDENTIFICATION. |
|
|
Lookup |
Lookup for type of pay category on a pay slip. For example:
|
|
|
Reference |
Subtype of PRODUCT. Pay TV is subscription-based product to deliver TV channels to a customer. |
|
|
Lookup |
Lookup for the type of payment made to the employee. For example:
|
|
|
Lookup |
The classification of accounts according to payment delay history. For example:
|
|
|
Derived |
Customer Debt aging results for a DAY. Customer Debt is assigned to a predefined AGE BAND. |
|
|
Aggregate |
Monthly summary of customer debt aging. |
|
|
Reference |
Channel by which customer may pay for service. For example:
|
|
|
Lookup |
Lookup for valid methods of payment. For example:
|
|
|
Lookup |
Lookup for type codes and descriptions for transaction types associated with the ACCOUNT PAYMENT. The payment may be, for example:
|
|
|
Lookup |
Lookup for reasons for a Packet Control Unit (PCU) outage in GPRS technology. For example:
|
|
|
Reference |
Defines required logical features to implement the specific role of a PE (Provider Edge) device, as used in a PRODUCT or SERVICE. |
|
|
Lookup |
The definition of the time slots is usage dependent, but it is not common for all the products/packages. The time hours (Peak, off-peak, and night) can be different for different packages. The definition also varies for the following:
For the special days defined in the system. |
|
|
Reference |
A measure of the manner in which a SERVICE and/or Element is functioning. |
|
|
Reference |
The time of day or days during which a PERFORMANCE SPECIFICATION is measured or not measured. |
|
|
Reference |
A value of a Characteristic Specification provided for PERFORMANCE CATEGORY that further defines what the PERFORMANCE CATEGORY is. |
|
|
Reference |
A specification for an association that can be established between two instances of PERFORMANCE CATEGORYs. For example, a relationship can be established between a Codec instance and Bearer Type instance. |
|
|
Reference |
The invariant characteristics that define a group or set of performance qualities that are classified together because of common characteristics. |
|
|
Reference |
A group or set of performance qualities that are classified together because of common characteristics. |
|
|
Reference |
An association between two instances of PERFORMANCE CATEGORYs. For example, a relationship between a Codec instance and Bearer Type instance. |
|
|
Reference |
A value of a Characteristic Specification provided for PERFORMANCE that further defines what the PERFORMANCE is. |
|
|
Reference |
An action taken if a PERFORMANCE OBJECTIVE is not met. |
|
|
Reference |
A numeric value or text determined for a PERFORMANCE INDICATOR SPECIFICATION. For example, a value of .005 ms that represents average packet delay. |
|
|
|
Reference |
A parameter used in the calculation of a PERFORMANCE INDICATOR. A Characteristic Specification can be used as a parameter or another PERFORMANCE INDICATOR SPECIFICATION can be used. |
|
Reference |
An association between two PERFORMANCE INDICATORs, such as one indicator derived from another. |
|
|
Reference |
An association between two PERFORMANCE INDICATOR SPECIFICATIONs, such as one indicator derived from another. |
|
|
Reference |
A measure of a specific aspect of the performance of an entity, such as a lost packets or average jitter, defined for a PERFORMANCE SPECIFICATION that may trigger the creation of a PERFORMANCE CONSEQUENCE. |
|
|
Reference |
A Performance-related extension to an IP ADDRESS. |
|
|
|
Lookup |
Type of IP ADDRESS related performance measures. |
|
Reference |
A network address that identifies mobile Element Elements, such as cell sites and base station controllers. |
|
|
Reference |
A Performance-related extension to a NETWORK ADDRESS. A NETWORK ADDRESS defines different ways to identify where an Element is, such as an IP ADDRESS, or an IPXAddress, or a Point Code. |
|
|
|
Lookup |
The invariant characteristics that define Performance-related extensions to Network Address Specification. Network Address Specifications define different types of addresses of different technologies, such as an IP ADDRESS or an IPXAddress. Each related PERFORMANCE NETWORK ADDRESS instance has the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE NETWORK ADDRESS entity are specific to each instance. |
|
Reference |
A communication that occurs as part of measuring performance. A Notification is typically one-sided, that is, no Response is expected. |
|
|
Reference |
The invariant characteristics that define a communication (notification) that occurs as part of performance measurement. A Notification is typically one-sided, that is, no Response is expected. |
|
|
Reference |
A goal for a PERFORMANCE INDICATOR defined in terms of metrics, thresholds, and tolerances. |
|
|
Reference |
The time of day or days during which a PERFORMANCE OBJECTIVE is evaluated or not evaluated. |
|
|
Reference |
The time of day or days during which a Performance Objective Consequence applies or not to the violation of a PERFORMANCE OBJECTIVE. |
|
|
Reference |
The performance gathered on a POINT CODE (subtype of NETWORK ADDRESS). |
|
|
Reference |
The conversion factor that defines how many instances of one PERFORMANCE SPECIFICATION INTERVALs are contained in the related PERFORMANCE SPECIFICATION INTERVAL. |
|
|
Reference |
The invariant characteristics that define a measure that determines how a SERVICE and/or Element is functioning. Each related PERFORMANCE instance will have the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE entity are specific to each instance. |
|
|
Reference |
The interval of time for represented by the PERFORMANCE SPECIFICATION. |
|
|
Reference |
Cumulative time transformations at the period level. |
|
|
Reference |
Time transformations at the period level. |
|
|
Reference |
This entity represents the minimum and maximum requirements, limits, or other variable features of a Managed Device or MANAGED HARDWARE object. |
|
|
Reference |
Represents the semantics of the Has PHYSICAL CAPACITY association. The Physical Capacity Detail provides additional semantics describing the different types of PHYSICAL CAPACITYs that this Managed Component contains, and provides methods to tell how many PHYSICAL CAPACITYs are associated with this particular Managed Component instance. |
|
|
Reference |
This is the base entity for different types of Physical Components that can reside either in an EQUIPMENT or an Equipment Holder object. They cannot be used as a standalone object. From a management point-of-view, this object either cannot or does not need to be split into its constituent parts. For example, an ASIC (or Chip) cannot, and a tape for data storage does not need to be split up into their constituent parts. Any piece of hardware that is not a PHYSICAL LINK, PHYSICAL CONNECTOR, EQUIPMENT, or Equipment Holder, is a subclass of this class. |
|
|
Reference |
This is a concrete entity that represents any type of hardware unit that connects to other hardware units and transmit signals and/or power between them. |
|
|
Reference |
This entity adds additional semantics to the MANAGED HARDWARE entity. The associated attributes define whether a MANAGED HARDWARE object can be removed and/or replaced, and whether this action requires power to be removed or not when the action is performed. |
|
|
Reference |
This entity represents hardware devices that can be managed. Represents a convenient aggregation point for combining different aspects of a device (for example, the cables, connectors, cards, power supplies, and other objects that together comprise the device). Thus, it enables the device itself to have a physical manifestation (for example, the "Internet Gateway Router" can be identified as a PHYSICAL DEVICE). Examples of this entity include routers and switches, computers, and other end-devices that are managed. |
|
|
Reference |
Entity for representing hardware devices that can be managed that contains no sub-ordinate devices. In other words, this physical device is a standalone physical device. Represents a convenient aggregation point for combining different aspects of a device (for example, its physical composition and the set of services that it offers). The Physical Device Atomic also enables the device itself to have a physical manifestation. Examples of this entity include routers and switches, computers, and other end-devices that are managed. |
|
|
Reference |
Entity for representing hardware devices that can be managed that contains one or more sub-ordinate devices. In other words, this physical device is not a standalone physical device; rather, it represents an aggregation of physical devices. Each physical device in this aggregation can be managed. Represents a convenient aggregation point for combining different aspects of a device (for example, its physical composition and the set of services that it offers). The Physical Device Composite also enables the device itself to have a physical manifestation. Examples of this entity include routers and switches, computers, and other end-devices that are managed. |
|
|
Reference |
Entity for all Physical Device Role Specification subclasses. The Physical Device Role Spec enables relationships to be defined between itself and other entities in the core model. This helps prevent relationship explosion. The Physical Device Role Spec entity defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with PHYSICAL DEVICEs in the model. |
|
|
Reference |
Captures the semantics of the Specifies Physical Device Roles aggregation. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building PHYSICAL DEVICE objects. |
|
|
Reference |
This entity describes different types of hardware that constitute a PRODUCT. The Physical Element has two main purposes:
|
|
|
Reference |
Entity for defining the characteristic features and behavior of a PHYSICAL ELEMENT SPEC. Every PHYSICAL ELEMENT SPEC has a variety of important attributes, methods, constraints, and relationships which distinguish that PHYSICAL ELEMENT SPEC from other Physical Element Specifications. We call these Physical Element Spec Characteristics. Each of these characteristics is used at the business level to characterize a PHYSICAL ELEMENT SPEC. |
|
|
Reference |
This is a physical role that a device has. The Physical Element Role enables the correlation of physical components that route traffic with the logical capability of routing traffic. |
|
|
Reference |
Implements the semantics of the Roles Describe Physical Element aggregation. |
|
|
Reference |
Entity for all Physical Element Role Specification subclasses. The Physical Element Role Spec enables relationships to be defined between it and other classes in the model. This helps prevent relationship explosion. The Physical Element Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with Physical Elements, whether they are subclasses of PHYSICAL DEVICE or Hardware, in the model. |
|
|
Lookup |
This entity defines the invariant characteristics and behavior, attributes, methods, constraints, and relationships, of a PHYSICAL ELEMENT. |
|
|
Lookup |
Describes specific attributes, behavior, relationships, constraints, and semantics for building PHYSICAL ELEMENT objects. The purpose of this entity is to track Physical Element Specifications separately from other types of Element Specifications. This entity inherits the Specifies Element aggregation, and therefore can be used with the corresponding PHYSICAL ELEMENT entity. The difference between this entity and the PHYSICAL ELEMENT SPEC COMPOSITE entity is that this entity represents standalone Physical Element Specifications. The PHYSICAL ELEMENT SPEC COMPOSITE entity represents a specification that is in reality made up of a set (usually a hierarchy) of Physical Element Specifications. |
|
|
Lookup |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building Physical Element objects. The purpose of this entity is to track Physical Element Specifications separately from other types of Element Specifications. This entity inherits the modifiesElementSpec aggregation, and therefore can be used with the corresponding PHYSICAL ELEMENT SPEC entity. The difference between this entity and the PHYSICAL ELEMENT SPEC ATOMIC entity is that this entity represents a hierarchy of Physical Element Specifications. The PHYSICAL ELEMENT SPEC ATOMIC entity represents a single standalone Physical Element Specification. |
|
|
Reference |
Represents physical components of a managed device, including replaceable components. An instance of this object class must be present in only a single geographic location. An Equipment object may be nested within another Equipment object, thereby creating a containment relationship. The Equipment type shall be identified by sub-classing this object class. Either the name of the sub-class or an attribute may be used for identifying the equipment type. |
|
|
Reference |
This is a concrete entity that represents the connecting or cabling together of hardware entities. This entity enables both wireless and connector-based communication to be modeled. |
|
|
Reference |
Represents an actual or potential end point of a topological (physical) link, and corresponds directly to a physical port on a topology map. Physical Ports are always contained by another physical object - they cannot exist by themselves. The two most common examples are Physical Ports on a CARD and on a CHASSIS. |
|
|
Reference |
This entity is a concrete entity that defines the semantics of the PHYSICAL PORTs In Element Port aggregation. For example, it will describe characteristics and behavior of the PHYSICAL PORTs that comprise this particular Element Port in terms of dependencies and how a PHYSICAL PORT interacts with other PHYSICAL PORTs. |
|
|
Reference |
Captures the semantics of the SpecifiesPHYSICAL ELEMENT ROLEs aggregation. |
|
|
Reference |
Pipe is an abstracted Link between two network resources (which are also abstracted as TERMINATION POINTs). |
|
|
Reference |
A characteristic quality or distinctive feature of a PARTY INTERACTION THREAD (PIT). |
|
|
Lookup |
Type of PARTY INTERACTION THREAD (PIT) Characteristic. |
|
|
Reference |
A value of a PARTY INTERACTION THREAD (PIT) Characteristic. |
|
|
Reference |
Period level in the planning calendar. |
|
|
Reference |
Quarter level in the planning calendar. |
|
|
Reference |
Season level in the planning calendar. |
|
|
Reference |
Week level in the planning calendar. |
|
|
Reference |
Year level in the planning calendar. |
|
|
Reference |
Reference for Available Product Market Plan in different area or organization business unit. |
|
|
Reference |
Define the PRODUCT MARKET PLAN availability over Loyalty Program participants. |
|
|
Reference |
Defines the PRODUCT MARKET PLAN availability over certain Market Segments. |
|
|
Reference |
Reference for available PRODUCT MARKET PLAN subscriptions in an ORGANIZATION BUSINESS UNIT (store, outlet, and so on). |
|
|
Reference |
The outcome of the successful evaluation of a POLICY STATEMENT (that is, one that has met its condition(s)). The outcome is expressed in terms of the price of a Product Offering. A Prod Offer Price Action is a type of POLICY ACTION. |
|
|
Reference |
Part of a POLICY STATEMENT representing a single constraint that defines the assessment of the rule. The constraint is specified in terms of one or more Product Offering, Product Specification Type, Product Offering Price, and/or Product Offering Price Component. Prod Offer Price Rule Condition is a type of POLICY CONDITION. |
|
|
Reference |
An amount expressed in money or another medium of exchange that is thought to be a fair exchange for a Product Offering as the result of the evaluation of a POLICY STATEMENT. |
|
|
Reference |
A type of POLICY VARIABLE that represents a Product Offering, Product Offering Price, or Product Specification Type. |
|
|
Reference |
The Relationship between PRODUCT MARKET PLAN and PRODUCT INSTANCE. Through this assignment, the product market plan can be designed based on Product Instance. For example, the movie Avatar can be promoted with Email service. In this example, the operator can run a promotion saying: Subscribing to the Email service in this month gives you the movie Avatar for free (from IPTV or by downloading). |
|
|
Reference |
An altered rating plan, with allowance or premium charge, over the standard rating charge to the product inside a PRODUCT MARKET PLAN. |
|
|
Reference |
Details for an alternation, allowance or premium charge, over the standard rating charge to the product inside a product market plan. |
|
|
Reference |
ISUP Signaling OPC and DPC attributes that map to Region, Subregion, Node Type, and Node Name. |
|
|
Reference |
This entity is the root of the POLICY model. As such, it defines common attributes, methods and relationships that all policy subclasses use and take part in. |
|
|
Reference |
This entity represents how to form the action clause of a POLICY RULE. This consists of a single occurrence of a POLICY STATEMENT, which is of the form: {variable, operator, value} Policy actions have the semantics of "SET variable to value". There are two types of actions: - pass actions are invoked if the condition clause was TRUE - fail actions are invoked if the condition clause was FALSE. |
|
|
Reference |
This entity specifies the semantics needed for the contained Policy Actions aggregation. |
|
|
Reference |
This is the base entity for all simple POLICY ACTIONs. A simple POLICY ACTION consists of a single Boolean clause, which performs a single action. This consists of a single occurrence of a POLICY STATEMENT, which is of the form: {SET | CLEAR} POLICY VARIABLE to POLICY VALUE. This is distinctly different from the Policy Action Vendor, which does not use a POLICY STATEMENT. Policy Action Atomic objects can also be used to form more complex action structures. A Policy Action Composite object contains a group of Policy Action Atomic objects; this grouping enables multiple Policy Action Atomic objects to be executed as a group. Alternatively, a Policy Action Atomic object can contain one or more Policy Action Atomic objects (and also Policy Action Composite groups if desired) to provide the semantics of a compound Policy Action. In either case, the aggregation is done using the contained Policy Actions aggregation. |
|
|
Reference |
Serves as a generic container in which to place Policy Action Atomic, Policy Action Vendor, or Policy Action Composite entities. The first two provide actions that this container groups, while the latter establishes a hierarchy in which to order the execution of POLICY ACTIONs. Both simple and complex POLICY ACTIONs can be placed in this container. Each Policy Action Atomic and Policy Action Vendor object is linked to this object using the containedPolicy Actions association. |
|
|
Reference |
This entity specifies the semantics needed for the Policy Action In Policy Rule aggregation. This aggregation defines the set of POLICY ACTIONs that are contained in this POLICY RULE. |
|
|
Reference |
Provides a general extension mechanism for representing POLICY ACTIONs that have not been modeled with the attributes specified in this model. This entity uses two of its properties (Constraint and Constraint Encoding) for defining the content and format of a vendor-specific condition. Its third property (actionResponse) to provide a standard result, so that this object can be placed with other POLICY ACTION objects in a POLICY RULE object. Standardized extensions are not expected to use this entity. |
|
|
Reference |
This is an association class that explicitly defines which Managed Entities in a Policy Domain this Policy information applies to. |
|
|
Reference |
This entity represents how to form the condition clause of a POLICY RULE. This entity represents rule-specific or reusable policy conditions. Policy conditions are of the form: {variable, operator, value} where the operator is usually the MATCH operator, but could be another type (for example, compare) of operator. This gives the semantics of "IF the condition is TRUE (or FALSE)". The subclasses of POLICY CONDITION, along with its recursive aggregation, enable simple and compound (for example, nested) POLICY CONDITIONs to be supported by the same structure. |
|
|
Reference |
This entity specifies the semantics needed for the Policy Condition In Policy Condition aggregation. This aggregation defines the set of POLICY CONDITIONs that are contained in this POLICY CONDITION. Note that the POLICY CONDITION Contained Policy Condition Details entity and the Policy Condition Rule Details entity have conceptually the same attributes. This is because they both provide semantics to form a condition expression. The difference lies in their placement relative to the POLICY RULE entity. That is, the Contained Policy Condition Details entity combines individual expressions within a condition clause, whereas the Policy Condition Rule Details entity describes how the completed condition clause appears to the POLICY RULE. These attributes are described in the Data Dictionary section of this Addendum. |
|
|
Reference |
This is the base entity for all simple policy conditions. A simple policy condition consists of a single Boolean clause, which tests a single condition. This consists of a single occurrence of a POLICY STATEMENT, which is of the form: {variable, operator, value} This design relies on the POLICY STATEMENT to supply the actual terms to form the condition clause. Thus, since everything is normalized to a condition clause, no subclasses of Policy Condition Atomic are needed. Instead, subclasses of the appropriate POLICY STATEMENT classes are provided. A compound POLICY CONDITION consists of one or more POLICY CONDITIONs contained inside a higher-level POLICY CONDITION. These can optionally be grouped by a POLICY CONDITION COMPOSITE object if desired. |
|
|
Reference |
The POLICY CONDITION COMPOSITE entity is the base entity for all complex policy conditions. A complex policy condition consists of an aggregation of POLICY CONDITION ATOMIC and POLICY CONDITION COMPOSITE objects, which in turn form a complex Boolean statement. Note that such an object still evaluates to a single Boolean TRUE or FALSE value. Conceptually, this is a standalone object that consists of one POLICY CONDITION that provides an overall context for either a nested or a group of subordinate POLICY CONDITIONs to be evaluated. |
|
|
Reference |
This entity specifies the semantics needed for the Policy Condition In Policy Rule aggregation. This aggregation defines the set of Policy Conditions that are contained in this POLICY RULE. The Contained Policy Condition Details entity and the Policy Condition Rule Details entity have conceptually the same attributes. This is because they both provide semantics to form a condition expression. The difference lies in their placement relative to the POLICY RULE entity. That is, the Contained Policy Condition Details entity combines individual expressions within a condition clause, whereas the Policy Condition Rule Details entity describes how the completed condition clause appears to the POLICY RULE. These attributes are described in the Data Dictionary section of this Addendum. |
|
|
Base |
Represents an aggregation of Policy Events, constrained according to the eventConstraint attribute of the Event Details aggregation entity. This set of Policy Events is then presented to one or more POLICY RULEs to trigger the evaluation of their condition clauses. This entity enables an external application, such as a Policy Server, to dynamically adjust the set of events that are being used to trigger the evaluation of a POLICY RULE. |
|
|
Base |
Represents the occurrence of a single atomic event, which triggers the evaluation of the condition clause of a POLICY RULE. |
|
|
Base |
Represents the occurrence of a composite event. A composite event is an event that is made up of a set of Policy Event Atomic and/or Policy Event Composite entities. Like a Policy Event Atomic, a Policy Event Composite can also be used to trigger the evaluation of the condition clause of a POLICY RULE. |
|
|
Reference |
This entity is a generalized aggregation container. A Policy Group enables POLICY RULEs and POLICY GROUPs to be aggregated in a single container. Note that loops, including the degenerate case of a POLICY GROUP that contains itself, are not allowed when POLICY GROUPs contain other POLICY GROUPs. |
|
|
Reference |
This is an association entity that defines the semantics associated with a Policy Event Set being applied to a POLICY GROUP. Specifically, it controls through its Execution Filter attribute which components in the POLICY GROUP this Policy Event Set will be passed to, so it can be evaluated. |
|
|
Reference |
This is a concrete entity for modeling different types of operators in a POLICY STATEMENT. By restricting the type of operator used in a POLICY STATEMENT, one can effectively restrict the semantics of that POLICY STATEMENT. |
|
|
Reference |
Defines the relationship between POLICY OPERATOR and POLICY VARIABLE. |
|
|
Reference |
This entity defines the concept of various types of roles for different policies that are used. |
|
|
Reference |
Entity for realizing the "event-condition-passaction-failaction" semantics that form a the model policy rule. The semantics of this rule are that the rule is evaluated when an event occurs. If the condition clause is satisfied, then the pass-action clause will be executed (otherwise, the fail-action clause will be executed). POLICY RULEs may be nested within POLICY RULEs. This is often needed in networking (for example, bandwidth allocation). |
|
|
Reference |
This entity defines two types of collections. POLICY RULE collects Policy Events, POLICY CONDITIONs, and POLICY ACTIONs, while POLICY GROUP collects POLICY RULEs and POLICY GROUPs. Two important and powerful features of this arrangement are that a POLICY SET defines a common decision strategy and a common set of POLICY ROLEs to be used by the POLICY GROUPs and the POLICY RULEs that inherit from it. |
|
|
Reference |
Defines relationship between POLICY SETs. |
|
|
Reference |
This entity models the triplet {variable, operator, value} that is used by both the POLICY CONDITION and POLICY ACTION entities. The semantics are reflected in the types of operators that are allowed to be used in each case. For conditions, users want the semantics of "variable relates to value", where "relates to" is usually the match operator, but could also be other applicable operators (for example, a comparison operator). For actions, users want the semantics of "set variable to value". Here, the only operator allowed is the set operator. |
|
|
Reference |
An abstract base entity for modeling different types of values that occur in a POLICY STATEMENT. The POLICY VALUE specifies an attribute that should either be set or cleared (if used in a POLICY ACTION) or matched or compared to a value of the POLICY VARIABLE in a POLICY CONDITION. |
|
|
Reference |
This entity models different types of variables that form a POLICY STATEMENT. The variable specifies an attribute or concept that should either be matched or compared to a value when the condition is evaluated. |
|
|
Reference |
This is an association class that contains the OCL expression that will be used to define the particular semantics of how this Value is constrained by this Variable. This includes constraints such as upper and lower bounds of the value that a POLICY VALUE object can take. |
|
|
Lookup |
Lookup for type of postal service type available to the carrier. For example:
|
|
|
Reference |
Postal Code, Zip Code, or similar geographical designation. |
|
|
Reference |
Subtype of PRODUCT for postpaid wireless. |
|
|
Lookup |
Lookup for categorizations of prepaid allowances. For example:
|
|
|
Lookup |
Lookup for valid deduction types as related to prepaid allowances (PPA). |
|
|
Derived |
The summary of daily prepaid ACCOUNT activations, with all their initial values. |
|
|
Derived |
Monthly aggregation of prepaid account revenue, including: air time, recharge value and so on, by ACCOUNT, SALES CHANNEL, AGE ON NET BAND. |
|
|
Aggregate |
Monthly summary of prepaid account revenue, including: air time, recharge value, and so on, by CUSTOMER SEGMENT, PRODUCT MARKET PLAN. |
|
|
Derived |
Daily aggregate of free minutes allowance (PPA) for ACCOUNT and PRODUCT MARKET PLAN. |
|
|
Aggregate |
Monthly summary of free minutes allowance (PPA) in a PRODUCT MARKET PLAN. |
|
|
Derived |
Daily aggregate of prepaid calls by ACCOUNT, PRODUCT MARKET PLAN, and ACCESS METHOD. |
|
|
Aggregate |
Monthly summary of prepaid call activity by PRODUCT MARKET PLAN, CUSTOMER TYPE. |
|
|
Lookup |
Lookup for the prepaid mobile event types that may be actioned against a prepaid mobile subscription. The specific event types are implementation specific. For example:
|
|
|
Base |
Type of ACCOUNT PAYMENT in which a PREPAID VOUCHER INSTANCE is recharged. |
|
|
Reference |
The voucher a customer can buy to refill their prepaid account, normally in the form of a paper or plastic card. For example:
|
|
|
Reference |
Each voucher instance generation batch may produce thousands vouchers. |
|
|
Reference |
Represents each prepaid card. The cards are a means of recharging prepaid mobiles. The card can be physically a Plastic Card or a paper slip with account number and pin code. |
|
|
Derived |
The summary of daily prepaid voucher recharge. |
|
|
Reference |
The recharge options for a type of PREPAID VOUCHER. A voucher can be configured with different perceived value to the customer and they may choose to redeem any one of them. For example a voucher may have the following recharge options:
|
|
|
Reference |
Type of Service Product. Subtype of SERVICE, for Prepaid Wireless service only. |
|
|
Reference |
The specification of a method to be used to transform the current sell unit retail amount to the price charged to account based on a discount group. |
|
|
Reference |
Type of event which may trigger a billing process, for example, event of customer using a product over its quota. |
|
|
Reference |
The product provided by the carrier. Product includes PRODUCT PACKAGE information. The composition of a PRODUCT PACKAGE is tracked in the product relationship. |
|
|
Reference |
Additional descriptive text for a given product, that cannot fit in any other existing attributes, or that should be customized for users with different languages. |
|
|
Reference |
Defines a relationship between a PRODUCT and a related product. |
|
|
Lookup |
Lookup for valid reason codes and descriptions for PRODUCT ASSIGNMENT. |
|
|
Lookup |
Brand of the PRODUCT or PRODUCT MARKET PLAN. The operators can provide the same product under different brands for different segments of customers. For example, some operators may have brand such as Business, High End, Economical, for the same gsm wireless product. |
|
|
Reference |
Various product capabilities, or features. For example:
|
|
|
Lookup |
Lookup for type of PRODUCT CAPABILITY. |
|
|
Reference |
Detailed PRODUCT CAPABILITY information. The information would be quantitative by PRODUCT CAPABILITY TYPE. |
|
|
Reference |
A list of PRODUCT MARKET PLAN for sale, with prices and illustrations, for example in book form or on the web. Product Catalogs can be used by Customers during a self-care ordering process and may be used across one or more Distribution Channels. |
|
|
Reference |
A characteristic quality or distinctive feature of a Product Catalog Specification. |
|
|
Reference |
A use of the Product Catalog Spec Characteristic by an Entity Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Product Catalog Spec Characteristic. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Characteristic Specifications. |
|
|
Reference |
A value associated with a Product Catalog Characteristic. |
|
|
Reference |
A use of the Product Catalog Spec Characteristic Value by an Product Catalog Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Product Catalog Spec Characteristic Value. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Characteristic Spec Values. |
|
|
Reference |
Defines which PRODUCT CATALOG is available in which geographical area. |
|
|
Reference |
Defines the relationship between a PRODUCT CATALOG and the product market plans that appeared on the PRODUCT CATALOG. |
|
|
Reference |
The PRODUCT CATALOG presentation type. For example:
|
|
|
Reference |
Defines where the PRODUCT CATALOGs are made available to the end user. |
|
|
Lookup |
Lookup for types that define the invariant characteristics of a PRODUCT CATALOG. |
|
|
Lookup |
Lookup for classification of the PRODUCT according to certain common characteristics. |
|
|
Reference |
A characteristic quality or distinctive feature of a Product Specification. The characteristic can be take on a discrete value, such as color, can take on a range of values, (for example, sensitivity of 100-240 mV), or can be derived from a formula (for example, usage time (hrs) = 30 - talk time *3). Certain characteristics, such as color, may be configured during the ordering or some other process. |
|
|
Reference |
A use of the Characteristic Specification by an Product Specification to which additional properties apply. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Product Spec Characteristics. |
|
|
Lookup |
Type of PRODUCT CHARACTERISTIC. |
|
|
Reference |
A value of a Product Spec Characteristic chosen for a PRODUCT that further defines what the PRODUCT is. |
|
|
Reference |
A use of the Product Catalog Spec Characteristic Value by an Product Catalog Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Product Catalog Spec Characteristic Value. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Product Spec Characteristics. |
|
|
Lookup |
Lookup for type codes and descriptions for PRODUCT PACKAGE charge on a PRODUCT. For example:
|
|
|
Reference |
Assignment of related PRODUCT CHARGE TYPEs. |
|
|
Lookup |
Lookup for available reasons for PRODUCT CHARGE TYPEs to be related to each other. |
|
|
Lookup |
Lookup for available reasons for Product Charge in the PRODUCT RATING PLAN. For example:
|
|
|
Base |
Sub-table of the COST TYPE table, used to associate a specific cost to a given product. |
|
|
Reference |
Coverage of a product over geographical area. |
|
|
Lookup |
Lookup for type code and description for PRODUCT COVERAGE AREA. For example:
|
|
|
Reference |
Links detailed geographical locations to a certain PRODUCT COVERAGE AREA. |
|
|
Reference |
Available features that may be associated with one or more PRODUCTs. For example, for a handset there are features such as:
|
|
|
Reference |
Assigns one or more PRODUCT FEATUREs to a PRODUCT. Multiple products may have the same PRODUCT FEATUREs. |
|
|
Reference |
Assignment of valid EQUIPMENT FUNCTIONALITY and PRODUCT VERSIONs to a PRODUCT. |
|
|
Reference |
Assigns a PRODUCT to a GEOGRAPHY ENTITY. This is particularly used for products offered only locally or in a limited region. For example: "Broadband Service" in specific cities and ZIP code areas (typically used for City carriers). |
|
|
Lookup |
Categorizations or Groups into which PRODUCTs may be assigned, usually based on similar functionality. Note: this is different and should not be confused with the PRODUCT MARKET PLAN GROUP entity. For example, the customer may group product in categories such as:
|
|
|
Reference |
Defines relationship of PRODUCT and one or more PRODUCT GROUPs. |
|
|
Lookup |
Lookup for codes and descriptions of types of PRODUCT GROUPs. |
|
|
Reference |
The real instance of a given PRODUCT which a customer can purchase or rent (or eventually gets for free as part of a PRODUCT MARKET PLAN). The product instance is linked to the Customer Order Line Item and relates a product to a customer. For example:
|
|
|
Base |
A history of the Status for a PRODUCT INSTANCE. For example:
|
|
|
Lookup |
Lookup for type of specific Product instance status type. For example:
|
|
|
Lookup |
Lookup for the ways to classify products according business organization. For example: Wireless, Fixed Line, and so on. |
|
|
Base |
Defines relationship between EMPLOYEE, PRODUCT MANAGEMENT ROLE, and PRODUCT. |
|
|
Lookup |
Lookup for available reasons for a PRODUCT MANAGEMENT HISTORY relationship. |
|
|
Lookup |
Lookup for valid role codes and descriptions an employee may be assigned in PRODUCT MANAGEMENT HISTORY. For example:
|
|
|
Reference |
Defines how a product is brought to the market, including: positioning, pricing, and bundling details. For example:
|
|
|
Reference |
Assigns Products to PRODUCT MARKET PLANs. |
|
|
Lookup |
Lookup for type of product participation (inclusion) in the market plan. For example:
|
|
|
Base |
Sub-table of the COST TYPE table. This entity associates a specific cost to a given PRODUCT MARKET PLAN. The cost should not be related to the CAMPAIGN or to the PROMOTION, but just to the PRODUCT MARKET PLAN. |
|
|
Reference |
Relationship between PRODUCT MARKET PLAN and Geography. Some PRODUCTs may only be sold in a particular area. |
|
|
Reference |
Hierarchy level to group the various PRODUCT MARKET PLANs. For example:
|
|
|
Reference |
Defines relationship of PRODUCT MARKET PLANs to one or more PRODUCT MARKET PLAN GROUPs. |
|
|
Lookup |
Lookup for the type code and description for a PRODUCT MARKET PLAN GROUP. |
|
|
Reference |
Defines the relationship between two PRODUCT MARKET PLANs. For example:
|
|
|
Lookup |
Lookup for the types of PRODUCT MARKET PLAN relationships. |
|
|
Lookup |
Type of the PRODUCT MARKET PLAN. For example:
|
|
|
Reference |
||
|
Reference |
Groups of PRODUCTs bundled to serve as basis of a PRODUCT MARKET PLAN. The product package is not customer facing and a customer should subscribe to a product package through the PRODUCT MARKET PLAN. For example:
|
|
|
Reference |
Assigns PRODUCT(s) to a PRODUCT PACKAGE. |
|
|
Lookup |
Lookup for type codes and descriptions for PRODUCT PACKAGE charge on a PRODUCT. For example:
|
|
|
Reference |
Grouping mechanism for prices and usage limits associated with a PRODUCT. |
|
|
Reference |
Detail of PRODUCT RATING PLAN, defines prices and usage limits for each PRODUCT CHARGE TYPE. |
|
|
Lookup |
Lookup for the type of PRODUCT RATING PLAN. |
|
|
Base |
Status history of PRODUCT. |
|
|
Lookup |
Lookup for the type of the product status. |
|
|
Lookup |
Lookup for the type of the PRODUCT. For example:
|
|
|
Reference |
The usernames assigned to customer for given products. For example:
|
|
|
Reference |
Iteration of a PRODUCT created when a minor change is made to the PRODUCT setting that does not require creating a new PRODUCT. |
|
|
Reference |
The business activities, TASKs, may be categorized into a specific Project according to their common purpose. For example:
|
|
|
Reference |
The business activity which may happen to the operator. It is the super type of PROJECT and TASKs. |
|
|
Reference |
The promotion reflects the tactics that an operator undertakes to generate increased incremental sales or usage volume for a specific product within a promotional event. Promotions are frequently communicated as part of a marketing campaign to ensure that awareness is generated with the target audience. |
|
|
Base |
Assigns a particular CUSTOMER SEGMENT, cluster, to a given PROMOTION or list of promotions. The customer segments are generated by certain analytic applications, including Oracle Mining, and this assignment tracks the usage of customer segments in the PROMOTION. |
|
|
Base |
Defines the relationship between a CONTACT LIST and a PROMOTION: the contact list has been used for a marketing campaign to which a specific promotion was proposed. |
|
|
Base |
Subtype of the COST, which is used to associate a specific cost uniquely associated to a given promotion. For example, a rent fee for the location where the operator performs the promotion. |
|
|
Base |
A history of campaign party role about management of a campaign EPISODE. |
|
|
Reference |
Associates a market plan to a PROMOTION. Typically, this applies when a given market plan is offered with an additional discount (PROMOTION) during a certain period. |
|
|
Reference |
Details regarding each CAMPAIGN MESSAGE broadcast through a MEDIA OBJECT. |
|
|
Reference |
||
|
Reference |
Associates PRODUCT CATALOGs to a PROMOTION. |
|
|
Reference |
Defines the relationship between two PROMOTIONs. |
|
|
Lookup |
Lookup for the prospect reaction to a specific PROMOTION during a sales campaign. For example:
|
|
|
Reference |
The allocation of PROMOTION resources or actions onto each SALES CHANNEL. |
|
|
Lookup |
Lookup for valid type codes and descriptions of Promotion Term associated with a PROMOTION TERM VALUE. For example:
|
|
|
Base |
Assigns PROMOTION TERM TYPE to a PROMOTION with a value corresponding to the Term Type. For example:
|
|
|
Lookup |
Lookup for the type of PROMOTION (each for either a limited time or for the contract duration). For example:
|
|
|
Reference |
A parcel of land with defined legal boundaries. This is a concrete Geographic Location entity. |
|
|
Reference |
Defines the relationship of which property is using which address location to identify the property. |
|
|
Reference |
The proposals made available to prospects in the promotion. It could be a upsell offer like selling a new product, or a retention program (Free Minutes for Longer contract period). |
|
|
Reference |
The relationship between two PROPOSALs. |
|
|
Reference |
An individual, collection of individuals, company, or public institution that does not currently purchase merchandise or services, but who may in the future. A prospect may also be a CUSTOMER of one PRODUCT (already purchased) that does not currently purchase another PRODUCT (may purchase). A prospect has no recorded relationship with the provider. |
|
|
Reference |
Attributes of an individual PROSPECT, one who is not an organization. |
|
|
Reference |
Attributes of a prospect organization. |
|
|
Lookup |
The different priorities which can be assigned to the prospect and prospect interests. |
|
|
Reference |
Lookup for type of quality scores which can be applied to PROSPECT. For example:
|
|
|
Reference |
The quality score value assigned to each prospect under different types of criteria. |
|
|
Lookup |
The reason to explain why an offer or PROPOSAL is rejected by the prospect. |
|
|
Reference |
A formal set of rules and conventions that governs how two entities exchange information (usually over one or more types of network media). This entity represents Protocols that can be managed. Represents a convenient aggregation point for defining how Protocols are managed and used. |
|
|
Base |
Pay TV full channel activation event. |
|
|
Base |
The detail of QPI service. |
|
|
Base |
Customer usage of PAY TV service. |
|
|
Reference |
Publication to which the MEDIA OBJECT used in CAMPAIGN belongs. |
|
|
Lookup |
Lookup for code and description describing the type of publication. |
|
|
Base |
All the purchase orders that are raised on suppliers by the purchasing unit of a business organization (purchasing organization). The types of purchase orders can be many and would typically include one-time, regular, blanket, release, and so on. |
|
|
Base |
Specifies purchase order line Item information. |
|
|
Base |
Specifies the state change history of each PURCHASE ORDER LINE ITEM. |
|
|
Base |
Defines the records of a PURCHASE ORDER LINE ITEM being in a particular state for a period of time. |
|
|
Lookup |
Lookup for the different types of state a purchase order or a line item may be at. For example:
|
|
|
Reference |
Represents a single or a set of bit string values. A bit string is defined as a string whose individual characters have the value "0" or "1". No other values are allowed. |
|
|
Reference |
Represents a Boolean value (TRUE or FALSE). |
|
|
Reference |
Provides a list of integer or integer range values. Each integer can be of an arbitrary size. |
|
|
Reference |
Provides an unordered list of IPv4 addresses, IPv6 addresses, ranges of IPv4 addresses, ranges of IPv6 addresses, and host names to be matched against in a policy condition. The format of each string is specified according to the ABNF definition of an IPv4 address. If a host name is matched against another valid IP address, the match is done by resolving the host name into a valid IPv4 or IPv6 address. Matching host names against each other, like matching IP addresses (of the same type) against each other, is done using a string comparison. Matching an IPv4 address against an IPv6 address fails. |
|
|
Reference |
Represents a single string value, or a set of string values. Each value can have wildcards. |
|
|
Reference |
Represent a single or set of bit string variable. Thus, only Bit String Value classes can be used in the value portion of the condition expression with this POLICY VARIABLE. |
|
|
Reference |
Represents a single or set of string variable. Each can have wildcards. Thus, only String Value classes can be used in the value portion of the condition expression with this POLICY VARIABLE. |
|
|
Reference |
Represents a generic specification for defining the different types of Sub-Services that are required to implement a specific type of QoS. This enables business rules to be mapped to the network, and define services that the network provides. A QoS Service can be thought of as an aggregation of sub-services needed to realize the functionality specified by, for example, a SERVICE BUNDLE. This enables the network administrator to map business rules, as specified in a more abstract object or set of objects, to the network, and the network designer to engineer the network such that the network provides different functions for different types of applications. QoS Services are a type of RESOURCE FACING SERVICE and are bundled together using SERVICE BUNDLEs. QoS Services can be turned into templates using SERVICE BUNDLE SPECs. The QoS Service itself is a means to coordinate different technology-specific approaches to implementing QoS, such as DiffServ, ToS, and IEEE 802.x. As such, the QOS Service entity is an abstract entity. |
|
|
|
Lookup |
The QOS SERVICE spec type. |
|
Reference |
Quarter Hour as defined in Time Hierarchy. |
|
|
Reference |
Cumulative time transformations at the quarter level. |
|
|
Reference |
Transformation with respect to a quarter. For example:
|
|
|
Reference |
A Rack is a type of Secure Holder that represents an enclosure in which Equipment Holders, such as CHASSIS, are placed. Typically a Rack is nothing more than the enclosure, and all the functioning componentry is packaged in the CHASSIS. The logical identifier of a Rack is not typically associated with the Device (that is, the Network Element). Compare this to either a Bay or a Shelf, whose logical identifier IS associated with the Device. Thus, the Rack is explicitly not a part of the logical model of a network. The Rack typically serves as the "master enclosure" for CHASSIS, Shelves and Bays. In addition, Racks can have multiple instances of multiple Devices mounted in them. |
|
|
Lookup |
Lookup to specify the valid candidate Ratable Unit Measurement (RUM)s for each event type. For example:
|
|
|
Base |
Contains rating information attached to raw or mediated network event. |
|
|
Lookup |
Lookup for Rating Method Type code and description. For example:
|
|
|
Base |
The raw MMS EVENTas acquired on network element. |
|
|
Base |
The raw WIRELESS CALL EVENT. |
|
|
|
Reference |
This class defines a SERVICE SPEC, in terms of a set of ServiceSpecificationRoles, for a ElementFacingService. This is the base class for defining ServiceSpecificationRoles that are used to represent the invariant characteristics of a ElementFacingService. This enables the ElementFacingService to be managed abstractly using ServiceSpecificationRoles. It also helps define the SERVICE SPEC in terms of the functions that it has or provides. |
|
Lookup |
Lookup for the bands of revenue earned from the sale of recharge coupons, for prepaid, which is called recharge revenue. The recharge revenue is to be analyzed for all currently active prepaid subscribers and for all churned subscribers until the time of termination. For example, the revenue can be banded by creating slabs for recharge revenue of $0-$25, $25-$50, and so on. |
|
|
Reference |
A type of PRODUCT MARKET PLAN (PMP) rating plan with a recurring charge. |
|
|
Derived |
The daily aggregate of loyalty point redemption by CREDIT CATEGORY, LOYALTY PROGRAM CHANNEL, AGE ON NET BAND, and EMPLOYEE. Daily aggregation of LOYALTY PROGRAM redemption statistics by LOYALTY PROGRAM CHANNEL, SALES CHANNEL, AGE ON NET BAND, CREDIT CATEGORY, and EMPLOYEE. |
|
|
Aggregate |
Monthly summary of LOYALTY PROGRAM redemption statistics by LOYALTY PROGRAM CHANNEL |
|
|
Lookup |
Lookup for redemption type that maintains all possible point redemption types and organizes redemption data by redemption type for analysis purposes. |
|
|
Lookup |
This lookup for religion. For example:
|
|
|
Reference |
This is the base entity for defining Resource Facing Services. A Resource Facing Service is an abstraction that defines the characteristics and behavior of a particular SERVICE that is not directly seen or purchased by the Customer. Resource Facing Services are "internal" Services that are required to support a CUSTOMER FACING SERVICE. The Customer purchases CUSTOMER FACING SERVICEs, and is not aware of the Resource Facing Services which support the CUSTOMER FACING SERVICE(s) that is being purchased directly by the Customer. For example, a VPN is an example of a CUSTOMER FACING SERVICE. This particular type of VPN may require BGP to support it. Customers do not purchase BGP, and hopefully are not even aware that BGP is running. Therefore, BGP is an example of a Resource Facing Service. |
|
|
Reference |
Defines a SERVICE in terms of a set of SERVICE ROLEs for a RESOURCE FACING SERVICE. This is the base entity for defining SERVICE ROLEs that represent the variable characteristics of a RESOURCE FACING SERVICE in terms of roles that this SERVICE plays. This entity enables the RESOURCE FACING SERVICE to be managed abstractly using SERVICE ROLEs. The Resource Facing Service Role also helps define the SERVICE in terms of the functions that it has or provides. |
|
|
Lookup |
This is the base entity for defining Resource Facing Service Specs. A Resource Facing Service Spec is an abstraction that defines the invariant characteristics and behavior of a particular RESOURCE FACING SERVICE. This is not seen by the Customer. However, it is required by one or moreCUSTOMER FACING SERVICE SPECs in order for them to function correctly. The invariant portion serves as a single common basis to build a set of variable RESOURCE FACING SERVICEs that all use this common Resource Facing Service Spec. |
|
|
Lookup |
This entity defines a standalone RESOURCE FACING SERVICE that meets the needs of a particular CUSTOMER FACING SERVICE. Standalone RESOURCE FACING SERVICEs may be linked directly to a CUSTOMER FACING SERVICE or aggregated by a Resource Facing Service Composite. |
|
|
Lookup |
This entity defines an integrated set of RESOURCE FACING SERVICE that collectively meets the needs of a CUSTOMER FACING SERVICE. For example, the Customer may have requested "GoldService", which is a SERVICE PACKAGE that defines a set of SERVICE BUNDLEs, each of which has its own QoS. A set of Resource Facing Service Products can then be defined, one for each different SERVICE BUNDLE instance, that provides the required QoS for each SERVICE BUNDLE instance. |
|
|
Reference |
Defines a Service Specification, in terms of a set of Service Specification Roles, for aRESOURCE FACING SERVICE. This is the base entity for defining Service Specification Roles that represent the invariant characteristics of aRESOURCE FACING SERVICE. This entity enables theRESOURCE FACING SERVICE to be managed abstractly using Service Specification Roles. The Resource Facing Servicesrole also helps define the Service Specification in terms of the functions that it has or provides. |
|
|
Reference |
Keeps the historical versions of RESOURCE FACING SERVICE SPEC. |
|
|
Base |
A type of Request that represents a Service Order's services decomposed into the Elements on which the services will be provisioned. |
|
|
Base |
The purpose for the RESOURCE ORDER expressed in terms of a NETWORK ELEMENT TYPE or a NETWORK ELEMENT. |
|
|
Reference |
A measure of the manner in which a Element is functioning. |
|
|
Lookup |
The invariant characteristics of a measure of the manner in which a Element is functioning. Each related PERFORMANCE instance will have the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE entity are specific to each instance. |
|
|
Reference |
A role that a Element Specification plays in defining a PERFORMANCE SPECIFICATION. |
|
|
Reference |
The Resource Port covers both logical and physical port together and manage as a single entity. |
|
|
Reference |
Subtype of internal organization. This usually lists the shops where the communications service provider presents the products and sells directly to customers. A retail store may contain several SELLING LOCATIONs. |
|
|
Reference |
Reference list of all wireless or Radio Frequency (RF) carriers. |
|
|
Derived |
Daily aggregate of Radio Frequency (RF) Network Capacity utilization statistics. Radio Frequency (RF) interfaces are present at two levels in the network:
|
|
|
Aggregate |
Monthly summary of Radio Frequency (RF) Network Capacity utilization statistics. |
|
|
Reference |
Defines the semantics of the modifiesRFSSpec aggregation. Specifically, it enables an application to define which set of versions of this Resource Facing Service Specification are appropriate for a given task. |
|
|
Reference |
Sub-table of SUPPLEMENTARY SERVICE, by which a customer can download music as a ringtone for the phone. |
|
|
Lookup |
Lookup for the various roaming types to classify the calls. For example:
|
|
|
Reference |
This is an abstract base entity that defines the concept of various types of roles. |
|
|
Reference |
Hierarchy among the job roles within an organization. |
|
|
Reference |
Provides an abstraction for most policy entities. The root entity properties enable you to name, describe, and identify all objects, manageable and unmanageable, in the environment. |
|
|
Reference |
This entity represents different types of routed protocols that can be managed. Routed protocols are those protocols that can be routed by a router. Specifically, the router must be able to interpret the logical internetwork as specified by that routed protocol. Represents a convenient aggregation point for defining how routed protocols are managed and used. |
|
|
Reference |
A type of physical device which performs routing function in IP-based network. |
|
|
Reference |
In IN Network or Wireless, many different type of devices such as VLR, HLR, SCP servers are utilized in network to decide the call routing. This entity tracks the device information. |
|
|
Reference |
This entity represents different types of routing protocols that can be managed. Routing protocols are used to determine how information is routed (for example, how it traverses an intermediate system). This entity represents a convenient aggregation point for defining how routing protocols are managed and used. |
|
|
Reference |
An abstracts entity showing the different routing capabilities necessary for a LOGICAL DEVICE to have. This entity helps to simplify the modeling of network devices, which have many different sets of capabilities. For example, most routers can do routing, forwarding, and firewalling of traffic. By modeling these capabilities as three roles, router functionality is both abstracted as well as categorized, so that the differences between routing done by a router and routing done by an L3 switch can be differentiated. |
Table 2-28 S to V Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Derived |
Daily aggregate of campaign results by PROMOTION RESULT TYPE and Sales Campaign Client Code. |
|
|
Aggregate |
Monthly summary of Sales Campaign results by PRODUCT MARKET PLAN, CAMPAIGN CHANNEL, PROMOTION RESULT TYPE. |
|
|
Reference |
Channel used to communicate with parties for sales purposes. For example:
Sales channels are represented by the channel level, which also becomes the lowest level for the channel dimension. |
|
|
Base |
Defines a history of which SALES CHANNEL is applicable to which SALES COMMISSION PLAN. |
|
|
Reference |
The sales representative who sells the product to the customer. For example:
|
|
|
Base |
The sales commission earned by sales agent because of the contract. |
|
|
Base |
The sales commission issued to the sales agent. |
|
|
Reference |
The sales commission plan for particular PRODUCT PACKAGE and sales agent level. |
|
|
Reference |
Details about the SALES COMMISSION PLAN per PRODUCT MARKET PLAN and PROMOTIONs, including sales quota and commission rate. |
|
|
Derived |
Daily aggregate of sales by SALES CHANNEL, PRODUCT MARKET PLAN, business unit, sales representative, CUSTOMER. |
|
|
Aggregate |
Monthly summary of sales by SALES CHANNEL, PRODUCT MARKET PLAN, business unit, sales representative. |
|
|
Derived |
Monthly summary of sales representative performance measured by sales, commission, and so on. |
|
|
|
Lookup |
Super entity to provide SCD2 and LANGUAGE support for all its children. |
|
Reference |
A list of specific groupings of questions or statements presented to individuals during a survey. |
|
|
Reference |
Initiative questions documents the questions asked of the customer as part of the initiative. |
|
|
Lookup |
The domain of values used to group script items. For example:
|
|
|
Lookup |
Seasons and their attributes. Seasons are arbitrary periods around which some providers organize their buying and selling patterns. Each day should fall within no more than one season. |
|
|
Reference |
Second hierarchy level as defined in Time Hierarchy. |
|
|
Reference |
This entity is a type of Holder Composite that serves as the parent for the RACK and CHASSIS entities. This entity generalizes common properties that apply to RACKs and CHASSIS. |
|
|
Lookup |
Lookup for type and description of security requirements that may be associated with an ITEM. |
|
|
Reference |
Minimum and Maximum scores for each segment associated with an ACCOUNT SEGMENT or CUSTOMER SEGMENT. |
|
|
Lookup |
Lookup for type codes and descriptions used to define ACCOUNT SEGMENTATION MODEL or CUSTOMER SEGMENTATION MODEL. |
|
|
Reference |
Physical location in a RETAIL STORE specifically dedicated to selling or displaying merchandise. |
|
|
Lookup |
Lookup for type code and description used to define a SELLING LOCATION: For example:
|
|
|
Reference |
Service is an internal technical presentation of available PRODUCTs to the end user. Different customers may subscribe to different services under the same product name. For example, for a service of 4MB Broadband, the service may be implemented by ADSL service or by FTTH (Optical Fiber). |
|
|
Reference |
Conceptually, a Service Bundle is thought of as a collection of Element Facing Service Specifications. This entity enables the needs of different sets of Element Facing Service Specifications to be grouped together - hence, the name "bundle". Since these are Resource Facing Specifications, they define reusable templates for implementing the Element Facing Services that are required by a particular CUSTOMER FACING SERVICE (as represented by a SERVICE PACKAGE). Service Bundles were designed to define a set of Class of Service specifications that were required by a CUSTOMER FACING SERVICE to work together. A SERVICE PACKAGE is the entity that models the requirements of the CUSTOMER FACING SERVICE. Thus, SERVICE PACKAGEs can specify different packaging of CUSTOMER FACING SERVICE that are sold to the Customer, and Service Bundles specify the set of Element Facing Services that each CUSTOMER FACING SERVICE requires. Service Bundles are a natural way to implement the requirements of a SERVICE PACKAGE, and are related to a SERVICE PACKAGE through the Service Package Uses Service Bundles aggregation. |
|
|
Reference |
A Service Bundle Spec is the base entity for defining the different classes of bundled Element Facing Service Specs that a Customer (or some other appropriate PARTY ROLE) can subscribe to. The preferred way to represent a Customer subscription of this nature is by defining a Service Bundle Spec that defines the set of Element Facing Service Specs that are being used. Conceptually, a Service Bundle Spec is thought of as a collection to enable the needs of different sets of Element Facing Service Specs to be grouped together. The "bundle" conveys the concept of grouped Service Specs that are related. Since these are Resource Facing Specifications, they define reusable templates for implementing the Element Facing Services that are required by a particular CUSTOMER FACING SERVICE (as represented by a SERVICE PACKAGE). |
|
|
Reference |
A Service Bundle Spec Atomic object models different SERVICE BUNDLE SPECs as a set of different instances of individual, independent Element Facing Service Specs. This is fundamentally different than the SERVICE BUNDLE SPEC COMPOSITE entity, which models one SERVICE BUNDLE SPEC COMPOSITE as the combination of other existing SERVICE PACKAGE SPECs (as well as providing its own extensions). For example, assume that the Gold Package service offering (which is a subclass of Service Package, not SERVICE PACKAGE SPEC), requires two different CoS Service instances. This may be because the Gold Package service offering has two different groups of applications that require two different types of traffic conditioning mechanisms. This is represented by a Service Bundle Spec Atomic object. Now, assume that the Platinum Package service offering includes the Gold Package service offering and a new service offering requiring a new set of traffic conditioning mechanisms. This requires a second Service Bundle Spec Atomic object, as users want to reuse the first Service Bundle Spec Atomic object. These could be aggregated to form an instance of a SERVICE BUNDLE SPEC COMPOSITE entity. |
|
|
Reference |
A Service Bundle Spec Composite defines an integrated set of SERVICE BUNDLE SPECs that collectively meets the needs of a Element Facing Service Spec Composite entity. This is fundamentally different than the Service Bundle Spec Atomic object, which models one Service Bundle Spec as the combination of other existing SERVICE PACKAGE SPECs (as well as providing its own extensions). For example, assume that the Gold Package service offering (which is a subclass of SERVICE PACKAGE, not SERVICE PACKAGE SPEC), requires two different CoS Service instances. This may be because the Gold Package service offering has two different groups of applications that require two different types of traffic conditioning mechanisms. This is represented by a SERVICE BUNDLE SPEC ATOMIC entity. Now, assume that the Platinum Package service offering includes the Gold Package service offering and a new service offering requiring a new set of traffic conditioning mechanisms. This requires a second SERVICE BUNDLE SPEC ATOMIC entity, as you want to reuse the first SERVICE BUNDLE SPEC ATOMIC entity. These could be aggregated to form an instance of a Service Bundle Spec Composite object. |
|
|
|
Reference |
This is an association entity. The entity represents the semantics, for example, owns, uses, and other relationships, of a Business Actor using a particular SERVICE. |
|
Lookup |
Lookup for category of SERVICE. For example:
|
|
|
Reference |
This entity represents the key features of this Service Specification. For example, bandwidth is characteristic of many different types of services; if bandwidth is important (for example, from the point-of-view of a Customer purchasing this Service) then bandwidth would be a Service Characteristic for that particular SERVICE. Note that in this example, bandwidth would have to be defined as an invariant feature that multiple Services use. Otherwise, it should be defined as a Service Characteristic. |
|
|
Reference |
A use of the Service Spec Characteristic by an Service Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Service Spec Characteristic. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between or among Service Spec Characteristics. |
|
|
Reference |
A Service Spec Characteristic Value object defines a set of attributes, each of which can be assigned to a corresponding set of attributes in a Service Spec Characteristic object. The values of the attributes in the Service Spec Characteristic Value object describe the values of the attributes that a corresponding Service Spec Characteristic object can take on. |
|
|
Reference |
A use of the Service Spec Characteristic Value by an Entity Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Service Spec Characteristic Value. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Service Spec Characteristic Values. |
|
|
Lookup |
The class of the services. For QoS reason, the call can be divided into different classes (Basically might be home line or business line, or others). The Service Class can also be divided by other aspect, line utilizing Circuit Line or IP packets, and so on. |
|
|
Lookup |
Lookup for the type or base to define the SERVICE CLASS. |
|
|
Reference |
The geographic area covered by service provider with certain product combination. Service areas are defined so that service providers can determine the demographic / psychographic / population data the geography served by the network. |
|
|
Lookup |
Lookup for type code and description for SERVICE COVERAGE AREA. |
|
|
Reference |
The detail about service coverage on lowest level. For example:
|
|
|
Reference |
The Dependency among services. One service may depend on others to function, for example, GSM Roaming depends on HLR service to determine its subscription status, likewise, multiple ADSL services depends on the core IP network to transfer the information. |
|
|
Reference |
Captures the semantics involved in representing how a particular Element Facing Service is implemented on a specific DEVICE INTERFACE. |
|
|
Reference |
Assignments between NETWORK TOUCHPOINT, EQUIPMENT, and SERVICE according to which SERVICE was tied to which NETWORK TOUCHPOINT through which EQUIPMENT INSTANCE. |
|
|
Reference |
A special type of contract which keeps the agreement between a customer and the service provider specifying the service quality, including availability, bandwidth, and so on. The detailed terms of the service level agreement are specified in CONTRACT TERM VALUE. |
|
|
Reference |
Detail line items for a SERVICE LEVEL AGREEMENT. |
|
|
Lookup |
Lookup for type of all service levels. For example, the classification of service levels can be: Gold, Silver, Bronze. Each product may have different Service Level Agreement settings. |
|
|
Base |
The customer case of each violation to the SERVICE LEVEL AGREEMENT. |
|
|
Reference |
Quality goal for a Service Level Specification defined in terms of parameters and metrics, thresholds, and tolerances associated with the parameters. |
|
|
Reference |
The time of day or days during which a Service Level Specification, Service Level Objective, or Service Level Spec Consequence is relent or not. |
|
|
Reference |
An action that takes place when a SERVICE LEVEL OBJECTIVE is not met. |
|
|
Reference |
Specifies a variable whose value determines compliance with a Service Level Objective. |
|
|
Reference |
A pre-defined or negotiated set of service level objectives, and consequences that occur, if the objectives are not met. |
|
|
Lookup |
Lookup for the type of consequences if the service level requirement is not met. |
|
|
Reference |
This is an association entity. The Service LR Dependency represents the semantics (for example, exists, uses, and other relationships) that exist when a LOGICAL ELEMENT helps to supply or to support a particular Element Facing Service. |
|
|
Reference |
Defines how a network element supports a service. |
|
|
Base |
A type of Request that represents the products in a Customer Order decomposed into the services through which the products are realized. |
|
|
Base |
The purpose for the SERVICE ORDER expressed in terms of a SERVICE SPEC or a Service. |
|
|
Reference |
A Service Package is derived from an associated SERVICE PACKAGE SPEC. The SERVICE PACKAGE SPEC defines the invariant attributes, methods, relationships, and constraints for all Service Package instances that are derived from it. This entity enables each individual Service Package to add its own application-specific changeable characteristics and behavior. There is no specific aggregation used to relate a particular Service Package to the SERVICE PACKAGE SPEC that it is derived from. This is because the SERVICE PACKAGE SPEC and Service Package both inherit the Specifies Service aggregation, and at this (the business level) view, there are no new semantics that are required to represent this relationship. Finally, while the composite pattern could be applied to Service Package, there is no perceived need to do so. Multiple Service Packages will simply be aggregated by a Product Bundle, and appear as separate Product Components. |
|
|
|
Reference |
Defines how service bundle implements SERVICE PACKAGE. |
|
Reference |
Defines how a type of service bundle can support other types of SERVICE PACKAGEs. |
|
|
Lookup |
A Service Package Spec defines the concept of bundling a set of different CUSTOMER FACING SERVICE SPECs to meet the functionality specified by one or more Product Specifications. This entity enables the specification of the invariant characteristics and behavior of these CUSTOMER FACING SERVICEs, so that multiple PRODUCTs can be built from their associated Product Specification. Treating this set of CUSTOMER FACING SERVICE SPECs as a single object is important for building complex Services, such as a VPN. This entity enables a single Product Item, derived ultimately from a Product Specification, to be offered to the Customer, even though in reality the Product Item consists of a set of different CUSTOMER FACING SERVICEs that must work to provide the functionality that the Customer needs. |
|
|
Lookup |
A Service Package Spec Atomic object models different SERVICE PACKAGE SPECs as a set of different instances of individual, independent CUSTOMER FACING SERVICE SPECs. This is fundamentally different than the Service Package Spec Composite object, which models one SERVICE PACKAGE SPEC as the combination of other existing SERVICE PACKAGE SPECs (as well as providing its own extensions). For example, Gold Package Spec is an individual packaging of services, and is therefore an instance of the Service Package Spec Atomic entity. If there was a service offering that combined the services defined by the Gold Package Spec with those defined by another Service Package Spec Atomic entity, such as the Platinum Package Spec, then that combination could be aggregated, forming an instance of the Service Package Spec Composite entity. |
|
|
Lookup |
This models different packages as the combination of other existing SERVICE PACKAGEs (as well as providing its own extensions). This is fundamentally different than Service Package Atomic, which models different SERVICE PACKAGEs as a set of different instances. |
|
|
Reference |
A measure of the manner in which a SERVICE is functioning. |
|
|
Lookup |
The invariant characteristics of a measure of the manner in which a SERVICE is functioning. Each related PERFORMANCE instance will have the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE entity are specific to each instance. |
|
|
Reference |
This is an association entity. The Service PR Dependency represents the semantics (for example, exists, uses, and other relationships) that exist when a PHYSICAL ELEMENT helps to supply or to support a particular RESOURCE FACING SERVICE. |
|
|
Base |
Subtype of PARTY INTERACTION THREAD, specifically dedicated to a service request that may trigger a customer field service support order. |
|
|
Reference |
This entity defines a SERVICE in terms of a set of roles. The roles are then used to characterize the functionality of the Service, regardless of whether it is a Element- or a customer-facing service. Service Roles represent the functionality of a Service, and as such are a mix of the invariant and changeable characteristics and behavior of a Service. Representing a SERVICE in terms of Service Roles enables the functionality of the SERVICE to be defined independently of Business Actor, PHYSICAL ELEMENT, LOGICAL ELEMENT, or other Services. |
|
|
Reference |
This entity defines a Service Specification in terms of a set of roles. The roles are then used to characterize the invariant functionality of the Service, regardless of whether it is a resource- or a customer-facing service. Service Specification Roles represent the invariant functionality of a Service. Representing a SERVICE in terms of Service Specification Roles enables the functionality of the SERVICE to be defined independently of Business Actor, network element, or other Services. |
|
|
Reference |
This entity defines the ServiceSpecification hierarchy. All Services are characterized as either being directly visible and usable by a Customer or not. This gives rise to the two subclasses of Service: CUSTOMER FACING SERVICE and ElementFacingService. However, each instance of a Service is made up of changeable as well as invariant attributes, methods, relationships and constraints. A ServiceSpecification defines the invariant characteristics of a Service. It can be conceptually thought of as a template that different Service instances can be instantiated from. Each of these Service instances will have the same invariant characteristics. However, the other characteristics of the instantiated Service will be specific to each instance. This entity can be thought of as a template, which represents a generic specification for implementing a particular type of Service. A ServiceSpecification may consist of other ServiceSpecifications supplied together as a collection. Members of the collection may be offered individually or collectively. ServiceSpecifications may also exist within groupings, such as within a Product. |
|
|
Reference |
This entity defines SERVICE SPECs that do not have any subordinate SERVICE SPECs. In other words, a ServiceSpecAtomic is a standalone SERVICE SPEC, and does not require any supporting SERVICE SPECs to define the invariant characteristics of Services that it serves as a template for. |
|
|
Reference |
This entity defines SERVICE SPECs that are formed by aggregating other SERVICE SPECs. The types of SERVICE SPECs that are aggregated may be ServiceSpecAtomic or ServiceSpecComposite instances. A ServiceSpecComposite collectively defines all of the invariant characteristics of Services that it serves as a template for. |
|
|
Reference |
Defines the relationship between Service Spec and Network Element. For example, to track which Network Element Type is required for a certain type of Service Spec to work. |
|
|
Reference |
Defines the relationship between Service Spec and Product, for example, to track which Product requires which Service Spec. |
|
|
Reference |
This entity represents the ability to distinguish between different instances of SERVICE SPECs. It represents a particular form or variety of a SERVICE SPEC that is different from others or from the original. The form represents differences in attributes, methods, relationships, and/or constraints that characterize this particular SERVICE SPEC, but which are not enough to warrant creating a new SERVICE SPEC. |
|
|
Lookup |
Lookup for all status types of a SERVICE. For example:
|
|
|
Lookup |
A category that categorizes similar SERVICE STATUS. |
|
|
Base |
A history of the Status of a SERVICE. Such as active, inactive, defaulted, terminated. |
|
|
Lookup |
Lookup for reasons why a SERVICE has a certain status. |
|
|
Lookup |
Lookup for types of SERVICE. For example, values should be from a subtype of: CUSTOMER FACING SERVICE RESOURCE FACING SERVICE COMPOSITE SERVICE |
|
|
Lookup |
This entity defines Service Specifications that do not have any subordinate Service Specifications. In other words, a Service Spec Atomic is a standalone Service Specification, and does not require any supporting Service Specifications to define the invariant characteristics of Services that it serves as a template for. |
|
|
Lookup |
This entity defines Service Specifications that are formed by aggregating other Service Specifications. The types of Service Specifications that are aggregated may be Service Spec Atomic and/or Service Spec Composite instances. A Service Spec Composite collectively defines all of the invariant characteristics of Services that it serves as a template for. |
|
|
Lookup |
Represents the ability to distinguish between different instances of Service Specifications. The Service Type Version represents a particular form or variety of a Service Specification that is different from others or from the original. The form represents differences in attributes, methods, relationships, and/or constraints that characterize this particular Service Specification, but which are not enough to warrant creating a new Service Specification. |
|
|
Lookup |
A detailed description of a service usage event (for example, a purchase or a usage of a service). |
|
|
Reference |
Set-top box for Television service. |
|
|
Reference |
Set-top box model specification. |
|
|
Derived |
Daily aggregate of Lines Count by PRODUCT MARKET PLAN. For example:
|
|
|
Aggregate |
Monthly summary of Lines Count by PRODUCT MARKET PLAN. The usage and profitability is analyzed in this entity. For example:
|
|
|
Reference |
A Shelf is a type of Equipment Holder that is designed to hold various types of Equipment. The Shelf has a logical identifier that is often relative to the Bay that contains the Shelf (that is, the unique identifier for a Shelf is often a concatenation of the network element identifier, the Bay identifier, and the Shelf identifier). The logical identifier of a Shelf is typically associated with the Device (that is, the Network Element). Compare this to a RACK, whose logical identifier is not associated with the Device. Thus, the Shelf is explicitly a part of the logical model of a network. Often, a Shelf contains not just pluggable components (for example, CARDs, Power Supplies, and so on) but also cabling (for example, both fiber and wire), with optional connections to external fuse, alarm, and other types of panels. |
|
|
Derived |
Daily aggregate of shop efficiency details including customer and transaction counts, wait times, and so on, by ORGANIZATION BUSINESS UNIT and GEOGRAPHY REGION. |
|
|
Aggregate |
Monthly summary of shop efficiency details including customer and transaction counts, wait times, and so on, by ORGANIZATION BUSINESS UNIT and GEOGRAPHY REGION. |
|
|
Reference |
Assigns one industry to another industry in Standard Industrial Classification (SIC). |
|
|
Lookup |
Lookup for reason codes and descriptions that describe why two industries are assigned in the Standard Industrial Classification (SIC). |
|
|
Lookup |
A classification group for Standard Industrial Classification (SIC). For example: A. Division A: Agriculture, Forestry, And Fishing:
|
|
|
Reference |
The base level of SIC classification. For more information see SIC CLASSIFICATION. |
|
|
Lookup |
The middle level of the industry classification hierarchy. |
|
|
Reference |
This entity represents different types of signaling protocols that can be managed. Signaling protocols are used to convey information along a specific path. Represents a convenient aggregation point for defining how signaling protocols are managed and used. |
|
|
Reference |
A subscriber identity module (SIM) on a removable SIM card securely stores the service-subscriber key (IMSI) used to identify a subscriber on mobile telephony devices (such as a mobile phone). Also used for UIM (User Identity Module) in the CDMA (Code Division Multiple Access) network. |
|
|
Reference |
A history of relationship between ACCESS METHOD and SIM CARD. Many access methods can be assigned to one SIM Card at any given time. |
|
|
Lookup |
Lookup for valid reason codes and descriptions to describe relationship between SIM CARD and ACCESS METHOD. |
|
|
Lookup |
Lookup for valid reason codes and descriptions describing why a SIM CARD has been activated. |
|
|
Lookup |
Usage states that a SIM CARD may be in. For example:
|
|
|
Reference |
A history of relationship between a HANDSET INSTANCE and a SIM CARD. SIM Cards can be swapped between handsets. |
|
|
Reference |
A history of relationship between the SIM CARD and a SUBSCRIPTION. |
|
|
Lookup |
A reason why a SIM CARD is associated with a SUBSCRIPTION. |
|
|
Lookup |
Lookup for the types of SIM CARD. For example:
|
|
|
Reference |
Site is any geographical location of interest to the telecom operator. |
|
|
Reference |
This role defines a Customer Site - that is, an interface to a set of Customers. The objective of this role is to enable the definition of Policies such that all Customers in this Site can receive the same Services. For example, routing announcements, traffic marking, and so on. |
|
|
Lookup |
Lookup of all possible types of sites of interest to the service provider. |
|
|
Lookup |
Lookup of available skill types for an individual party. |
|
|
Reference |
This is a concrete entity that has two main purposes. One is to model the ability of a hosting board to accept a daughter card to add or complete the base functionality of the hosting board. The second is to represent the different expansion slots supported by a CHASSIS. |
|
|
Reference |
This entity represents the semantics of the Adjacent Slots association. The SLOT Relationship includes two attributes that are used to provide general layout information describing the SLOTs in the Equipment Holder. The first, Distance Between Slots, defines the distance in inches between two adjacent SLOTs in the Physical Package. The second, Shared Slots, is a boolean attribute that describes the dependency between two SLOTs that are located near each other. Sometimes, the two SLOTs are so close that if one of these SLOTs is populated by an adapter CARD, the other SLOT must be left empty. If this attribute is set to TRUE, then the second SLOT must be left unoccupied. |
|
|
Reference |
Subtype of VALUE ADDED SERVICE. This entity defines the information relative to the Short Message Service (SMS). Do not confuse this entity with SMS EVENT. |
|
|
Base |
Subtype of NETWORK EVENT, which collects all information of product usage of Short Message Service (SMS). |
|
|
Reference |
Subtype of PRODUCT RATING PLAN, reserved for Short Message Service (SMS), and also Multimedia Messaging Service (MMS), service. |
|
|
Reference |
Entity holds the most detailed level of Standard Occupational Classification (SOC) job classification. For example:
|
|
|
Reference |
Lookups for the categories in the Standard Occupational Classification (SOC) in which each occupation in the SOC is placed. The hierarchy in SOC is typically: NN-MMM0. These job categories correspond to the 449 "broad occupations" or categories. For example:
|
|
|
Reference |
Lookups for the groups in the Standard Occupational Classification (SOC) in which each occupation in the SOC is placed. The hierarchy of SOC is typically: NN-MM00. For example:
|
|
|
Reference |
Lookups from the (23) major groups in the Standard Occupational Classification (SOC) in which each occupation in the SOC is placed. The hierarchy of SOC is typically: NN-0000. For example:
|
|
|
Reference |
This entity represents software. Software represents the set of user visible functions and processes that are contained in a device. The Has Software Features association defines software that is associated with a LOGICAL DEVICE, such as programs and operating systems. Since this software can be associated with devices and/or device components, this association is defined between the roots of the two classes. Software may be nested within other software, thereby creating a containment relationship (which is part of the system view). Currently, the subclasses of this class reflect user-facing features. For example, features that are manageable, configurable, and executable by users and applications. Internationalization and Language functionality are supported by creating a Software Uses Language association to the Language classes. |
|
|
Reference |
This entity represents atomic units of software that are individually manageable and do not form composite, or nested, software units. From a finite state machine view, each Software Atomic element is not just individually manageable, but is also installable, executable, and runnable. In addition, each Software Atomic element can be a FRU. This is the super-class for creating concrete subclasses that define particular functionality. For example, a device driver, or software that implements MPLS as part of a larger routing software package. |
|
|
Reference |
Software Commands describe the sets of features that are programmable by a particular PARTY ROLE. For example, a Developer, or Network Operator, and in rare cases, an End User. This should not be confused with Capabilities. Capabilities define what features and functions are available at a given moment for the Element. Thus, Software Commands represent the specific commands that are available in a device, whereas Capabilities represent higher-level generic functions available in a Element. For example, the ability to perform BGP routing is a Capability, whereas the actual commands used to implement BGP routing are Software Commands. |
|
|
Reference |
This entity represents software units that are made up of other software units (that is, instances of this entity and the Software Atomic base entity). This provides the semantics of collecting a set of components, each of which is individually manageable, and being able to manage the set of objects as a whole. An example is an operating system - this is manageable as a unit, but consists of individually manageable components. This containment is modeled using the Contains Software Components composition. From a finite state machine view, each Software Composite element is manageable, installable, executable, and runnable. In addition, each Software Composite element can be a FRU. This is the super-class for creating concrete subclasses that define groups of functionality. For example, set of features that work to provide application-level functionality to the end-user. |
|
|
Reference |
Software Feature Sets describe the groups of Software Commands that distinguish a particular release of Software. The Software Commands contained in the Software Feature Sets are programmable by a particular PARTY ROLE (for example, a Developer, or Network Operator, and in rare cases and End User). Often, Software Feature Sets are used by the manufacturer to define a custom or semi-custom build of software, or are provided as a set of options that are orderable by the Customer. This should not be confused with Capabilities. Capabilities define what features and functions are available at a given moment for the Element. Thus, Software Feature Sets represent groups of commands that are available in a device, whereas Capabilities represent higher-level generic functions available in a Element. For example, the ability to perform BGP routing is a Capability, whereas the actual commands used to implement BGP routing are Software Commands that reside in one or more Software Feature Sets. Hence, Software Feature Sets may or may not offer BGP as a programmable feature. |
|
|
Reference |
This is an association class, and defines the semantics of the Software Interacts With OS association. This is a complex class, and consequently only a few simple attributes are shown in this viewpoint in order for the reader to get a flavor of the types of parameters defined in this entity. |
|
|
Reference |
System of record from which information was loaded. |
|
|
Reference |
Track Key of the PARTY, customer or employee, in the originating source system. This key can track information back to the source management system. |
|
|
Lookup |
Lookup for type code and description used to describe SOURCE SYSTEM. For example:
|
|
|
Reference |
This is an entity that defines the invariant characteristics, attributes, methods, and relationships, of a managed entity. |
|
|
Reference |
This is the entity for all Role Specification subclasses. |
|
|
Reference |
The geographic coverage area of a given wireless spectrum. |
|
|
Reference |
To be defined |
|
|
Reference |
An abstraction provided by the Element Management System (EMS) to the Network Management System (NMS) that describes the potential for subnetwork connections. The Sub Network also provides a transparent end-to-end connection or a TRAIL, closed or half-open, through a Subnetwork according to the roles associated to its end points. |
|
|
Lookup |
Lookup for valid Subscriber activation code and reasons used to describe Subscriber Activation. For example:
|
|
|
Reference |
The record of customer using a product or service which may be based on a contract. Customer's subscription to services is the basis of billing and network usage authorization. |
|
|
Reference |
Relational assignment of one SUBSCRIPTION to another SUBSCRIPTION. This is optional. |
|
|
Lookup |
Lookup for type codes and descriptions pertaining to SUBSCRIPTION ASSIGNMENT. |
|
|
Lookup |
Lookup for available type codes and descriptions for Subscription Events. |
|
|
Reference |
Defines the relationship between SUBSCRIPTION and the NETWORK ELEMENT ROLE. |
|
|
Reference |
The relationship between SUBSCRIPTION and PRODUCT MARKET PLANs. A SUBSCRIPTION may be reassigned to different PRODUCT MARKET PLANs during its lifetime. |
|
|
Reference |
Charge information over a specific subscription. |
|
|
Reference |
Price alteration applied to the given subscription. |
|
|
Reference |
The monetary charge applied to an individual subscription, as a subtype of SUBSCRIPTION PRICE. |
|
|
Reference |
The relationship between the Party Role and SUBSCRIPTION PRICE to track who managed the SUBSCRIPTION PRICE. |
|
|
Reference |
The relationship between SUBSCRIPTION and SERVICE. One subscription may be used to rate multiple services. For example, WCDMA 3G Data + Wifi, and vice versa. One service, for example a gsm mobile, may support multiple products (calling minutes, discounts, and so on). |
|
|
Reference |
Defines the class of service for a SUBSCRIPTION. |
|
|
Derived |
Monthly aggregate of subscriber Churn information by ACCOUNT, PRODUCT MARKET PLAN, SALES CHANNEL, AGE BAND, AGE ON NET BAND, CREDIT CATEGORY, DEBT AGING BAND, CUSTOMER REVENUE BAND, ARPU BAND, CUSTOMER. |
|
|
Aggregate |
Monthly summary of Subscriber Churn by PRODUCT, PRODUCT MARKET PLAN, CUSTOMER TYPE, GEOGRAPHY ENTITY, ORGANIZATION BUSINESS UNIT. |
|
|
Lookup |
Lookup for available code and description for the status of a SUBSCRIPTION. For example:
|
|
|
Lookup |
Lookup for category codes and descriptions used to group or categorize SUBSCRIPTION STATUS. |
|
|
Base |
A history of the status of a SUBSCRIPTION. For example:
The subscription can simultaneously contain multiple status. For example, the subscription could be Active and In_Debt, or amount below threshold. |
|
|
Lookup |
Lookup for available reason codes and descriptions for defining why a SUBSCRIPTION may be assigned a status. |
|
|
Lookup |
Lookup for available code and description for the status of a SUBSCRIPTION. For example:
A subscription can simultaneously have two statuses. For example, a subscription could be Active and In Debt, or an amount below a threshohld, at the same time. |
|
|
Lookup |
Lookup for available type codes and descriptions pertaining to SUBSCRIPTIONs and PRODUCTs to which Values may be assigned. For example:
|
|
|
Base |
Value assignments for Subscription Terms as pertains to a SUBSCRIPTION and PRODUCT. For example:
The value can vary at different time periods. For example, the monthly fee might be 100 for first six months, and 80 for last six months. A penalty calculation can also be assigned based on the months left in a contract. |
|
|
Lookup |
Lookup for available type codes and descriptions for SUBSCRIPTIONs. For example:
|
|
|
Aggregate |
Monthly summation of the amount budgeted for the items to be given on subsidy by PRODUCT MARKET PLAN, and CUSTOMER TYPE, excluding the NVP scheme items and give-away items. |
|
|
Derived |
Monthly aggregation of the amount budgeted for the items to be given on subsidy by PRODUCT MARKET PLAN and CUSTOMER TYPE, excluding the NVP scheme items and give-away items. |
|
|
Lookup |
Lookup for type code and description of a Subsidy. |
|
|
Reference |
Subtype of PRODUCT that may include supplementary services to complement and support existing services such as telephone and data services. For example:
|
|
|
Derived |
Keep the aggregation information for usage of supplementary service. Analyze SUPPLEMENTARY SERVICE for the Core Network Planning. |
|
|
Aggregate |
Monthly summation of Charge and Billing details for SUPPLEMENTARY SERVICE usage by Business Unit, PRODUCT MARKET PLAN, and PRODUCT. |
|
|
Reference |
A survey is a subtype to the PROMOTION. |
|
|
Reference |
Network switches or exchanges. A switch may be a PSTN (wireline) digital or analog, or a GSM Mobile Station controller (wireless). |
|
|
Reference |
Records the specific functional characteristics of each switch or exchange. The types of capabilities of interest are those that enable customer services; this entity enables the operator to identify if customers on a particular switch can utilize a certain service (for example, VPN). |
|
|
Lookup |
Lookup for type codes and descriptions used to categorize SWITCH CAPABILITY. |
|
|
Reference |
Command which is sent to the switch, telling it to take an action. For example, activate a port with specified parameters. |
|
|
Reference |
Assigns a routing device to a switch in any type of network. |
|
|
Lookup |
Classification of Switch Type and Manufacturer. |
|
|
Reference |
This entity represents different types of switching protocols that can be managed. Switching protocols are those protocols that enable routing to take into account layer 2 information, such as bandwidth and QoS. (Remember that traditional routing protocols are designed to evaluate each frame's layer 3 header only). Several methods are available for accomplishing the task of looking at layer 2 information and defining a next hop. Most now use the concept of a label, which is a means to define the next hop without evaluating all of the information of a traditional header. |
|
|
Reference |
Abstracts the different routing capabilities necessary for a LOGICAL DEVICE to have. This helps simplify the modeling of (especially) network devices, which have many different sets of capabilities. For example, most routers can do routing, forwarding, and firewalling of traffic. By modeling these capabilities as three roles, switch functionality is both abstracted and categorized, so that the differences between forwarding traffic done by a router and forwarding traffic done by a L3 switch can be differentiated. |
|
|
Lookup |
A Strength, Weakness, Opportunity, Threat (SWOT) that an enterprise has when compared to a COMPETITOR. SWOT analysis is a formal framework of identifying and framing organizational growth opportunities. |
|
|
Base |
Network events invoked by our customer on partners network. Those events should be attached to the account for billing purposes. |
|
|
Base |
Network events by partner customer on the operator network. |
|
|
Reference |
The ACCESS METHODs associated with a PROMOTION. |
|
|
Reference |
||
|
Reference |
||
|
Reference |
GEOGRAPHY ENTITYs targeted by a PROMOTION. |
|
|
Reference |
The MARKET SEGMENTs included in a specific CAMPAIGN. |
|
|
Lookup |
Lookup for valid Type codes and descriptions as pertain to a PROMOTION. For example:
|
|
|
Reference |
The specific tasks inside a PROJECT. |
|
|
Reference |
A government authority that levies sales taxes and on whose behalf the store collects these sales taxes. For Example:
|
|
|
Lookup |
The tax categories which may be applied to invoices items. |
|
|
Lookup |
Lookup for valid tax exempt codes and descriptions as pertains to an ITEM. |
|
|
Lookup |
Lookup for the types of Traffic Channel. For example:
|
|
|
Lookup |
Technology names and descriptions that can define a NETWORK ELEMENT. For example:
|
|
|
Lookup |
Lookup for available type codes and descriptions that can classify or categorize a TECHNOLOGY. For example:
|
|
|
Reference |
The phone number as a subtype of access method. |
|
|
Reference |
The telephone number pool allocated to the TELCO operator. |
|
|
Reference |
The template for SERVICE LEVEL AGREEMENT spec. |
|
|
Reference |
This entity is for terminates transport entities, such as trails and connections. This object class is a basic object class from which subclasses, such as Trail Termination Point and CONNECTION TERMINATION POINT, are derived. |
|
|
Lookup |
Band of call duration. For example:
|
|
|
Reference |
Reference entity defining the time slot within a DAY in relation to HOURs, HALF HOURs and QUARTER HOURs. This is used in all time derived and aggregation tables. |
|
|
Reference |
Relates the calendar day to a season and to a standard day. Specifies the relationship between a given day and all days of a given season up to that day. |
|
|
Reference |
Relates the calendar week to a season and to a standard week. Specifies the relationship between a given week and all days of a given season up to that week. |
|
|
Lookup |
Lookup for the Geographic time zone as related to the Greenwich Mean Time (GMT +0.00). |
|
|
Reference |
Trail is a class of managed objects in layer networks which is responsible for the integrity of transfer of characteristic information from one or more other layer networks. A Trail is composed of two Trail Termination Points and one or more Connections and associated CONNECTION TERMINATION POINTs. |
|
|
Reference |
This entity groups different types of Trail Termination Points. This entity enables a single composition (CTPsInTrail) to be run to this entity, which is then inherited by its subclasses. This is deemed better than building three relationships between the (currently) three types of Trail Termination Points and the CTP class. Note that each has the same containment relationship. |
|
|
Reference |
Type of PRODUCT INSTANCE associating a Television Channel with a PTV USAGE EVENT. |
|
|
Lookup |
Lookup for valid type codes and descriptions for Unified Messaging Services (UMS). The UMS access type indicates the way customers are accessing their mailboxes. This is especially applicable to UMS users who can access their mailbox ether using the standard method, with a specified number or by using Internet mail. |
|
|
Base |
Subtype of NETWORK EVENT. In the UMS notification type dimension, Unified Messaging Service (UMS) is an advanced version of Voice Message Service (VMS). As it is possible to notify the subscriber using UMS by either SMS or by internet mail, similarly a subscriber can access a mailbox in different ways, including by calling a standard access number or through the internet. The information related to UMS access is to be analyzed by the type of access. UMS access type dimension will be used to fulfill this requirement. |
|
|
Lookup |
Lookup for the type of UMS events. For example:
|
|
|
Lookup |
Lookup for possible measurement units valid for the data within the system. For example:
|
|
|
Reference |
The property address in the format of an urban area. |
|
|
Reference |
Associative entity for EMPLOYEE, JOB ROLE, Business Unit; associates a unique ID for every job role that an employee performs at a particular business unit. An employee appears only one time in the EMPLOYEE entity, but in USER entity, the employee appears on time for each job role at each business unit. |
|
|
Reference |
Type of product consisting of supplementary or value added services such as Call Forward, Call barring, CLI, CLIR, UMS, or VMS. |
|
|
Reference |
This entity provides two basic attributes to define custom value objects that can be used in an application-specific fashion. These two attributes are called valueModelAttribute and valueModelClass. The valueModelAttribute is a string attribute that defines the name of the attribute within the entity specified in the valueModelClass attribute that is to be evaluated or set as a POLICY VALUE. The valueModelClass is a string attribute that defines the entity name whose attribute is to be evaluated or set as a POLICY VALUE. This combination enables new custom subclasses of Value Custom to be defined that specify the entity and attribute that they are modeling. These new subclasses can be found by users of the current the model schema by searching for these two properties. That also enables the model users to immediately understand the purpose of new extensions. |
|
|
Lookup |
Lookup for unit of measure for the value. For example a customer or a profile can be valued in terms of monetary value or time (a customer for next three years). |
|
|
Reference |
This is the abstract base entity for defining a set of standardized POLICY VALUEs. This set of POLICY VALUEs will be added to over time, and represents a set of common values that are useful in a variety of PBNM applications. The subclasses of Value Standard are a set of classes that define the semantics of commonly occurring variables that occur in PBNM applications. |
|
|
Lookup |
Lookup for available type codes and descriptions pertaining to defining the derived value of a CUSTOMER or PROSPECT. |
|
|
Reference |
There are two subclasses of POLICY VARIABLE, called Variable Custom and Variable Standard. The Variable Custom entity defines a set of standardized policy variables for use in an application-specific manner. The term "custom" means that such variables are explicitly designed to work with attributes that are not in any of the model Variable Standard subclasses. Thus, the particular semantics, including any applicable constraints, are not known to the model. This entity provides two basic attributes to define custom variables to use in an application-specific fashion. |
|
|
Reference |
This entity defines a standard set of POLICY VARIABLE objects that are common to most PBNM applications. |
|
|
Reference |
Type of Subscription that includes VALUE ADDED SERVICE. |
|
|
Aggregate |
Monthly Summary of VALUE ADDED SERVICE Details by CUSTOMER TYPE. |
|
|
Derived |
Monthly Aggregation of VALUE ADDED SERVICE Details by CUSTOMER and ACCESS METHOD. |
|
|
Derived |
Daily usage statistics for all value added services that are content based (and some others). This includes: M2M, P2P, and SMS, MMS, ringtone, music, video, email, Universal (Voice/Email) message, and others. |
|
|
Aggregate |
Monthly aggregation of VAS usage statistics, from VAS USAGE DAY DRVD. |
|
|
Reference |
The vehicles owned and used by the operators to fulfill its business requirement. |
|
|
Reference |
Supplier or source of equipment or supplies. |
|
|
Base |
Single or recurring appointment times allocated for VENDOR representative to visit the Provider or Retail Site. |
|
|
Lookup |
Lookup for the classification of Vendors. For example:
|
|
|
Reference |
Time bound agreement with VENDOR. |
|
|
Reference |
Defines the relationship between VENDOR and FACTOR COMPANY. |
|
|
Reference |
Score assigned to VENDOR based on performance criteria. |
|
|
Lookup |
Lookup for type codes and descriptions of VENDOR RATING performance criteria. |
|
|
Reference |
A Site or Location associated with a VENDOR from which VENDOR may do business with Provider. A Vendor site may be an Office, Warehouse, Dispatch Center, and so on. |
|
|
Reference |
Association of VENDOR SITE with COURIER code (from the goods transportation perspective). |
|
|
Lookup |
Lookup for valid type codes and descriptions pertaining to VENDOR SITE. For example:
|
|
|
Reference |
Type of Business Unit formed for a specific purpose. For example:
|
|
|
Reference |
Subtype of SERVICE. |
|
|
Derived |
Daily aggregate of Voice Call statistics by TIME SLOT, Business Unit, County, PRODUCT, CUSTOMER TYPE, Call Source, Call Destination, CALL DIRECTION, Call Success/Failure, Roaming Service. |
|
|
Base |
The subtype of Network event, specialized for Voice Over IP (VOIP) Calls. |
|
|
Aggregate |
Monthly Summary of Voice Call statistics by Business Unit, County, PRODUCT, CUSTOMER TYPE, CALL CATEGORY, CALL DIRECTION, Call Success/Failure. |
|
|
Lookup |
Characterizes network events by volume. The volume characteristic may be in units of bytes, minutes, packets, downloads. The entity is used as part of the rating of calls and other network events. |
|
|
Reference |
A VPNRole is the superclass for various types of VPN role classes. For example, MPLS VPNs will use the CPELogicalDeviceRole, PELogicalDeviceRole, and PLogicalDeviceRole subclasses of this entity to abstract functionality required for the CPE, PE, and P roles of an MPLS VPN. Other types of VPNs use other subclasses of the VPNRole class. The advantage of this class is that it enables different types of VPN roles to be specified by an MPLSVPNServiceSpecification. |
|
|
Reference |
The VPN service currently used by the customers. |
Table 2-29 W to Z Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Reference |
WAN Protocols operate at the lowest three levels of the OSI model, that is, physical, data link, and network. Use WAN Protocols define communications over different types of wide-area media. |
|
|
Reference |
Reference of the various “weather” conditions, in a very general sense, affecting a given day. There is a difference between internal "weather" (a flood in a store, an employee strike, and so on) and external "weather" (storm, flood, snow, and so on). This information is useful in relation to a network failure. |
|
|
Base |
The history of customer navigation path in web visit. |
|
|
Reference |
A web page on a service operator Web site. The Web page may present a product or handle a customer service request. |
|
|
Reference |
Content of a WEB PAGE, links WEB PAGE to its relevant entity, including product, script, and so on. |
|
|
Lookup |
Lookup for type of WEB PAGE rendering. For example:
|
|
|
Lookup |
Web page type groups the web pages according to their content and purpose. For example:
|
|
|
Reference |
Cumulative time transformations at the week level. |
|
|
Reference |
Time transformations at the week level. |
|
|
Reference |
Calendar weekdays. |
|
|
Base |
Defines occurrence of wireless call. |
|
|
Base |
Type of network event, to track wireless content downloading such as music, video clips, and so on. |
|
|
Derived |
Derived from NETWORK ELEMENT Hierarchy for analytical purposes. |
|
|
Reference |
Subtype of PRODUCT RATING PLAN, reserved for wireless voice and data services. |
|
|
Base |
The wireless call event which roams across operators, including TAP IN and TAP OUT events. This entity is designed according to GSMA (Global System for Mobile communications) official document TD.57. |
|
|
Base |
The batch which includes roaming events as details. This batch normally appears in one TAP file. |
|
|
Reference |
The wireless services that the customer is using. For example:
|
|
|
Reference |
The wireless spectrum used in service provider network. |
|
|
Reference |
Transformations at the year level. |
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|