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 athttps://support.oracle.com.Table 2-2 lists the entities associated with the subject area Account.
Table 2-3 lists the entities associated with the subject area Agreement.
Table 2-4 lists the entities associated with the subject area Billing.
Table 2-10 lists the entities associated with the subject area Business Interaction.
Table 2-6 lists the entities associated with the subject area Click Stream.
Table 2-7 lists the entities associated with the subject area Cost.
Table 2-8 lists the entities associated with the subject area Customer.
Table 2-9 lists the entities associated with the subject area Customer Field.
Table 2-10 lists the entities associated with the subject area Employee.
Table 2-11 lists the entities associated with the subject area Event.
Table 2-12 lists the entities associated with the subject area Financial GL Cost and Asset.
Table 2-13 lists the entities associated with the subject area Flexible Characteristics.
Table 2-14 lists the entities associated with the subject area Loyalty Program.
Table 2-15 lists the entities associated with the subject area Number Porting.
Table 2-16 lists the entities associated with the subject area Party.
Table 2-17 lists the entities associated with the subject area Party Partners Vendor Roaming Content.
Table 2-18 lists the entities associated with the subject area Payment.
Table 2-10 lists the entities associated with the subject area Prepaid Balance and Voucher.
Table 2-20 lists the entities associated with the subject area Problem.
Table 2-21 lists the entities associated with the subject area Process.
Table 2-22 lists the entities associated with the subject area Product Offering and Product Subscription.
Table 2-22 Entities of Subject Area: Product Offering and Product Subscription
| Product Offer and Product Subscription Entity List |
|---|
|
PRODUCT SPECIFICATION CHARACTERISTIC CONFIGURABLE ASSIGNMENT |
Table 2-10 lists the entities associated with the subject area Product Subscription.
Table 2-10 lists the entities associated with the subject area Product and Product Specification.
Table 2-10 lists the entities associated with the subject area Promotion and Campaign.
Table 2-10 lists the entities associated with the subject area Quality of Service (QoS).
Table 2-10 lists the entities associated with the subject area Resource.
Table 2-10 lists the entities associated with the subject area Service and Service Specification.
Table 2-10 lists the entities associated with the subject area UDR Event.
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 About 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-30 lists the logical entities for Cost.
Table 2-31 lists the logical entities for Customer Management.
Table 2-32 lists the logical entities for Marketing.
Table 2-33 lists the logical entities for Network.
Table 2-34 lists the logical entities for Partner Management.
Table 2-35 lists the logical entities for Product Management.
Table 2-36 lists the logical entities for Provisioning and Service.
Table 2-37 lists the logical entities for Revenue.
Table 2-38, Table 2-39, Table 2-40, Table 2-41, Table 2-42, Table 2-43, and Table 2-44 list the logical data model entities, in alphabetical order.
Table 2-38 A to C Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Reference |
Semantics that define how traffic is forwarded based on the value of the priority field in the 802.1P header. |
|
|
Reference |
Methods that a customer accesses or uses as 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 |
Assigns ACCESS METHOD(s) to a PRODUCT SUBSCRIPTION. |
|
|
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:
|
|
|
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 |
A physical instance of ACCESSORIES which customer has got as part of an option or add-on. An instance can be a specific Handset cover or headset (with Serial Number), loudspeakers, and so on. |
|
|
Reference |
The account is generated by a agreement 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 website or from a Service Provider terminal. In this case the account is normally protected by a password. |
|
|
Base |
Billing cycle status history for ACCOUNTs. |
|
|
Lookup |
Lookup of all the reasons for adjustments. For example:
|
|
|
Reference |
||
|
Reference |
Relationship assignments between ACCOUNTs. For example, parent and child accounts. |
|
|
Lookup |
Lookup for available reasons ACCOUNTs may be related. |
|
|
Reference |
The type of relationship between two ACCOUNTs. For example, a corporate account has several affiliated accounts. |
|
|
Base |
This entity keeps a snapshots of ACCOUNT BALANCEs, at different period of time and for different ACCOUNT BALANCE TYPE. |
|
|
Lookup |
Lookup of all the types of adjustments. For example:
|
|
|
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 |
The account balance change details, because of a specific event. For example:
|
|
|
Derived |
Daily aggregate of free minutes allowance (PPA) for ACCOUNT and PRODUCT OFFERING. |
|
|
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. |
|
|
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 agreement. |
|
|
Base |
Information about the ACCOUNT and debt collection process, as soon as an ACCOUNT is tagged as being in debt until the day it is resolved (included). |
|
|
Base |
History tracking of the evolution of the debt process per individual ACCOUNT. |
|
|
Aggregate |
The summarized monthly debt status for each CUSTOMER TYPE. |
|
|
Derived |
Summery of payment and collection by internal collector. |
|
|
Lookup |
Lookup for account event types. |
|
|
Derived |
Collects first usage and payment per account. This entity should be filled once and updated maximal twice per account (one for payment, one per incoming and outgoing usage). It is then never touched. |
|
|
Derived |
Collects last usage and payment per account. This entity should be filled at least every day per account until full account deactivation. |
|
|
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 OFFERING. |
|
|
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. |
|
|
Derived |
Daily aggregation of payments made by all customers. |
|
|
Reference |
Contains preferred payment methods for the account. |
|
|
Base |
Status history of each account preferred payment method. For example:
|
|
|
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 |
Association of an ACCOUNT PAYMENT to a specific PAYMENT PLAN (after agreement). This association is critical to control whether the PAYMENT PLAN is fulfilled on time or not. |
|
|
Reference |
Association of a PAYMENT PLAN to an ACCOUNT. |
|
|
Reference |
The preferred invoice delivery type history for ACCOUNT. |
|
|
Base |
Defines the history of how account uses the PRODUCT OFFERING. |
|
|
Reference |
History of subscriptions by an ACCOUNT. |
|
|
Lookup |
Each account to subscription relationship may have a reason associated with it. For example:
|
|
|
Reference |
Records more details about the ACCOUNT. |
|
|
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. |
|
|
Aggregate |
Monthly summary per ACCOUNT for subscriptions, ARPU, Lifespan, and so on. |
|
|
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. |
|
|
Reference |
Association of TAX EXEMPTs to accounts. There may be several tax exemptions for a given account. |
|
|
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:
|
|
|
Base |
Any events that lead to an increase in Loyalty Points to any membership account (loyalty). This entity focuses on the origin (type, organization or partner, and so on) of the increase of points (and the amount). The events that could feed Loyalty Program Event as earning points should all come from Billing System, whatever their origin (usage, customer order, payment and so on). Retail Transactions could also feed this entity. |
|
|
Lookup |
Helps to categorized activity events. Typically there are four categories:
|
|
|
|
Lookup |
Type of relationship between (employee) activities. This entity is not physicalized. |
|
Lookup |
Lookup for available Result Types for EMPLOYEE activities. For example: 1000 - Successful 2000 - Failed 5000 - Pending |
|
|
Lookup |
Type of EMPLOYEE activities, used for grouping and reporting purpose. |
|
|
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 |
Association of an ADDRESS LOCATION to a given ADMINISTRATIVE AREA.Since there can be several levels of jurisdictions and administration, there can be several administrative areas associated with the same address location. Normally, in case of clear administrative hierarchy (for example, Local finance administration and country level finance administration), the lowest possible level should only be used. |
|
|
Reference |
Tracks other names used by the same ADDRESS LOCATION. |
|
|
Reference |
Phone Numbers given by individuals or organization as contact data (typically from Retail Shops). It should not be used to store the ACCESS METHOD. It is used from a loyalty retail perspective. |
|
|
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:
|
|
|
Base |
History of the status for any ADDRESS LOCATION. For example: Active, Obsolete |
|
|
Lookup |
Lookup for the reason for a change to the current ADDRESS STATUS. |
|
|
Lookup |
Lookup for address types. For example:
|
|
|
Lookup |
Type of verification for the address (automatic, manual, 3rd party, and so on). |
|
|
Base |
Represents the "on demand" or "adhoc" Statistics Collection, that are not part of the standard statistics collection flow or process. It is typically triggered by EMPLOYEE after a network fault, an alarm, or a service problem. |
|
|
Lookup |
Type of INVOICE ADJUSTMENT. |
|
|
Reference |
Area defined by an administration; necessarily associated with a jurisdiction of any type. For example: MUNICIPALITY CENSUS DISTRICT ELECTORAL AREA COUNTY PARISH |
|
|
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. |
|
|
Reference |
Defines how to forward network traffic by adding specific semantics that characterize the operation of the Assured Forwarding (AF) Service (RFC2597). |
|
|
Lookup |
Lookup to bin the customer into different groups according age. For example:
|
|
|
Lookup |
Group of ages for Individual only; should be filled with what Marketing requires. |
|
|
Lookup |
Defines subscriber life cycle ranges. For example:
|
|
|
Reference |
Agent in the software modelling sense. This is not a sales representative. |
|
|
Reference |
Legal agreement between a Communications Service Provider and an account. |
|
|
Aggregate |
An aggregated view for reporting and linking purposes that keeps track of current relationships between CUSTOMER, ACCOUNT, AGREEMENT and PRODUCT SUBSCRIPTION. |
|
|
Base |
Approval for the AGREEMENT from the operator's authorized employee, if the agreement requires higher level approval or review. |
|
|
Reference |
Defines relationship(s) between agreements. |
|
|
Base |
Agreement Approval Assignment is only to be used when the chain of approvals is not linear. In case of multiple parallel Authorization Requests for Approval, this entity shall be used. |
|
|
Lookup |
Lookup for reasons of why two agreements are related. For example: The reason for one agreement to be replaced by another:
The reason for one agreement to depend on another:
|
|
|
Lookup |
Lookup for types of assignment between two agreements. For example:
|
|
|
Lookup |
Lookup to classify the initiator of the agreement change. |
|
|
Lookup |
Reasons for a change in AGREEMENT. Typically, it could be CUSTOMER take-over, or simple information update (CUSTOMER or main product offering level) that triggers a change in agreement information or relationship. |
|
|
Lookup |
Lookup of all the type of agreement changes. For example:
|
|
|
Derived |
Derived information about customer's current or future agreement for analytical purposes. This entity captures only changed agreements, including REPLACE or TERMINATE. |
|
|
Reference |
The document(s) provided by the customer when a agreement was signed. For example:
|
|
|
Derived |
Derived information about customer's current or future agreement for analytical purposes. |
|
|
Reference |
Goal of any AGREEMENT (intent). It is defined once so that all similar agreements can refer to the same Statement of intent. |
|
|
Reference |
Detail items for the AGREEMENT. Each item may use a different PRODUCT SPECIFICATION. |
|
|
Reference |
This entity is superceded by AGREEMENT ITEM. It is deprecated and should only be used by legacy systems. |
|
|
Derived |
Summary of postpaid revenue per AGREEMENT for any given day. All fact fields are sum-able. It is an extension of the REVENUE DAY DRVD from a different point of view. |
|
|
Reference |
Association of SERVICE LEVEL AGREEMENT with the main AGREEMENT signed by customers. Normally, only customer specific SERVICE LEVEL AGREEMENT are mentioned, but one could generalize also to add a relationship for and agreement with "tacit" SERVICE LEVEL AGREEMENT. |
|
|
Base |
The status history of the AGREEMENT. |
|
|
Lookup |
Lookup for description of the agreement status change. For example:
|
|
|
Lookup |
Lookup for all possible types of AGREEMENT STATUS. For example:
|
|
|
Base |
The value of terms attached to the AGREEMENT. For example:
The value can vary at different time period of agreement. 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 agreement. |
|
|
Lookup |
Lookup for all possible terms which may be attached to a AGREEMENT. For example:
|
|
|
Lookup |
Lookup for agreement types. |
|
|
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 PRODUCT 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:
|
|
|
Lookup |
Average Revenue per Unit Band definitions. For example:
|
|
|
Aggregate |
The monthly summary of revenue values for ARPU calculation on CUSTOMER TYPE level. |
|
|
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. |
|
|
Lookup |
Method used to authorize a payment (PIN, Signature, TAN, TAN SMS, and so on) or an official document like an agreement (Certified Email or PDF, signature, and so on). |
|
|
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 RESOURCE, 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. |
|
|
|
Reference |
The BaseBand Unit (BBU) is part of 3G Node B base station system, which is in charge of base station control. |
|
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 UDR 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. |
|
|
Lookup |
The brands associated with hardware (usually this applies for handsets, but also for ITEM SPECIFICATIONs). |
|
|
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 |
Subtype of PRODUCT OFFERING PRICE applied to BROADBAND SERVICE. |
|
|
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. |
|
|
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: RESOURCE |
|
|
Reference |
Defines month-in-half in a business calendar. |
|
|
Reference |
Defines half year in a business calendar. |
|
|
Reference |
Describes an arrangement, agreement, communication, or joint activity between one or more PARTY ROLEs, RESOURCE 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, RESOURCE, 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 temporary status of an interaction, non current, if it was not COMPLETED when it was first loaded. |
|
|
Base |
The purpose for the Business Interaction expressed in terms of a Product Type, PRODUCT OFFERING, Service Type, or RESOURCE SPECIFICATION or may refer to a Product, Service, or RESOURCE. 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 product offering Price |
|
|
Reference |
Specification of how a given BUSINESS INTERACTION ITEM is supposed to be filled (data, information, and so on). Normally ignored because the content expected is obvious, this entity is present for completeness only. |
|
|
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 agreement or a customer order. |
|
|
Reference |
The roles which can be played by PARTY or other business interaction elements like Resource, and so on. |
|
|
Reference |
The invariant characteristics (attributes in the business view, and methods, constraints, relationships, and behavior in the system view) and behavior of a BUSINESS INTERACTION. This is done by optionally defining a set of BUSINESS INTERACTION SPECIFICATION items, each of which aggregates one or more other types of Specifications. This helps to ensure that different BUSINESS INTERACTION have the same basic characteristics and behavior by deriving them from the same BUSINESS INTERACTION SPECIFICATION. |
|
|
Lookup |
The reason to explain why a BUSINESS INTERACTION has had a change in status. |
|
|
Reference |
Represents the ability to distinguish between different instances of RESOURCE SPECIFICATIONs. It represents a particular form or variety of a RESOURCE SPECIFICATION that is different from others or from the original. The form represents differences in attributes, methods, relationships, or constraints that characterize this particular RESOURCE SPECIFICATION, but which are not enough to warrant creating a new RESOURCE SPECIFICATION. |
|
|
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. |
|
|
Aggregate |
Monthly summary of customer call statistics for the call center. |
|
|
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 SPECIFICATION, 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. |
|
|
Base |
||
|
Reference |
A number or text that can be assigned to a CAMPAIGN CHARACTERISTIC. |
|
|
Reference |
The customer documents provided during campaign activities. |
|
|
Derived |
Daily aggregate of campaign results by PROMOTION RESULT TYPE. |
|
|
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 |
Relationship between a CAMPAIGN and the MEDIA OBJECT chosen to run this campaign (Radio, TV, newspaper, posters, Internet Adds, and so on). |
|
|
Reference |
Item, resource, associated with the CAMPAIGN and the MEDIA OBJECT used. It could go from specific accessories that one could get with a specific promotion. |
|
|
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". |
|
|
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 Resources, such as Chips or Cards. |
|
|
Lookup |
Verification Method to check a Card Holder self (personal ID, Birthday, extra PIN...), typically for Credit Card but it could be generalized. |
|
|
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. |
|
|
Lookup |
Lookup for codes denoting which kind of card was accepted. For example:
|
|
|
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 run time statistics captured at the cell level. |
|
|
Aggregate |
The network parameters and run time 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:
|
|
|
Lookup |
Type of Certificate (Medical, Tax Authority, Government, and so on). |
|
|
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 |
Mining target entity to store churn factors retrieved from SVM mining model. |
|
|
Derived |
Mining target entity to store churn ROC details calculated using SVM mining model. |
|
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 |
Specifies the algorithm that schedules packets in queues and guarantees a certain transmission rate. If a queue is not in use, the bandwidth is made available to other queues. |
|
|
Reference |
Describes the internal component of the forwarding path, used to recognize and distinguish among different packet streams or flows. |
|
|
Reference |
Client (part of the software application). This is not the customer. |
|
|
Reference |
Host on which the CLIENT runs (from a software application perspective). It is a Resource identification expected. |
|
|
Reference |
Version of the CLIENT (part of a software application that the end-user is running). |
|
|
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:
|
|
|
Lookup |
Type of Statistic Collection (alerts, alarms, network KPIs, and so on). |
|
|
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 Products 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. |
|
|
Lookup |
Possible REASONs for being compensated (Standard Sales program, accelerator, or Hardware Defect, and so on). |
|
|
Reference |
A classification of a COMPETITOR, such as by size, product lines offered, and so on. |
|
|
Reference |
A PARTY that offers PRODUCT SPECIFICATION similar to the enterprise's PRODUCT SPECIFICATION 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 SPECIFICATION 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 |
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 |
Association of price component to Composite Product Offering. It allows building complex pricing. |
|
|
Reference |
Groups of PRODUCT SPECIFICATIONs bundled to serve as basis of a PRODUCT OFFERING. The composite product specification is not customer facing and a customer should subscribe to a composite product specification through the PRODUCT OFFERING. For example:
|
|
|
Reference |
Assigns PRODUCT SPECIFICATION(s) to a COMPOSITE PRODUCT SPECIFICATION. |
|
|
Lookup |
Lookup for type codes and descriptions for COMPOSITE PRODUCT SPECIFICATION charge on a PRODUCT SPECIFICATION. For example:
|
|
|
Lookup |
Type of COMPOSITE PRODUCT SPECIFICATION. It groups COMPOSITE PRODUCT SPECIFICATIONs that share common characteristics. |
|
|
Reference |
A PRODUCT PRICE COMPONENT (associated with PRODUCT SUBSCRIPTION) that is made up of parts. |
|
|
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 |
Abstract entity that defines "compound" traffic conditioning elements. |
|
|
Reference |
This is the abstract base entity for all composite entities that are inherently manageable and form a PRODUCT SPECIFICATION. The key difference between network element and COMPOUND RESOURCE is that network element describes either a Physical or a Logical entity. In contrast, COMPOUND RESOURCE describes managed entities that are collections of other managed entities. A key point is that each managed entity that is part of a COMPOUND RESOURCE can be individually managed as either a PHYSICAL RESOURCE or a LOGICAL RESOURCE. |
|
|
Reference |
An entity that is individually manageable. A Compound Element Collection is an aggregate entity consisting of RESOURCE and optionally Compound Element Collection entities. As such, a Compound Element Collection represents a set of PHYSICAL RESOURCEs and LOGICAL RESOURCEs 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 RESOURCE Collection. Each node in the network can be represented by a RESOURCE. |
|
|
Reference |
Defines the semantics of aggregating COMPOUND RESOURCEs using aggregation. It associates the various components. Also see the TMF SID and the DEN-ng system for more details. See also COMPOUND RESOURCE DETAIL. |
|
|
Reference |
Defines the semantics of the COMPOUND RESOURCE 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 RESOURCE, LOGICAL RESOURCE, and COMPOUND RESOURCE into this particular COMPOUND RESOURCE. |
|
|
Lookup |
The various types for a COMPOUND RESOURCE DETAIL. For example:
|
|
|
|
Reference |
This is a concrete entity that defines the semantics of aggregating PHYSICAL RESOURCE into a COMPOUND RESOURCE. |
|
Reference |
This entity is a role that is defined by the interaction between PHYSICAL RESOURCE ROLEs and LOGICAL RESOURCE ROLE. There must be at least one or more PHYSICAL RESOURCE ROLEs and one or more LOGICAL RESOURCE ROLE to form a Compound Element Role. However, neither a PHYSICAL RESOURCE ROLE nor a Logical Element Role has to belong to a Compound Resource Role. |
|
|
Reference |
Implements the relationship between COMPOUND RESOURCE and network element role. |
|
|
Reference |
Specification of COMPOUND RESOURCE ROLE: it details the common characteristics of a COMPOUND RESOURCE ROLE. |
|
|
Reference |
This is the abstract base entity that defines the invariant characteristics and behavior, attributes, methods, constraints, and relationships, of a COMPOUND RESOURCE. The key difference between a Compound Resource Spec and either a PHYSICAL RESOURCE SPECIFICATION and a LOGICAL RESOURCE SPECIFICATION is that a PHYSICAL RESOURCE SPECIFICATION and LOGICAL RESOURCE SPECIFICATION define templates for specifying the invariant characteristics and behavior of PHYSICAL RESOURCEs and LOGICAL RESOURCEs, respectively. In contrast, a Compound Resource Spec describes templates that contain at least one PHYSICAL RESOURCE SPECIFICATION and at least one LOGICAL RESOURCE SPECIFICATION. Optionally, one or more Compound Resource Specs may also be specified. Thus, a Compound Resource Spec is in effect a "shorthand notation" for specifying complementary PHYSICAL RESOURCE SPECIFICATIONs and LOGICAL RESOURCE SPECIFICATIONs. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building COMPOUND RESOURCE objects. The purpose of this entity is to track specifications of COMPOUND RESOURCEs separately from other types of Resource Specifications. This entity inherits the Modifies Resource Spec aggregation, and therefore can be used with the corresponding COMPOUND RESOURCE entity. The key difference between a COMPOUND RESOURCE SPEC and either a PHYSICAL RESOURCE SPECIFICATION and a Logical Resource Type is that a PHYSICAL RESOURCE SPECIFICATION and Logical Resource Type define templates for specifying the invariant characteristics and behavior of PHYSICAL RESOURCEs and LOGICAL RESOURCEs, respectively. In contrast, a COMPOUND RESOURCE SPEC describes templates that contain at least one PHYSICAL RESOURCE SPECIFICATION and at least one Logical Resource Type. Optionally, one or more COMPOUND RESOURCE SPECs may also be specified. The difference between a Compound Resource Spec Atomic entity and a COMPOUND RESOURCE SPEC COMPOSITE entity is that a Compound Resource Spec Atomic entity is designed to be a standalone entity. Note that it still aggregates at least one PHYSICAL RESOURCE SPECIFICATION and at least one Logical Resource Type; however, the result is that this Compound Resource Spec Atomic entity can be used by itself.) In contrast, a COMPOUND RESOURCE SPEC COMPOSITE entity is made up of one or more COMPOUND RESOURCE SPECs, one of which must be a Compound Resource Spec Atomic entity. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building composite COMPOUND RESOURCE objects. The purpose of this entity is to track specifications of COMPOUND RESOURCEs separately from other types of Resource Specifications. This entity inherits the modifies Resource Spec aggregation, and therefore can be used with the corresponding COMPOUND RESOURCE entity. The key difference between a COMPOUND RESOURCE SPEC and either a PHYSICAL RESOURCE SPECIFICATION and a Logical Resource Type is that a PHYSICAL RESOURCE SPECIFICATION and Logical Resource Type define templates for specifying the invariant characteristics and behavior of PHYSICAL RESOURCEs and LOGICAL RESOURCEs, respectively. In contrast, a COMPOUND RESOURCE SPEC describes templates that contain at least one PHYSICAL RESOURCE SPECIFICATION and at least one Logical Resource Type. Optionally, one or more COMPOUND RESOURCE SPECs may also be specified. The difference between a COMPOUND RESOURCE SPEC ATOMIC entity and a Compound Resource Spec Composite entity is that a COMPOUND RESOURCE SPEC COMPOSITE entity is designed to be a standalone entity. (Note that it still aggregates at least one PHYSICAL RESOURCE SPECIFICATION and at least one Logical Resource Type; however, the result is that this COMPOUND RESOURCE SPEC ATOMIC entity can be used by itself.) In contrast, a Compound Resource Spec Composite entity is made up of one or more COMPOUND RESOURCE SPECs, one of which must be a COMPOUND RESOURCE SPEC COMPOSITE entity. |
|
|
Reference |
Concrete entity that links TERMINATION POINT to COMPOUND RESOURCE. For example, it will describe characteristics and behavior of the TERMINATION POINTs that comprise this particular Resource Port in terms of dependencies and how a TERMINATION POINT interacts with other TERMINATION POINTs. |
|
|
Reference |
A Resource Unit is an entity that is individually manageable. The Compound Resource Unit is an aggregate entity consisting of both physical and logical aspects of a managed Resource. For example, a ROUTER is a Resource Unit. Different PHYSICAL RESOURCE 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 RESOURCE 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 aggregates all PHYSICAL RESOURCE and LOGICAL RESOURCE objects, enabling a high-level view of the physical and logical aspects of the Resource to be provided. |
|
|
Reference |
Assigns one or more CONFIGURABLE PRODUCT SPECIFICATION CHARACTERISTICs to a PRODUCT SPECIFICATION. Multiple products may have the same CONFIGURABLE PRODUCT SPECIFICATION CHARACTERISTICs. |
|
|
Reference |
Available features that may be associated with one or more PRODUCT SPECIFICATIONs. For example, for a handset there are features such as:
|
|
|
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. |
|
|
Derived |
Specifies customer contact statistics. The customer contacts are analyzed. |
|
|
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 |
Medium used to get into Contact with customer or third party in a business interaction. Typically phone, letter, fax, visit, or chat. |
|
|
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 OFFERING PRICE. |
|
|
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 |
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. |
|
|
Derived |
Statistics of all expenses by each business unit inside the carrier. It can be used for auditing and budgeting. |
|
|
Base |
The budget of each COST CENTER at a specific financial period. |
|
|
Aggregate |
Summary at month level of COST associated with COST CENTER and ORGANIZATION BUSINESS UNITs. |
|
|
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). |
|
|
Derived |
Critical Aggregation Summary at day level of various measures (counts) at customer, account, agreement, Main Product Subscription, and Product Subscription level as a function of Customer Type, County, Organization Business Unit, Product Offer level and Product Specification Level (full Hierarchies). It collects summable measures (like number of new customers, new subscriptions, churners, and so on) over the day as well as non-summable measures, like number of active accounts (end of day), suspended subscriptions, and so on. The measures are supposed to be all at the end of the day considered. |
|
|
Aggregate |
Similar to COUNT DAY DRVD but at month level. The measures are supposed to be all at the end of the month considered (or the last past full day of data available of the current month). |
|
|
Lookup |
Specifies the barcode on a store or manufacturer coupon. The coupon scan code comprises two parts:
|
|
|
Lookup |
Lookup for type of coupon used. |
|
|
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 SPECIFICATION or SERVICE. |
|
|
Reference |
List of credit categories available that may be assigned to customers. For example:
|
|
|
Reference |
Provides reference financial rating scores for each customers to the service provider. This information is also called the "Credit Rating Agency". |
|
|
Reference |
Indicates the identifier of the threshold that caused the alarm. It has to be in relation with a RESOURCE ALARM. |
|
|
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 |
Custom Queueing enables the designer to specify a particular number of bytes, packets, or flows to forward from a specific Queue each time the Queue is serviced. |
|
|
Reference |
Information pertaining to customers. |
|
|
Reference |
Account associated to a CUSTOMER from a pure Retail shop perspective. It has otherwise the same behavior as ACCOUNT, but is specific to the retail view, to allow the possibility for the same customer to have two accounts: one for Retail, one for standard Telecommunications Provider (Billing and CRM) just in case they are separate and might not be easily conciliable upfront. |
|
|
Aggregate |
Monthly summary of newly acquired customers by PRODUCT SPECIFICATION. |
|
|
Reference |
Address associated with a customer as given to the Retail Unit in contact with customer. |
|
|
Reference |
Associates a CUSTOMER with a CUSTOMER GROUP. |
|
|
Aggregate |
Summary of churners per month by reason. |
|
|
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 |
Identifies the cluster that the CUSTOMER falls into, based on buying behavior. |
|
|
Lookup |
Define types of CUSTOMER CLUSTER. |
|
|
|
Data Mining |
Specifies storing concatenated customer comments in last 1 year, customer comments' score, and so on. |
|
Reference |
The Customer Communities identified by mining algorithm. |
|
|
Base |
Subtype of COST which applies to a customer. For example, the cost of a gift that is sent to a customer. |
|
|
Derived |
Statistics of various costs incurred to the customer. This information is important from the analysis point of view. For example, subscriber acquisition cost, subscriber retention cost, and so on. |
|
|
Aggregate |
Statistics of various costs incurred to the customer. These details are important for analysis such as:
|
|
|
Aggregate |
Summary of customer in debt per month (status at the end of the month or latest past full day of the current month). |
|
|
|
Reference |
Mining target entity to store Decision Tree mining model details. |
|
Derived |
The D.N.A of the customer at month level collects any information available about the customer (socio-demographic data, products, purchase, payment and recharge behavior, call behavior, interactions with call center and support, issues, complains, and so on, for mining purposes. |
|
|
Reference |
Various types of customer proof documents provided for a CUSTOMER ORDER, AGREEMENT, 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 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. |
|
|
Reference |
Specifies the invariant characteristics and behavior of a particular CUSTOMER FACING SERVICE as seen by the CUSTOMER. |
|
|
Reference |
This entity defines CUSTOMER FACING SERVICE SPECIFICATIONs that do not have any subordinate CUSTOMER FACING SERVICE SPECIFICATIONs. In other words, a Customer Facing Service Spec Atomic is a standalone CUSTOMER FACING SERVICE SPECIFICATION, and does not require any supporting CUSTOMER FACING SERVICE SPECIFICATIONs 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. |
|
|
Reference |
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 SPECIFICATION. In this case, a Customer Facing Service Spec Composite will aggregate all of the individual CUSTOMER FACING SERVICE SPECIFICATIONs 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 SPECIFICATION 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 SPECIFICATION. |
|
|
Base |
On site installation for the customer with particular equipment instance. |
|
|
Base |
Details regarding customer service. |
|
|
Aggregate |
This entity gives order measures (number of orders and total order amount) in same quarters of consecutive years. For example:
Provides information on order measures varying year over year. |
|
|
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 |
The list of criteria used to group the CUSTOMERs under a specific CUSTOMER GROUP. |
|
|
Reference |
Subtype of CUSTOMER (and PARTY), which contains details of individuals as opposed to organizations. |
|
|
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. |
|
|
Derived |
Daily summary of CUSTOMER ORDERs and their status (end of the corresponding day). |
|
|
Reference |
The document provided while submitted CUSTOMER ORDER. |
|
|
Base |
Details regarding items in the CUSTOMER ORDER. |
|
|
Derived |
Summary of the details of CUSTOMER ORDER LINE ITEM status, per day. It allows identifying typical or recurrent issues in specific order types on specific items. |
|
|
Base |
Current state of an order line item. |
|
|
Aggregate |
Summarizes orders placed by customers at month level of aggregation. Using this entity, order measures (number of orders and total order amount) across order status, order type, product, product type dimensions can be computed |
|
|
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). |
|
|
|
Derived |
Mining target entity to store prediction results of target promotion mining model. |
|
Reference |
Merchandise preferences of a Key Customer, for classes of items or other general categories. |
|
|
Reference |
Association between CUSTOMERs. Information regarding the CUSTOMER or PROSPECT that is restricted to comply with privacy and other laws. This table is encrypted. For example: associating the Husband-Wife relationship. |
|
|
Lookup |
Lookup for types of relationships that may exist between CUSTOMERs. For example:
|
|
|
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:
|
|
|
Derived |
Recency, Frequency, Monetary, and Profitability Value Score of a CUSTOMER, by ORGANIZATION BUSINESS UNIT. |
|
|
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 |
Specifies details for storing each customer segment derived from segmentation mining model. |
|
Reference |
The segmentation model used to profile the customers. For example:
|
|
|
|
Derived |
Specifies predefined dictionary to manually score customers' comments. |
|
Reference |
Assigns SIC/NASIC code to customers. |
|
|
Derived |
SKU ITEM purchases and returns by CUSTOMER for an ORGANIZATION BUSINESS UNIT. |
|
|
Reference |
Initial source or contact with customer. For example:
|
|
|
Lookup |
List of the possible REASONs for setting a customer in a given status. |
|
|
Lookup |
Lookup for type of customer. For example: Individual or Corporate. |
Table 2-39 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 |
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:
|
|
|
Reference |
Provide weighted fair distribution of bandwidth for multiple Queues that contain variable-length packets. |
|
|
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 RESOURCEs 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. |
|
|
Reference |
Semantics that define how traffic is forwarded based on the value of the DSCP (DiffServ Code Point) of a packet. |
|
|
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. |
|
|
Base |
Line Item associated with discounts in a retail transaction. |
|
|
Reference |
A discount, a reduction of price, for a PRODUCT SUBSCRIPTION. |
|
|
Lookup |
Denotes what disposition a returned item was in. For example:
|
|
|
Lookup |
Distance ranges to characterize UDR 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 |
Domain from a web portal point of view. |
|
|
Lookup |
Type of DOMAIN (web related). |
|
|
Reference |
Specifies the dropper service. Droppers are distinguished by the algorithm that they use to drop traffic. |
|
|
Reference |
The xDSL modem to implement Broadband on copper wire (router). The DSLAM (Digital Subscriber Line Access Multiplexer) aggregates multiple xDSL users into the core IP network. |
|
|
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 |
Specifies the policy to forward network traffic by adding specific semantics that characterize the operation of the Expedited Forwarding (EF) Service (RFC3246 and RFC3247). |
|
|
Reference |
List of email addresses as a generalization of ADDRESS LOCATION. Typically used for Retail shops. |
|
|
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:
|
|
|
Lookup |
Channel through which a customer gets enrolled into a LOYALTY PROGRAM. |
|
|
Lookup |
Type of ENROLL CHANNEL. |
|
|
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. |
|
|
Lookup |
Lookup for method used of entering transaction data. For example:
|
|
|
Lookup |
Defines the temperature, relative humidity, lighting, and other physical or climatic environmental requirements for storing and displaying the item. |
|
|
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 SPECIFICATION. |
|
|
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:
|
|
|
Lookup |
Lookup for type of specific equipment instance status type. For example:
|
|
|
Reference |
Sub-type of AGREEMENT in which customer leases some equipment. Those equipment that still belong to the service provider. When the AGREEMENT terminates, the device should be returned to service provider. |
|
|
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. |
|
|
|
Reference |
Lists of the various Ethernet Device Interfaces. |
|
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 |
Events related to agreement creation, cancellation, churn, or change, usually triggered after a business interaction. |
|
|
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 |
Subtype of "Non UDR 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 |
Events associated with an offer or COMPOSITE PRODUCT SPECIFICATION. Subtype of EVENT. |
|
|
Base |
Subtype of COST, which is specifically related to a given EVENT. This cost is usually for a non-UDR 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 |
Specifies the EMPLOYEE activities (sales, installation, and so on). Subtype of 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:
|
|
|
Reference |
Assigns an address location to the EVENT. |
|
|
Base |
Events associated with each event or transaction on a customer loyalty program. For example:
|
|
|
Base |
Many to many relationship assigning a party or multiple parties to event(s). |
|
|
Base |
Interactions or communications with the customer. For example:
|
|
|
Reference |
A value of a given Party Interaction Characteristic, associated with a full thread of interaction. The first interaction of the thread is the so-called "party interaction code". |
|
|
Base |
Subtype of EVENT PARTY INTERACTION which represents the chat history details between the service representative and the CUSTOMER. Each chat message is saved as one record. |
|
|
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. |
|
|
Base |
Tracks multiple employees who participate in a same interaction with a customer |
|
|
Base |
Event in which party profile information was modified or updated. |
|
|
Lookup |
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 a subscription. Subtype of EVENT. For example:
|
|
|
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 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:
|
|
|
Reference |
Specifies service area served by the central office. |
|
|
Reference |
The attribute exclusionFunction is designed to be populated from an external management system, and represents the criteria for excluding one or more Ports. A predefined exclusion function is to limit the role that a Port plays to an edge role. However, this class enables additional functions to be used to exclude 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:
|
|
|
Lookup |
Type of Basis or REASON for Expiry. It could be time-based (x months, or so) after first activation or after first or last call, or event based (something happened or a specific date like New Year passed so it expires). |
|
|
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. |
|
|
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. |
|
|
Reference |
Ensure that each Queue receives a fair share of the set of applicable metrics, for example bandwidth, that are divided among the different Queue instances. |
|
|
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 |
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 |
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. |
|
|
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 OFFERING PRICE 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. |
|
|
Lookup |
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. |
|
|
Lookup |
Lookup for status codes that may be applied to a fuel sale. |
Table 2-40 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 HIERARCHY. |
|
|
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 HIERARCHY. |
|
|
Reference |
Counties defined in a GEOGRAPHY HIERARCHY. |
|
|
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 region in a GEOGRAPHY HIERARCHY. |
|
|
Reference |
Defines a state in a GEOGRAPHY HIERARCHY. |
|
|
Reference |
Defines a city in GEOGRAPHY HIERARCHY. |
|
|
Reference |
Defines a subregion in a GEOGRAPHY HIERARCHY. |
|
|
Reference |
Top level of GEOGRAPHY HIERARCHY. |
|
|
Reference |
GGSN (Gateway GPRS Support Node) is the key component in GPRS and 3G system, which links the access network data into the IP-Network. |
|
|
Derived |
Statistics of all give away items to the customer 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 SPECIFICATION. |
|
|
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. |
|
|
Reference |
Subtype of PRODUCT SPECIFICATION, 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. |
|
|
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. |
|
|
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 |
Specifies the behavior of either a head dropper or tail dropper (for example, a dropper which drops from the head or tail of its queue, respectively). Subtype of DROPPER SERVICE. |
|
|
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 SPECIFICATION that provides information about IDD service. |
|
|
Base |
Event involving an International Direct Dial (IDD) call. |
|
|
Base |
Details collected when a user accesses a web page. |
|
|
Lookup |
Lookup for types of details collected when a user accesses a web page. |
|
|
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. |
|
|
Reference |
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 OFFERING 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:
|
|
|
Lookup |
Classification of Interaction Status for reporting purpose. Currently used similarly to INTERACTION STATUS. |
|
|
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:
|
|
|
Base |
Subtype of UDR EVENT, which captures customer internet surfing history with detailed URL and time information. |
|
|
Base |
The detail line item which applies an increment or decrement to the item's unit on hand and or the financial valuation. |
|
|
Derived |
Inventory adjustment information at the item, ORGANIZATION BUSINESS UNIT, day-reason level. |
|
|
Base |
A written or printed paper, or digital equivalent, that evidences the movement of merchandise or supply SKU ITEMs. |
|
|
Base |
Detail line on an INVENTORY CONTROL DOCUMENT that identifies the SKU ITEM, and unit of measure exchanged, or the freight, charges, taxes, and allowances applicable to a particular inventory control event and action. |
|
|
Base |
Specifies a unit record of a particular stock ITEM SPECIFICATION, held in a particular Inventory Location, in a particular Inventory State and controlled or managed by a particular Revenue Center. |
|
|
Reference |
Physical location where the retailer stores merchandise. The inventory location may be colocated at a SITE and does not include containers, ships, and trucks that are in transit. |
|
|
Aggregate |
Daily status and value of inventory. For example:
|
|
|
Derived |
Status and value of inventory. For example:
|
|
|
Aggregate |
Daily status and value of inventory. For example:
|
|
|
Derived |
Daily record of inventory receipts by item and ORGANIZATION BUSINESS UNIT. |
|
|
Derived |
Daily summary of transfer in and transfer out document statistics. Provides a daily summary of inventory transfers at the item, to ORGANIZATION BUSINESS UNIT, from ORGANIZATION BUSINESS UNIT, and transfer type. Daily summary of transfer in and transfer out document statistics summary of transfer in and transfer out document statistics. |
|
|
Derived |
Weekly record of inventory receipts by subclass and ORGANIZATION BUSINESS UNIT. |
|
|
Derived |
Daily summary of Vendors' Inventory Compliance. |
|
|
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. |
|
|
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:
|
|
|
Derived |
Daily Summary of aging of invoices (from the time they are open until they closed) for reporting purposes. |
|
|
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 |
Process specific for the generation of the Invoices (Billing process) as a subtype of PROCESS EVENT. |
|
|
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:
|
|
|
Aggregate |
Monthly aggregation of all invoices to postpaid customers at customer type level. |
|
|
Base |
Matches the payment to an INVOICE. |
|
|
Base |
Payment terms of each INVOICE. For example:
|
|
|
Lookup |
Lookup for available types of payment terms. |
|
|
Reference |
Describes the successful processes related to invoice generation, issuing and dispatching. |
|
|
Lookup |
Lookup for possible status of the invoices. |
|
|
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:
|
|
|
Lookup |
Information about the role in which a resource, a service, or a product is involved. |
|
|
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 |
Classification of Items (as resource). |
|
|
Reference |
Grouping of items based on common characteristics. |
|
|
Reference |
Top level of the item merchandise hierarchy. |
|
|
Reference |
Fourth level in item hierarchy below ITEM GROUP. Item department consists of one or more item classes. |
|
|
Reference |
Second level in item hierarchy below ITEM COMPANY. Item Division consists of one or more ITEM GROUPs. |
|
|
Reference |
Third level in item hierarchy, below ITEM DIVISION. Item Group consists of one or more ITEM DEPARTMENTs |
|
|
Lookup |
Method by which the SKU ITEM selling price was retrieved and entered into the Point of Sale system during a RETAIL SALES RETURN LINE ITEM transaction. |
|
|
Reference |
The sixth level in item hierarchy, below ITEM CLASS. Item Subclass consists of one or more items. |
|
|
Lookup |
Type of Item. It is available for Retail type of grouping (such as Hardware, Accessories, and so on) or any other grouping the Communications Provider prefers. |
|
|
Reference |
Details describing the item or PRODUCT SPECIFICATION. |
|
|
Base |
Specifies the IVR interaction navigation history. |
|
|
Reference |
Detailed Content description of the IVR Menu with the different choices, and paths (scripts) available. It should be use as part of a complete IVR navigation description. |
|
|
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. |
|
|
Reference |
List of areas over which authority extends in relationship with the SKU ITEM Service Provider in a way or another. |
Table 2-41 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. |
|
|
Reference |
Subtype of ADDRESS LOCATION. |
|
|
Lookup |
List of possible operations on land, carried out by humans, with the intention to obtain products and benefits through using land resources. |
|
|
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:
|
|
|
Lookup |
Type of Lifecycle, following the general marketing product lifecycle categorization. It can also be used as a further category to flag the market lifecycle period in which a specific product belong finds itself on the market. |
|
|
Reference |
The local place within a given geographical address location to locate a specific object, such as a RESOURCE. |
|
|
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 SPECIFICATION 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 |
Grouping of Common and invariant characteristics and behavior associated with a type of LOGICAL DEVICE. |
|
|
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. |
|
|
Reference |
This entity describes different logical aspects of devices (For example, DEVICE INTERFACEs) that constitute a PRODUCT SPECIFICATION. The Logical Resource has two main purposes.
|
|
|
Reference |
Defines how the LOGICAL RESOURCE supports certain PHYSICAL RESOURCEs. |
|
|
Reference |
This entity defines the concept of various types of roles that can be associated with LOGICAL RESOURCEs. |
|
|
Reference |
Implements the semantics of the Roles Describe Logical Resource aggregation. |
|
|
Reference |
Entity for all LOGICAL RESOURCE ROLE specification subclasses. The Logical Resource Role Spec enables relationships to be defined between it and other classes. This helps prevent relationship explosion. The Logical Resource Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with LOGICAL RESOURCEs. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building LOGICAL RESOURCE objects. The purpose of this entity is to track specifications of LOGICAL RESOURCEs separately from other types of Resource Specifications. This entity inherits the Modifies Resource Spec aggregation, and therefore can be used with the corresponding LOGICAL RESOURCE entity. The difference between this entity and the Logical Resource Type Composite entity is that this entity represents standalone specifications of LOGICAL RESOURCE objects. The Logical Resource Type Composite entity represents a hierarchy of specifications of LOGICAL RESOURCE objects. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building LOGICAL RESOURCE objects. The purpose of this entity is to track specifications of LOGICAL RESOURCE separately from other types of Resource Specifications. This entity inherits the Modifies Resource Spec aggregation, and therefore can be used with the corresponding LOGICAL RESOURCE entity. The difference between this entity and the Logical Resource Type Atomic entity is that this entity represents a hierarchy of specifications for LOGICAL RESOURCEs. The Logical Resource Type Atomic entity represents a single standalone specification of a LOGICAL RESOURCE. |
|
|
Reference |
Defines how the LOGICAL RESOURCE support certain PHYSICAL RESOURCEs. |
|
|
Reference |
Tracks changes in individual RESOURCE SPECIFICATION as it evolves with time. |
|
|
Reference |
This entity defines the invariant characteristics and behavior (attributes, methods, constraints, and relationships) of a LOGICAL RESOURCE. |
|
|
|
Reference |
The purpose of this entity is to track Logical Resource Type specifications separately from other types of Resource Specifications. This entity inherits the modifiesResourceSpec aggregation, and therefore can be used with the corresponding Logical Resource Type specification entity. |
|
Lookup |
Abstract ENTITY for all lookup entities. |
|
|
|
Reference |
A Loopback Interface is a virtual interface. Traffic sent to the Loopback Interface is forwarded to the Device itself for further processing. Subtype of DEVICE INTERFACE. |
|
Derived |
Similar to ACCOUNT BALANCE for Loyalty Points, on a daily basis. |
|
|
Base |
Describes the Loyalty membership enrollment event. |
|
|
Reference |
Loyalty programs available to which customers may be members of. |
|
|
Aggregate |
Monthly summary of LOYALTY PROGRAM statistics by PRODUCT SPECIFICATION and SALES CHANNEL. |
|
|
Reference |
Describes the LOYALTY PROGRAM level of membership or tier (typically bronze, silver, gold, platinum) associated with a given loyalty program. |
|
|
Base |
Tracks all migration from one loyalty tier to the other of Membership Accounts with the reason. |
|
|
Reference |
Grouping of LOYALTY TIER into "class", as required by the marketing needs. |
|
|
Lookup |
Logical Resource Status as defined by TMF SID. The default values are:
|
|
|
Reference |
Mailbox allocated to a CUSTOMER. |
|
|
Lookup |
Lookup for type of management action that can be performed on a PRODUCT OFFERING. 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 |
Abstract entity represents entities that represent management information obtained in a managed environment. Specifically, in the process of managing an entity, information of various forms are created. |
|
|
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 |
Represents a set of markings that can be used by one or more MARKER SERVICEs. For example, different marker pools could be defined for different CUSTOMERs as well as for different technologies. |
|
|
Reference |
Describes the Marker Service used to mark packets in a flow so that different devices in the network know how to treat the traffic that these packets belong to. |
|
|
Reference |
Association of a MARKER POOL to a MARKER SERVICE. |
|
|
Lookup |
List of the most common types of MARKER SERVICE, which sets existing bits in specific fields of a packet or frame:0: ToS1: DSCP2: 802-priority field3: 802-vlan id4: ISL class of service field (3 bits)5: Class of Service (other field)6: MPLS Label7: VC ID8: VC Bundle (set of VC IDs) |
|
|
Reference |
A geographic area or region or other connotation for which demographic data are available. |
|
|
Reference |
Hierarchical levels of market area. |
|
|
Reference |
A grouping of Parties, Geographic Areas, Sales Channels, and so forth. MARKET SEGMENTs are the target of Marketing Campaigns, PRODUCT OFFERING, 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 market information (in particular of competitors), including Sales Revenue by Month, Address, and Business Unit. |
|
|
Derived |
Defines the market information, including Sales Revenue by Month, Address, and Business Unit. |
|
|
Reference |
A categorization of performance measures by MARKET SEGMENT. |
|
|
|
Reference |
Relationship between two market statistics. |
|
Reference |
Contains the descriptions of the job for scheduling PM related activities: the collection of performance indicators or the production of performance indicators. |
|
|
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 |
Association of a logical interface with a media interface (USB, DVD Player...). |
|
|
Lookup |
Type of media interface available (USB, SD Card Reader, DVD Player,...). |
|
|
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 UDR event is at certain mediation status. For example:
|
|
|
Lookup |
Lookup of the mediation status of a given raw UDR event. For example:
|
|
|
Reference |
Loyalty Account or ACCOUNT specifically defined for and associated to LOYALTY PROGRAMs. The same customer may have multiple membership accounts. |
|
|
Base |
Stores the account balance history for MEMBERSHIP ACCOUNT (Loyalty) as counterpart of ACCOUNT BALANCE. |
|
|
Reference |
Traffic profile that the METER SERVICE can use to compare traffic against. The Meter Profile defines what levels of traffic pass through the METER SERVICE: Levels that are unaltered Levels that get delayed Levels that get dropped Levels that get further analyzed |
|
|
Reference |
A meter is a basic traffic conditioning building block. A meter determines the level of conformance of each packet or flow with respect to a pre-established traffic profile by monitoring a metric of a packet or flow (for example its arrival time). Subtype of TRAFFIC CONDITIONING SERVICE. |
|
|
Reference |
Association of a METER SERVICE with a specific Meter or traffic Profile against which the measures (of the packet) are done. |
|
|
|
Lookup |
Specifies mining churn types. |
|
|
Lookup |
Specifies customer life time survival value band details. |
|
|
Lookup |
Specifies customer life time value band details; 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. |
|
|
Lookup |
Specifies details of mining sentiment category. |
|
Reference |
Defines minutes as part of time. |
|
|
|
Reference |
The MOBILITY MANAGEMENT ENTITY (MME) is a key component in LTE network, which authenticates users, and so on. Subtype of PHYSICAL DEVICE. |
|
Base |
Subtype of UDR EVENT, which collects all information of calls of type Multimedia Messaging Service (MMS). |
|
|
Base |
Specifies the information relative to all the MMS services that customer is using. Subtype of CUSTOMER FACING SERVICE. |
|
|
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 |
This entity collects criteria for specifying what monitored objects are referenced by a query, specifying a monitored object class in conjunction with a filter. |
|
|
Reference |
This entity collects criteria for specifying what monitored objects are referenced by a query, specifying a list of monitored object instances. |
|
|
Reference |
The entity collects the criteria for specifying what monitored objects are referenced by a query, both scheduled or ad-hoc. |
|
|
Reference |
Defines related calendar elements for performing to-date time transformations. |
|
|
Reference |
Transformations with respect to a month. For example:
|
|
|
|
Reference |
Subtype of PHYSICAL DEVICE. |
|
Derived |
Parameters, configurations, and run time statistics related to the MSC (Mobile Switch Center) functioning and performance. |
|
|
Aggregate |
Monthly aggregation of parameters, configurations, and run time statistics related to the MSC (Mobile Switch Center) functioning and performance. |
|
|
Reference |
Subtype of VALUE ADDED SERVICE and PRODUCT SPECIFICATION, 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 Resource 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. 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 RESOURCE into NETWORK DOMAIN. |
|
|
Reference |
Subtype of RESOURCE FACING SERVICE |
|
|
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 |
Continuous Section of NETWORK ROUTE,that can be easily and unambiguously defined (for example a linear section from a repeater to the next). |
|
|
Reference |
Defines the relationship between NETWORK TOUCHPOINT and SERVICE COVERAGE AREA. |
|
|
Reference |
Specifies a place where RESOURCEs 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 |
Lists the possible reasons why a Number Portability Request is in a specific state. Such as 'Fraud','Lack of Document'. |
|
|
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-42 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 RESOURCE. This entity implements and manages the Resources, tasks, file systems, security, and data available on the LOGICAL RESOURCE. An Operating System is distinct from software applications that are run on the Resource. 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 status that a given order line item can be at. For example:“Pending” “Waiting for Customer feedback” “Closed” “Started” “Error” |
|
|
Lookup |
Lookup for the type of Order State. For example:
|
|
|
Lookup |
Type of ORDER STATE, used for grouping or summary purpose. |
|
|
Lookup |
Lookup for type of CUSTOMER ORDER. For example:
|
|
|
Reference |
A sub-type of PARTY that is related to the Communications Service Provider, usually from a Retail perspective. It is not part of the Communications Service Provider. It could have a role as customer upon which it the information should be repeated in CUSTOMER ORGANIZATION. |
|
|
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). |
|
|
Derived |
Simple daily summary at ORGANIZATION BUSINESS UNIT level of working, Opening and closing times. It should be limited to any units that may receive public (Retail Shops). |
|
|
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 websites managed by the operator. This normally includes only public information. |
|
|
Lookup |
Type of ORGANIZATION. The category is similar to ORGANIZATION BUSINESS UNIT TYPE but they can be different. |
|
|
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 SPECIFICATION or SERVICE. |
|
|
Lookup |
Lookup for reasons for a Packet Control Unit (PCU) outage in GPRS technology. For example:
|
|
|
Reference |
Web Page Description as part of a complete website navigation build-up and tracking. |
|
|
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 ADDRESS LOCATIONs with a PARTY. |
|
|
Reference |
Assignment of a PARTY to an AGREEMENT, in general, or a contract. |
|
|
Lookup |
Lookup for valid Roles that Parties may be assigned in PARTY AGREEMENT ASSIGNMENT. |
|
|
Lookup |
Lookup for type of the PARTY AGREEMENT ASSIGNMENTs. For example:
|
|
|
Base |
The status history of assignment among PARTY, ACCESS METHOD, and PRODUCT OFFERING. The assignment history among ACCESS METHOD, PRODUCT OFFERING, and PARTY. |
|
|
Base |
The current status and relationship between ACCESS METHOD, PRODUCT OFFERING and PARTY, before being moved to PARTY AM PRODUCT OFFERING ASSIGNMENT HISTORY once changed. |
|
|
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. |
|
|
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:
|
|
|
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:
|
|
|
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 |
Defines a PARTY's relationship to a PRODUCT SUBSCRIPTION. For example: a customer owns a subscription. |
|
|
Lookup |
Lookup for valid Roles that may be assigned to PARTY in regards to the PRODUCT SUBSCRIPTION. |
|
|
Reference |
A match between a PARTY and a PARTY PROFILE TYPE. It is based on matching PARTY characteristics, such as use of a product, with the characteristics of a PARTY PROFILE TYPE. |
|
|
Reference |
Association of (Profile specific) Characteristics to a given PARTY PROFILE. |
|
|
Lookup |
List of possible types of PARTY PROFILE. 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 TYPE CHARACTERISTIC on the party profile. |
|
|
Reference |
Describe the roles of each party in the project. |
|
|
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 agreement change, or for other reasons. |
|
|
Reference |
Specifies a simple grouping or categorization of PARTY ROLEs. |
|
|
Reference |
Shows the association between PARTY ROLE and various PARTY ROLE CATEGORYs |
|
|
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 |
Association of a given party ROLE (Customer, Provider, and so on) to a profile. Some profiles are only to be defined for specific roles while others can be defined for any. |
|
|
Lookup |
Status history of each role that a PARTY has taken. |
|
|
Lookup |
Type of PARTY ROLE, a general grouping for reporting purpose. |
|
|
Lookup |
Method used to create the segment, such as K-means clustering in Data Mining. |
|
|
Reference |
||
|
Lookup |
Lookup for available reasons for a PARTY and SERVICE relationship. |
|
|
Lookup |
Lookup for valid roles and descriptions a PARTY may be assigned for a SERVICE. For example:
|
|
|
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. |
|
|
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 SPECIFICATION. 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:
|
|
|
Reference |
Channel by which customer may pay for service. For example:
|
|
|
Lookup |
Lookup for valid methods of payment. For example:
|
|
|
Reference |
List of plans for payment (typically for Credit purpose but not only). |
|
|
Lookup |
Lookup for type codes and descriptions for transaction types associated with the ACCOUNT PAYMENT. The payment may be, for example:
|
|
|
Reference |
Defines required logical features to implement the specific role of a PE (Provider Edge) device, as used in a PRODUCT SPECIFICATION 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. |
|
|
Base |
A measure of the manner in which a SERVICE or RESOURCE 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. |
|
|
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. |
|
|
Reference |
A value of a characteristic 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. |
|
|
Lookup |
Defines a grouping of PERFORMANCE INDICATORs coming together (normally as a group of performance measurements). |
|
|
Lookup |
A group of indicators, usually reported in the same message by the equipment. |
|
|
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. |
|
|
Reference |
A network address that identifies mobile Resource Resources, 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 Resource is, such as an IP ADDRESS, or an IPXAddress, or a Point Code. |
|
|
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 Resource is functioning. |
|
|
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. |
|
|
Lookup |
Possible Types of Identification (document) required for a person (Driving license, Personal ID, passport). |
|
|
Reference |
Not used. |
|
|
Reference |
The phone number as a subtype of access method. |
|
|
Reference |
The telephone number pool allocated to the TELCO operator. |
|
|
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. |
|
|
Base |
Document associated with the manual Inventory (typically done once a year) in retail shops. |
|
|
Base |
Describes the line items in the documents associated with a manual Inventory in retail shops. |
|
|
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 |
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 Resource Port aggregation. For example, it will describe characteristics and behavior of the PHYSICAL PORTs that comprise this particular Resource Port in terms of dependencies and how a PHYSICAL PORT interacts with other PHYSICAL PORTs. |
|
|
Reference |
This entity describes different types of hardware that constitute a PRODUCT SPECIFICATION. The Physical Resource has two main purposes:
|
|
|
Reference |
Not used. |
|
|
Reference |
This is a concrete base class for defining the characteristic features and behavior of a Physical Element Specification. Every Physical Element Specification has a variety of important attributes, methods, constraints, and relationships which distinguish that Physical Element Specification from other Physical Element Specifications. We call these Physical Element SpecCharacteristics. Each of these characteristics is used at the business level to characterize a Physical Element Specification. |
|
|
Reference |
A subtype of PRODUCT SUBSCRIPTION to track tangible device usage by the customer. |
|
|
Reference |
This is a physical role that a device has. The Physical Resource Role enables the correlation of physical components that route traffic with the logical capability of routing traffic. |
|
|
Reference |
This class implements the semantics of the RolesDescribePhysical Element aggregation. |
|
|
Reference |
Entity for all Physical Resource Role Specification subclasses. The Physical Resource Role Spec enables relationships to be defined between it and other classes in the model. This helps prevent relationship explosion. The Physical Resource Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with Physical Resources, whether they are subclasses of PHYSICAL DEVICE or Hardware, in the model. Specifies relationships to be defined between it and other classes in the model. This helps prevent relationship explosion. |
|
|
Reference |
Captures the semantics of the PHYSICAL RESOURCE ROLEs aggregation. |
|
|
Reference |
This entity defines the invariant characteristics and behavior, attributes, methods, constraints, and relationships, of a PHYSICAL RESOURCE. |
|
|
Reference |
Describes specific attributes, behavior, relationships, constraints, and semantics for building PHYSICAL RESOURCE objects. The purpose of this entity is to track Physical Resource Specifications separately from other types of Resource Specifications. This entity inherits the Specifies Resource aggregation, and therefore can be used with the corresponding PHYSICAL RESOURCE entity. The difference between this entity and the PHYSICAL RESOURCE SPECIFICATION COMPOSITE entity is that this entity represents standalone Physical Resource Specifications. The PHYSICAL RESOURCE SPECIFICATION COMPOSITE entity represents a specification that is in reality made up of a set (usually a hierarchy) of Physical Resource Specifications. |
|
|
Reference |
This entity describes specific attributes, behavior, relationships, constraints, and semantics for building Physical Resource objects. The purpose of this entity is to track Physical Resource Specifications separately from other types of Resource Specifications. This entity inherits the modifiesResourceSpec aggregation, and therefore can be used with the corresponding PHYSICAL RESOURCE SPECIFICATION entity. The difference between this entity and the PHYSICAL RESOURCE SPECIFICATION ATOMIC entity is that this entity represents a hierarchy of Physical Resource Specifications. The PHYSICAL RESOURCE SPECIFICATION ATOMIC entity represents a single standalone Physical Resource Specification. |
|
|
Reference |
Pipe is an abstracted Link between two network resources (which are also abstracted as TERMINATION POINTs). |
|
|
Reference |
Not used. |
|
|
Lookup |
Not used. |
|
|
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 |
Platform (from a Software or Applications perspective) on which an application or a software runs. |
|
|
Reference |
ISUP Signaling OPC and DPC attributes. It is associated with "block point". |
|
|
Reference |
ISUP Signaling OPC and DPC attributes that map to Region, Subregion, Node Type, and Node Name. |
|
|
Reference |
Point of Sale (POS) grouping of items with similar point of sale control and processing attributes. The entity type may also be used to control sales that are not properly identified at the item level. |
|
|
Lookup |
Lookup for type of identifier used in POS identity. |
|
|
Derived |
Point of Sale (POS) Tender transactions by minute and tender type for a workstation in an ORGANIZATION BUSINESS UNIT. |
|
|
Lookup |
Type of Point of Sale (POS) transactions. |
|
|
Reference |
List the various periods (or basis) on which points will expire. |
|
|
Reference |
Specifies limits for traffic flow to a configured bit rate with limited bursting capability. For example, a standard policer service has no buffering, meaning that packets that cannot be transmitted are simply dropped. |
|
|
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. 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. |
|
|
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. Such an object still evaluates to a single Boolean 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. |
|
|
Reference |
Lists the various Time Period with POLICY CONDITION. It gives the "capability of enabling or disabling a POLICY CONDITION according to a pre-determined time schedule". |
|
|
Reference |
General extension mechanism for representing POLICY CONDITIONs that have not yet been modeled with the attributes specified in this model. |
|
|
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. |
|
|
Lookup |
Lookup for categorizations of prepaid allowances. For example:
|
|
|
Lookup |
Lookup for valid deduction types as related to prepaid allowances (PPA). |
|
|
Reference |
Subtype of MARKER SERVICE. |
|
|
Reference |
Details the TRAFFIC CONDITIONING SERVICE linked to the PREAMBLE MARKER SERVICE. |
|
|
Lookup |
The type of preference relevant to consumers or customers (for example, color preference). |
|
|
Derived |
Monthly aggregation of prepaid account revenue, including: air time, recharge value and so on, by ACCOUNT, SALES CHANNEL, AGE ON NET BAND. |
|
|
|
Derived |
The summary of daily prepaid voucher recharge. |
|
Aggregate |
Monthly summary of free minutes allowance (PPA) in a PRODUCT OFFERING. |
|
|
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 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 |
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 |
Specification associated with (an instance of) a Voucher. The voucher customer can buy to refill their prepaid account, normally in form of a paper or plastic card. For example:
It is subtype to ITEM SPECIFICATION. |
|
|
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. |
|
|
Lookup |
Possible REASONs for setting a given price. This is informative only. |
|
|
Lookup |
Lookup for type codes and descriptions for COMPOSITE PRODUCT SPECIFICATION charge on a PRODUCT SPECIFICATION. For example:
|
|
|
Lookup |
Lookup for available reasons for PRICE TYPEs to be related to each other. |
|
|
Reference |
Assignment of related PRICE TYPEs. |
|
|
Reference |
Entity to monitor queues and ensure that they are used properly. Subtype of QUEUE SERVICE. |
|
|
Base |
Defines any type of problems in general. Specifies details that are always applicable when dealing with problems as part of a process. |
|
|
Base |
Any comments or additional text associated with a PROBLEM. It is a separate entity to allow several comments to a given PROBLEM depending on who is dealing with it. |
|
|
Lookup |
The different levels of priority which can be assigned to any PROBLEM (and concretely to SERVICE PROBLEM). |
|
|
Base |
Association of one or more ADDRESS LOCATIONs to a given PROBLEM. Typically, it would be the location of the source of the problem. But it could also be the address of main alarm or whatever fits the problem description. |
|
|
Base |
Describes Relationships between problems, in particular if they are causally related. |
|
|
Base |
Describes the resources involved in the root cause of the PROBLEM. |
|
|
Base |
Describes the services that are associated with the root cause of the PROBLEM. |
|
|
Base |
Defines the history of status of any PROBLEMs: for example, from opened to solved pending confirmation to solved. |
|
|
Base |
Associates TRACKING RECORDs to PROBLEMs. |
|
|
Reference |
Association of TROUBLE TICKETs to specific (service) PROBLEMs. |
|
|
Reference |
Defines the various possible processes as defined by the Communications Service Provider. It should normally fits within eTOM but could be generalized to any type of processes at any place (within a software or from an organization perspective). It is the general description of a potentially recurring series of events with various complexity (parallelism, sequentially related or not, and so on). This entity is required to track any process events in Oracle Communications Data Model. |
|
|
Base |
Tracks the costs associated with a specific PROCESS EVENT, from any point of view (labor cost, effective cost like ink, paper and stamps, and so on). |
|
|
Base |
The effective run of a given process from start to end. Although not explicitly required, a process event is usually expected to be an atomic event (no sub-process event). But nothing in Oracle Communications Data Model prevents a building up of complex process and process event structure. Process event is not a sub-type of EVENT. |
|
|
Reference |
Describes the effective or actual sequential relationship between PROCESS EVENTs. |
|
|
Base |
Assignment for a specific PROCESS EVENT of Operators (logical or mathematical in general) to some of its parameters and values. |
|
|
Reference |
Association of process events with a specific PRODUCT OFFERING PRICE (or rate plan). This is usually used at rating or Billing time to deal with specific offering or customers (or partners like for interconnection settlement) following particular processes or calculations. |
|
|
Derived |
Daily summary of the end-to-end invoice processing (Billing, issuing, dispatching), observed from the end process (that is, Successful Dispatching).This entity is critical for the computation of some TMF KPIs. |
|
|
Base |
Defines any INVOICE dispatching process (from upload to the web to standard mailing to the customers) with some specific statistics related.The process event is considered ended once the letter or email is sent or when the invoice is available for download to the customer. It does not wait to get confirmation of receipt. |
|
|
Base |
Lists and describes any INVOICE GENERATION PROCESS (also called Billing Process itself, from invoice item collections to final invoice set-up ready for printing or publishing) with some specific statistics related. All the bill content shall be present in an electronic form, ready to be sent as-is to either the printing process or to the web publishing or formatting process (for example that turns it into a PDF if it is not already the case). |
|
|
Base |
Describes statistics for the process of issuing a bill. For example, printing, preparing for customer online display, creating pdf file for download, and so on. |
|
|
Reference |
List the parameter expected and their definition to be filled to allow given PROCESSes to run. |
|
|
Reference |
Association of the standard Parameter(s) expected to the PROCESSes to be able to run. |
|
|
Lookup |
List of Operators (logical or mathematical in general) available to be associated with Parameters from specific processes. |
|
|
Reference |
Lists of effective Parameter values used per process event. |
|
|
Reference |
Defines the standard sequential or causal relationships between processes. These are not necessarily the effectively used ones but default should be at least defined. |
|
|
Lookup |
Type of relationship between processes. Typically, it is "SEQUENTIAL" (FROM then TO) or "PARENT" (FROM includes TO). But other relationships could be imagined. |
|
|
Reference |
Lists the specifications (that is, invariant characteristics) of a given PROCESS. |
|
|
Reference |
Relationships between PROCESS SPECIFICATIONs, where required. |
|
|
Lookup |
Lists the possible status of a process event. The first Word of the "NAME" can be used for grouping purpose. |
|
|
Lookup |
Lists the types of PROCESSes one deals with. It should correspond to the eTOM processes a priori, but there are none pre-defined. |
|
|
Reference |
The real instance of a given PRODUCT SPECIFICATION which a customer can purchase or rent (or eventually gets for free as part of a PRODUCT OFFERING). The product is linked to the Customer Order Line Item and relates a product to a customer. For example:
|
|
|
Lookup |
Brand of the PRODUCT SPECIFICATION or PRODUCT OFFERING. 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 OFFERING 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 |
The PRODUCT CATALOG presentation type. For example:
|
|
|
Reference |
Defines the relationship between a PRODUCT CATALOG and the PRODUCT OFFERINGs that appeared on the PRODUCT CATALOG. |
|
|
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 |
List the possible types of PRODUCT characteristics (features, look, and so on). |
|
|
Reference |
Lists the possible values a given PRODUCT characteristic can take, ordered by type. |
|
|
Reference |
Coverage of a product over geographical area. |
|
|
|
Reference |
Details the area covered by a given PRODUCT or SERVICE COVERAGE AREA. It relies on third party marketing data associated with given ADDRESS LOCATION Code within a given SERVICE COVERAGE AREA. |
|
Reference |
Assignment of valid EQUIPMENT FUNCTIONALITY and PRODUCT SPECIFICATION VERSIONs to a PRODUCT SPECIFICATION. |
|
|
Reference |
Association of PRODUCT SPECIFICATION to certain geography or region, usually as available for sales or delivery (for example, Fiber-to-home network is usually only available in big cities in the first phase of development). |
|
|
Lookup |
Lookup for the ways to classify products according business organization. For example: Wireless, Fixed Line, and so on. |
|
|
Reference |
Defines how a product is brought to the market, including: positioning, pricing, and bundling details. For example:
|
|
|
Lookup |
Lookup for type of product participation (inclusion) in the market plan. For example:
|
|
|
Reference |
Reference for Available PRODUCT OFFERING in different area or organization business unit. |
|
|
Base |
Sub-table of the COST TYPE table. This entity associates a specific cost to a given PRODUCT OFFERING. The cost should not be related to the CAMPAIGN or to the PROMOTION, but just to the PRODUCT OFFERING. |
|
|
Reference |
Defines the customer document requirements of each PRODUCT OFFERING. |
|
|
Reference |
Relationship between PRODUCT OFFERING and Geography. Some PRODUCT SPECIFICATIONs may only be sold in a particular area. |
|
|
Reference |
Hierarchy level to group the various PRODUCT OFFERINGs. For example:
|
|
|
Reference |
Defines relationship of PRODUCT OFFERINGs to one or more PRODUCT OFFERING GROUPs. |
|
|
Lookup |
Lookup for the type code and description for a PRODUCT OFFERING GROUP. |
|
|
Base |
The management history of PRODUCT OFFERING by the employee. |
|
|
Reference |
Defines the PRODUCT OFFERING availability over certain Market Segments. |
|
|
Reference |
Reference for available PRODUCT OFFERING subscriptions in an ORGANIZATION BUSINESS UNIT (store, outlet, and so on). |
|
|
Reference |
Grouping mechanism for prices and usage limits associated with a PRODUCT SPECIFICATION. |
|
|
Reference |
Part of a PRODUCT OFFERING PRICE representing a single element of the price. Sub-entities further define these elements. It corresponds to a Rate in some billing systems. |
|
|
Reference |
A PRODUCT OFFERING PRICE that is made up of parts. This could correspond to a price in a price list. Do not confuse with PRODUCT OFFERING RATING PLAN which is the complete price list related to fees, usage or events, while PRODUCT OFFERING PRICE could be one or several elements of it. |
|
|
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 |
Recurring Product Offering Price (Typically for any periodically recurring fees). |
|
|
Reference |
Defines the relationship between PRODUCT OFFERING PRICE composite (or rating plan) and the product offering price composites or components (usually one uses the other). |
|
|
Lookup |
Type of relationships between PRODUCT OFFERING PRICEs (dependencies, parent child, and so on). |
|
|
Lookup |
Type of PRODUCT OFFERING. It can be classified by qualification of targeted customers. For example, a Handset-replacing program can be only for a Platinum Customer, while a long-distance loyalty fee discount might be applicable to everyone. |
|
|
Reference |
The Relationship between PRODUCT OFFERING and PRODUCT. Through this assignment, the PRODUCT OFFERING can be designed based on Product. 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 |
Association of a default PRODUCT OFFERING PRICE (or price list) to a PRODUCT OFFERING. |
|
|
Reference |
Assigns Products to PRODUCT OFFERINGs. |
|
|
Reference |
Group of PRODUCT OFFERING PRICE (composite or not) that are collected as a complete price list (or tariff plan). |
|
|
Reference |
Details of the PRODUCT OFFERING RATING PLAN, such as general rating method type, UNIT OF MEASURE of Usage depending on the PRODUCT SPECIFICATION, and so on. This is the price list itself. |
|
|
Reference |
Defines the relationship between two PRODUCT OFFERINGs. For example:
|
|
|
Reference |
Lookup for the types of PRODUCT OFFERING relationships. |
|
|
Reference |
Describes how the customer may be given different PRODUCT OFFERING according to available supporting documents they can provide (including income certification, Identification doc, and so on). Tracks under what circumstances what PRODUCT OFFERING is available to customer. |
|
|
Reference |
The detail term value according to each term for the market plan, including monthly charge. |
|
|
Lookup |
Type of the PRODUCT OFFERING. For example:
|
|
|
Reference |
Price alteration applied to the given subscription. |
|
|
Reference |
Part of a PRODUCT SUBSCRIPTION PRICEe representing a single element of the price. |
|
|
Reference |
The relationship between the Party Role and PRODUCT SUBSCRIPTION PRICE to track who managed the PRODUCT SUBSCRIPTION PRICE. |
|
|
Reference |
Association of a value from a given PRODUCT CAPABILITY, in a concrete instance of PRODUCT available for sales (or product subscription).For example, a set top box that is by default Bluetooth enabled for this specific promotion in this shop should have an entry for each set-top box available for sales. |
|
|
Reference |
Describes the Relationship between concrete PRODUCTs (as instance of PRODUCT SPECIFICATION). Typically, it could be the fact that a specific high value headset has to be sold with this phone available for sales in this shop. |
|
|
Lookup |
Lists the possible types of relationships between PRODUCTs. |
|
|
Reference |
Relationship between a Product Spec characteristic and its translation on the Resource Spec Characteristics. Entity to deal with the M:N relationship between those two entities. |
|
|
Reference |
Direct association (dependence usually) between values of PRODUCT SPECIFICATION CHARACTERISTIC and the value of a given RESOURCE SPECIFICATION CHARACTERISTIC. |
|
|
Reference |
The product provided by the carrier. Product includes COMPOSITE PRODUCT SPECIFICATION information. The composition of a COMPOSITE PRODUCT SPECIFICATION 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. |
|
|
Lookup |
Lookup for valid reason codes and descriptions for PRODUCT SPECIFICATION RELATIONSHIP. |
|
|
Lookup |
Lookup for classification of the PRODUCT SPECIFICATION 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 |
Association of a configurable Characteristics to a PRODUCT SPECIFICATION. |
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Product Spec Characteristics. |
|
|
Reference |
A use of the Characteristic Specification by an Product Specification to which additional properties apply. |
|
|
Reference |
A value of a Product Spec Characteristic chosen for a PRODUCT SPECIFICATION that further defines what the PRODUCT SPECIFICATION is. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Product Spec Characteristics. |
|
|
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 |
Various product COLUMNS - To be used for customization only as additional ways of adding invariant characteristics to PRODUCT SPECIFICATION. |
|
|
Base |
Sub-table of the COST TYPE table, used to associate a specific cost to a given product. |
|
|
Lookup |
Lookup for type code and description for PRODUCT COVERAGE AREA. For example:
|
|
|
Reference |
Links detailed geographical locations to a certain PRODUCT COVERAGE AREA. |
|
|
Lookup |
Categorizations or Groups into which PRODUCTs may be assigned, usually based on similar functionality. For example, Operator may group product as Postpaid Wireless, Prepaid Wireless, Fixed Line Subscription, Calling Card, Paid TV, Broadband, and so on. |
|
|
Reference |
Defines relationship of PRODUCT SPECIFICATION and one or more PRODUCT SPECIFICATION GROUPs. |
|
|
Lookup |
Lookup for codes and descriptions of types of PRODUCT SPECIFICATION GROUPs. |
|
|
Reference |
Detailed Product History, as column name, value pairs. |
|
|
Base |
Defines relationship between EMPLOYEE, PRODUCT SPECIFICATION MANAGEMENT ROLE, and PRODUCT SPECIFICATION. |
|
|
Lookup |
Lookup for available reasons for a PRODUCT SPECIFICATION MANAGEMENT HISTORY relationship. |
|
|
Lookup |
Lookup for valid role codes and descriptions an employee may be assigned in PRODUCT SPECIFICATION MANAGEMENT HISTORY. For example:
|
|
|
Reference |
Assigns a PRODUCT SPECIFICATION to one or more NETWORKs. |
|
|
Reference |
Defines a relationship between a PRODUCT SPECIFICATION and a related product. |
|
|
Base |
A history of the Status for a PRODUCT. For example:
|
|
|
Lookup |
Lookup for type of specific Product status type. For example:
|
|
|
Lookup |
Lookup for the type of the PRODUCT SPECIFICATION. For example:
|
|
|
Reference |
Iteration of a PRODUCT SPECIFICATION created when a minor change is made to the PRODUCT SPECIFICATION setting that does not require creating a new PRODUCT SPECIFICATION. |
|
|
Base |
A history of the Status for a PRODUCT instance, such as New, Broken, Returned, lost, reserved, obsolete, and so on. |
|
|
Lookup |
Type of specific PRODUCT instance status type, for example:
|
|
|
Reference |
The record of customer using a product or service which may be based on a agreement. Customer's subscription to services is the basis of billing and network usage authorization. |
|
|
Reference |
Relational assignment of one PRODUCT SUBSCRIPTION to another PRODUCT SUBSCRIPTION. This is optional. |
|
|
Lookup |
Lookup for type codes and descriptions pertaining to PRODUCT SUBSCRIPTION ASSIGNMENT. |
|
|
Lookup |
Lookup for available type codes and descriptions for Subscription Events. |
|
|
Reference |
Charge information over a specific subscription. |
|
|
Reference |
Relationship between PRODUCT SUBSCRIPTION PRICEs (dependencies, conditions, and so on). |
|
|
Reference |
Association of a specific PRODUCT SUBSCRIPTION to a specific PRODUCT OFFERING PRICE. This typically describes how the final price paid (or tariff plan used) by customer is not standard (typical for B2B). |
|
|
Lookup |
Lookup for available code and description for the status of a PRODUCT SUBSCRIPTION. For example:
|
|
|
Lookup |
Lookup for category codes and descriptions used to group or categorize PRODUCT SUBSCRIPTION STATUS. |
|
|
Base |
A history of the status of a PRODUCT 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 PRODUCT SUBSCRIPTION may be assigned a status. |
|
|
Lookup |
Type of PRODUCT SUBSCRIPTION STATUS, for grouping purpose at reporting level. |
|
|
Lookup |
Lookup for available type codes and descriptions pertaining to PRODUCT SUBSCRIPTIONs and PRODUCT SPECIFICATIONs to which Values may be assigned. For example:
|
|
|
Lookup |
Lookup for available type codes and descriptions for PRODUCT SUBSCRIPTIONs. For example:
|
|
|
Reference |
The usernames assigned to customer for given products. For example:
|
|
|
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 |
Details regarding each CAMPAIGN MESSAGE broadcast through a MEDIA OBJECT. |
|
|
Reference |
Associates PRODUCT CATALOGs to a PROMOTION. |
|
|
Reference |
Associates PRODUCT OFFERINGs to a PROMOTION, typically, when a given PRODUCT OFFERING will be offered by the PROMOTION only during a certain period. |
|
|
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. |
|
|
|
Derived |
Specifies target promotion factors retrieved from SVM mining model. |
|
|
Derived |
Mining target entity to store target promotion ROC details calculated using SVM mining model. |
|
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 agreement 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 agreement 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 SPECIFICATION (already purchased) that does not currently purchase another PRODUCT SPECIFICATION (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 |
Similar to CUSTOMER RESTRICTED INFO, but applied only to PROSPECT. It contains age, marital status, and so on. |
|
|
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 |
Represents a single string value, or a set of string values. Each value can have wildcards. |
|
|
Reference |
Represents using the IEEE 802.1q Class of Service value (which is three bits) as part of a condition expression. |
|
|
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 Distinguished Name variable, which may include wildcards. This variable type is specifically defined for retrieving LDAP-based data. |
|
|
Reference |
Represents using the value of the DSCP byte as part of a condition expression. |
|
|
Reference |
Represents using the value of the Ethertype protocol number of Ethernet frames as part of a condition expression. |
|
|
Reference |
Represents using the value of the IP protocol number as part of a condition expression. |
|
|
Reference |
Represents using the value of the IP ToS byte as part of a condition expression. |
|
|
Reference |
Represents using the value of IPv4 source and/or destination addresses as part of a condition expression. |
|
|
Reference |
Represents using the value of the flow ID in the specified packet header as part of a condition expression. |
|
|
Reference |
Represents using the value of IPv4 source and/or destination addresses as part of a condition expression. |
|
|
Reference |
Represents filtering on a particular version of the IP protocol as part of a condition expression. |
|
|
Reference |
Represent a single or set of string variable. Each can have wildcards. |
|
|
Reference |
Represents using the value of port source and/or destination fields as part of a condition expression. |
|
|
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 using the IEEE 802.1q VLAN ID value (which is 12 bits) as part of a condition expression. |
|
|
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 SPECIFICATIONs. 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. |
|
|
Reference |
Relationships between QOS SERVICE, to be able to build M:N relationships between those. |
|
|
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 |
Queuing can be thought of as the act of delaying of packets inside a device before they are transmitted to the next device. This is often called congestion management. There are many different algorithms to do this task, each having different purposes, different implementation (and therefore programming) complexities, and different uses. Since the semantics of these algorithms are very different, each algorithm is a subtype of QUEUE SERVICE. |
|
|
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 Resource). 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 UDR 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. |
|
|
Lookup |
General "REASON" entity that lists all possible reasons for whatever events. The REASON CATEGORY helps for determining which list of reasons is to be used in which case. This entity is not used in Oracle Communications Data Model. |
|
|
Lookup |
Grouping of REASONs dealing with the same event, or process, or source. It can be used for reporting purpose or to choose the right list of possible reasons in a given case. This entity is not used in Oracle Communications Data Model. |
|
|
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 |
Lists the RED Dropper Services, that represents the ability to drop network traffic using a Random Early Detection (RED) type of algorithm. The purpose of a RED algorithm is to avoid congestion (as opposed to managing congestion). |
|
|
Reference |
Lists the Random Early Detection (RED) elements, that define the drop probability, weighting, and other important parameters for distinguishing one traffic type from another traffic type for applying different dropping behavior. If the algorithm used is RED, then by definition there is only one entry in this entity (the REDServiceElement). |
|
|
Base |
Event related to the Redemption or use of LOYALTY PROGRAM points into something (through transfer, purchase when associated with a retail line item, recharge, and so on). |
|
|
Aggregate |
Monthly summary of LOYALTY PROGRAM redemption statistics. |
|
|
Lookup |
Lookup for redemption type that maintains all possible point redemption types and organizes redemption data by redemption type for analysis purposes. |
|
|
Reference |
User-defined referrer category. |
|
|
Reference |
User-defined referrer category level. |
|
|
Reference |
Web page containing the referring link. |
|
|
Reference |
URL of the REFERRING SITE. |
|
|
Lookup |
List all Possible Types of Relationship. This entity is not used in Oracle Communications Data Model. |
|
|
Lookup |
This lookup for religion. For example:
|
|
|
Reference |
Lookup for religious affiliations. |
|
|
|
Reference |
The Remote Radio Unit is part of Distributed Node B base station system, which manages the signals from the antennas and communicate with BBU. Using Fiber connected RRU, the antenna can be deployed far from the BBU location. |
|
Reference |
Set of MANAGED ENTITYs that must be replaced as a unit. |
|
|
Reference |
All elements belonging to the network (normally, only of the Communications Service Provider) to deliver the communication services. |
|
|
Base |
Alarms with any (somehow managed) resources. It shall store information about the alarm details or condition. |
|
|
Base |
Comments or additional text coming with the RESOURCE ALARM. It could be external weather condition or anything not easily storable in the RESOURCE ALARM description. |
|
|
Base |
Relationships between RESOURCE ALARMs, typically cascading (one triggers the other). |
|
|
Base |
Association of a given RESOURCE ALARM to a given RESOURCE. The type of assignment allows to determine whether it is the Alarm Trigger (or control source) or Source itself that caused this RESOURCE ALARM (the origin). |
|
|
Base |
Association of Tracking Record of End-Users with a given RESOURCE ALARM. |
|
|
Base |
The business interaction role which can be assigned by a RESOURCE. |
|
|
Reference |
A characteristic quality or distinctive feature of an Resource 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 RESOURCE CHARACTERISTIC by a concrete RESOURCE.It could be restricted to those to which additional properties (attributes) apply or override the properties of similar properties contained in RESOURCE CHARACTERISTIC. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between or among RESOURCE CHARACTERISTICs. |
|
|
Reference |
A number or text that can be assigned to an RESOURCE SPECIFICATION CHARACTERISTIC. |
|
|
Reference |
A use of the RESOURCE CHARACTERISTIC VALUE by a RESOURCE. One could limit to those which additional properties (attributes) apply or override the properties of similar properties contained in RESOURCE CHARACTERISTIC VALUE. |
|
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among RESOURCE CHARACTERISTIC VALUEs. |
|
|
Base |
Subtype of COST, which associate a specific cost to a given network element. For example, purchase, maintenance, recycling. |
|
|
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. |
|
|
Reference |
Defines historical versions of RESOURCE FACING SERVICE SPECIFICATION. |
|
|
Reference |
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 more CUSTOMER FACING SERVICE SPECIFICATIONs 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. |
|
|
Reference |
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. |
|
|
Reference |
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 |
This class defines a SERVICE SPECIFICATION, in terms of a set of ServiceSpecificationRoles, for a ResourceFacingService. This is the base class for defining ServiceSpecificationRoles that are used to represent the invariant characteristics of a ResourceFacingService. This enables the ResourceFacingService to be managed abstractly using ServiceSpecificationRoles. It also helps define the SERVICE SPECIFICATION in terms of the functions that it has or provides. |
|
|
Base |
Defines which RESOURCEs are affected by a given network (or RESOURCE related to the network) fault. |
|
|
Base |
A history of the Status for a RESOURCE, such as New, Broken, Returned, lost,reserved(for VIP customer). When agreement terminates, the customer may return the RESOURCE or declare it as lost and possibly pay some penalty for it. |
|
|
Reference |
A role a business entity (such as PARTY ROLE or RESOURCE ROLE) plays in the relationship for a RESOURCE. For example: user, owner, and so forth. This is different than the role a resource plays. |
|
|
Base |
A type of Request that represents a Service Order's services decomposed into the Resources on which the services will be provisioned. |
|
|
Base |
The purpose for the RESOURCE ORDER expressed in terms of a RESOURCE SPECIFICATION or a RESOURCE. |
|
|
Reference |
Defines which PARTY produced, owns, or is using which RESOURCE. The PARTY could a customer, employee, or vendor (initial vendor, and maintenance). |
|
|
Reference |
Defines the relationship between PARTY and its managed RESOURCEs. |
|
|
Reference |
A measure of the manner in which a Resource is functioning. |
|
|
Lookup |
The invariant characteristics of a measure of the manner in which a Resource is functioning. |
|
|
Reference |
The Resource Port covers both logical and physical port together and manage as a single entity. |
|
|
Reference |
The relationship between two Network Resources, for example, in GSM, multiple BTSs are connected to a BSC, in Broadband Service, several customer lines may be connected to a DSL MODEM. |
|
|
Lookup |
The Type of Network Resource Relationship. For example, "Pair Connected", "Master-Subordinate", "Primary-Backup", and so on. |
|
|
Reference |
This entity defines the concept of various types of roles associated with Resources (both physical and logical). |
|
|
Reference |
This abstract entity is defined to map the class that implements the semantics of the "ElementTakesOnRoles" aggregation. It also serves as the parent class for defining the classes that implement the RolesDescribePhysical Element, RolesDescribeLogical Element, and RolesDescribeCompoundl Element aggregations. These three classes are named RolesDescribePhysical ElementDetails, RolesDescribeLogical ElementDetails, and RolesDescribeCompoundl ElementDetailsm respectively. |
|
|
Reference |
Defines the relationship between RESOURCE ROLE and PARTY. |
|
|
Reference |
Details of the relationship (typically dependency) between RESOURCE ROLE and PARTY ROLE (Customer, provider, and so on). |
|
|
Reference |
This is the abstract base entity for all Resource Role Specification subclasses. The Network Resource Role Spec enables relationships to be defined between it and other network element roles. This helps prevent relationship explosion. The Network Resource Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with Resources (both physical and logical). |
|
|
Reference |
This entity defines the invariant characteristics and behavior (attributes, methods, constraints, and relationships) of a Managed Resource. |
|
|
Lookup |
Category of resource to further classify resource specification type (grouping). Available dimension for customization. |
|
|
Reference |
A characteristic quality or distinctive feature of a RESOURCE SPECIFICATION. The characteristic can be 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). |
|
|
Reference |
A use (or assignment) of the RESOURCE SPECIFICATION CHARACTERISTIC by a SERVICE SPECIFICATION which additional properties (attributes) apply or override the properties of similar properties contained in RESOURCE SPECIFICATION CHARACTERISTIC. This aggregation defines the set of characteristics, or distinguishing features, of a RESOURCE SPECIFICATION. |
|
|
Reference |
Relationship between RESOURCE SPECIFICATION CHARACTERISTICs (ParentChild, Exclusion, Requirement, and so on). |
|
|
Reference |
The values (a number or text) that can be assigned to a RESOURCE SPECIFICATION CHARACTERISTIC. |
|
|
Reference |
Association of Values to Characteristics of Resource Specification. It should list all possible values a Resource Spec Characteristic can have. |
|
|
Reference |
Relationship between Resource Spec Char Value (Typically, dependency like exclusion, requirement, and so on). |
|
|
Reference |
A role that a Resource Specification plays in defining a PERFORMANCE SPECIFICATION. |
|
|
Lookup |
Categorize sets of RESOURCE SPECIFICATIONs such as ROUTER, SWITCH, and so on. |
|
|
Reference |
Defines differences in attributes, methods, relationships, and/or constraints that characterize this particular RESOURCE SPECIFICATION, but which are not enough to warrant creating a new RESOURCE SPECIFICATION. |
|
|
Reference |
Defines the semantics of the RESOURCE SPECIFICATION aggregation. Specifically, it enables an application to define which set of versions of this RESOURCE SPECIFICATION are appropriate for a given task (which RESOURCE SPECIFICATION VERSION should be used when). This aggregation represents the set of versions of this RESOURCE SPECIFICATION. |
|
|
Base |
Tracks the state history of each resource, for example, power off, in use, decommissioned, and so on. |
|
|
Lookup |
Lookup for reasons why the RESOURCE is at certain state. For example, power failure, earthquake, new purchase, and so on. |
|
|
Lookup |
Lookup of the Resource State of a given RESOURCE, like power off, installed, decommissioned, and so on. |
|
|
Lookup |
A detailed description of a RESOURCE or network element usage event (for example, a purchase or a lease of a resource). |
|
|
Derived |
Summary of SKU ITEM sales and returns by day, ORGANIZATION BUSINESS UNIT, and optionally by promotional campaign. |
|
|
Base |
A line item component of a RETAIL TRANSACTION that records the exchange in ownership of a merchandise item (for example, a sale or return) or the sale or refund related to a service. |
|
|
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. |
|
|
Base |
A line item component of a RETAIL TRANSACTION that records the settlement of that transaction with an offsetting, valid tender type. |
|
|
Lookup |
||
|
Reference |
Place from where transactions take place. Meeting point for customer and retail organization. RETAIL TOUCHPOINT can be both logical and physical.
|
|
|
Base |
A type of transaction that records the business conducted between the retail enterprise and another party involving the exchange in ownership or accountability, or both, for merchandise or tender, or both, or involving the exchange of tender for services. |
|
|
Base |
A detail line item of a RETAIL TRANSACTION that records the business conducted between the organization store and another party involving the exchange in ownership or accountability, or both, for merchandise or tender, or both, or involving the exchange of tender for services. |
|
|
Lookup |
Lookup for available types of RETAIL TRANSACTION LINE ITEM. |
|
|
Lookup |
Lookup for types of retail processing. For example:
|
|
|
Derived |
Daily summary of any revenue stream associated with a PRODUCT OFFERING and PRODUCT SPECIFICATION. It considers Prepaid (Expired and effectively Used Prepaid Amount), Postpaid (Invoiced or not) and other revenue streams.All measures are summable over time or any other dimensions. This entity is critical for the computation of any revenue related KPI, and in particular ARPU. |
|
|
Aggregate |
Monthly summary of REVENUE DAY DRVD. All measures are summable for a given product specification and product offering hierarchy level. Summing all measures over all dimensions without restricting to specific level of hierarchy would lead to wrong result (double counting). |
|
|
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. |
|
|
Lookup |
Lookup for different methods of calculating the Recency, Frequency, Monetary, and Profitability (RFMP) scores. |
|
|
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, 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. |
|
|
Lookup |
Abstract entity that defines a root entity in TMF SID, such as Customer, Product, and so on. |
|
|
Reference |
Scheduler that serves each active QUEUE SERVICE, one after another. A QUEUE SERVICE is defined to be active if it has any packets that are enqueued. |
|
|
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-43 S to V Entity Descriptions
| Entity Name | Type | Description |
|---|---|---|
|
Lookup |
A code denoting how the item is being treated in the line item. For example:
|
|
|
Aggregate |
Monthly summary of Sales Campaign results by PRODUCT OFFERING, 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 agreement. |
|
|
Base |
The sales commission issued to the sales agent. |
|
|
Reference |
The sales commission plan for particular COMPOSITE PRODUCT SPECIFICATION and sales agent level. |
|
|
Reference |
Details about the SALES COMMISSION PLAN per PRODUCT OFFERING and PROMOTIONs, including sales quota and commission rate. |
|
|
Derived |
Monthly summary of sales representative performance measured by sales, commission, and so on. |
|
|
|
Reference |
Abstracted entity to provide SCD2 capability for all its children. |
|
|
Lookup |
Super entity to provide SCD2 and LANGUAGE support for all its children. |
|
Reference |
A Scheduler is used in the network forwarding path to determine how output queues are serviced. This service uses the QUEUE SERVICEs (that are defined in this entity) to store packets and then services these queues according to a pre-defined algorithm. When there is no congestion, the net effect is simply FIFO. However, when there is congestion, scheduling is the primary QoS action component. |
|
|
Reference |
Defines a SCHEDULING SERVICE as an independent (that is, standalone) TRAFFIC CONDITIONING SERVICE. This is fundamentally different than the SCHEDULING SERVICE COMPOSITE, which models a SCHEDULING SERVICE as the combination of other existing SCHEDULING SERVICEs (as well as providing its own extensions). |
|
|
Reference |
This entity models a SCHEDULING SERVICE as a set of coordinated SCHEDULING SERVICEs. This is fundamentally different than the SCHEDULING SERVICE ATOMIC, which is used to model a SCHEDULING SERVICE as a standalone TRAFFIC CONDITIONING SERVICE. |
|
|
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:
|
|
|
Reference |
Lists the possible types of "Search" over the website, as part of a WEB VISIT and NAVIGATION. |
|
|
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 SPECIFICATION. |
|
|
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 |
Lists the Server (Hardware and Software) on which applications can run or users can log in. |
|
|
Reference |
Lists and details the Farms of SERVERs available (when meaningful from a network, offering, analytics or end-user perspective) |
|
|
Lookup |
Possible Global Status of the SERVER from an external point of view (on, off, frozen, starting, shutting down). |
|
|
Reference |
Service is an internal technical presentation of available PRODUCT SPECIFICATIONs 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 |
Collects the history of the assignment of a given SERVICE to a given location. |
|
|
Reference |
Conceptually, a Service Bundle is thought of as a collection of Resource Facing Service Specifications. This entity enables the needs of different sets of Resource Facing Service Specifications to be grouped together - hence, the name "bundle". Since these are Resource Facing Specifications, they define reusable templates for implementing the Resource 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 Resource 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 Resource 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 Resource 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 Resource 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 Resource 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 SPECIFICATIONs as a set of different instances of individual, independent Resource Facing Service Specs. This is fundamentally different than the SERVICE BUNDLE SPECIFICATION COMPOSITE entity, which models one SERVICE BUNDLE SPECIFICATION COMPOSITE as the combination of other existing SERVICE PACKAGE SPECIFICATIONs (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 SPECIFICATION), 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 SPECIFICATION COMPOSITE entity. |
|
|
Reference |
A Service Bundle Spec Composite defines an integrated set of SERVICE BUNDLE SPECIFICATIONs that collectively meets the needs of a Resource 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 SPECIFICATIONs (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 SPECIFICATION), 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 SPECIFICATION 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 SPECIFICATION ATOMIC entity, as you want to reuse the first SERVICE BUNDLE SPECIFICATION ATOMIC entity. These could be aggregated to form an instance of a Service Bundle Spec Composite object. |
|
|
Lookup |
Lookup for category of SERVICE. For example:
|
|
|
Reference |
Define a set of attributes, each of which can be assigned to a corresponding set of attributes in a ServiceCharacteristic object. The values of the attributes in the ServiceCharacteristicValue Entity describe the values of the attributes that a corresponding ServiceCharacteristic object can take on. |
|
|
|
Reference |
This is how a list of SERVICE CHARACTERISTIC VALUE (of a service in use) is turned into a specific list of PRODUCT CHARACTERISTIC VALUE (Product or Product Subscription in Use). |
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among SERVICE SPECIFICATION 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 Resource 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 agreement 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 AGREEMENT TERM. |
|
|
Reference |
Detail line items for a SERVICE LEVEL AGREEMENT. |
|
|
Reference |
Relationships between service level agreement (typically parent child or mutually exclusive). |
|
|
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 RESOURCE helps to supply or to support a particular Resource Facing 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 SPECIFICATION or a Service. |
|
|
Reference |
A Service Package is derived from an associated SERVICE PACKAGE SPECIFICATION. The SERVICE PACKAGE SPECIFICATION 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 SPECIFICATION that it is derived from. This is because the SERVICE PACKAGE SPECIFICATION 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 a type of service bundle can support other types of SERVICE PACKAGEs. |
|
|
Reference |
A Service Package Spec defines the concept of bundling a set of different CUSTOMER FACING SERVICE SPECIFICATIONs 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 PRODUCT SPECIFICATIONs can be built from their associated Product Specification. Treating this set of CUSTOMER FACING SERVICE SPECIFICATIONs 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. |
|
|
Reference |
A Service Package Spec Atomic object models different SERVICE PACKAGE SPECIFICATIONs as a set of different instances of individual, independent CUSTOMER FACING SERVICE SPECIFICATIONs. This is fundamentally different than the Service Package Spec Composite object, which models one SERVICE PACKAGE SPECIFICATION as the combination of other existing SERVICE PACKAGE SPECIFICATIONs (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. |
|
|
Reference |
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 |
Keeps track of the history of Service Management by a given PARTY. |
|
|
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. |
|
|
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 RESOURCE helps to supply or to support a particular RESOURCE FACING SERVICE. |
|
|
Base |
Problem associated with a service delivery (of any type, whatever the reason). This entity is physicalized and problem analysis should be done from this level. |
|
|
Lookup |
Type of SERVICE PROBLEM CHARACTERISTICs, grouping the typical parameters that always come with SERVICE PROBLEMs. |
|
|
Reference |
Lists the general Characteristics available (or required) for SERVICE PROBLEM to be better defined or described. |
|
|
Reference |
Lists the possible Values a SERVICE PROBLEM CHARACTERISTIC may take. |
|
|
Derived |
Summarized information at Day level of any SERVICE PROBLEM occurring or still not solved for further analysis. |
|
|
Base |
Association of SERVICE PROBLEMs and RESOURCE ALARM related to those service problems. |
|
|
Base |
Relationship between the services (a priori or effectively) affected by a service problem. |
|
|
Base |
Tracks how many product subscriptions are affected by the service problem or network fault, as a measure of criticality. |
|
|
Base |
Sub-type of Party Interaction Thread, dedicated to a service request raised from a customer, which may involves a customer field service support order, or changing customer contact information. |
|
|
Reference |
Associates a resource or network element to a service as a way of describing how the service is supported. |
|
|
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 Resource- 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 RESOURCE, LOGICAL RESOURCE, or other Services. |
|
|
Reference |
Specifies the service specification hierarchy. All SERVICE 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 RESOURCE FACING SERVICE. However, each instance of a SERVICE is made up of changeable as well as invariant attributes, methods, relationships and constraints. A SERVICE SPECIFICATION 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. |
|
|
Reference |
This entity defines SERVICE SPECIFICATIONs that do not have any subordinate SERVICE SPECIFICATIONs. In other words, a ServiceSpecAtomic 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. |
|
|
Reference |
Relationship between a SERVICE SPECIFICATION CHARACTERISTIC and its translation on the RESOURCE SPECIFICATION CHARACTERISTICs. Entity to deal with the M:N relationship between those two entities. |
|
|
Reference |
A use of the SERVICE SPECIFICATION CHARACTERISTIC by an SERVICE SPECIFICATION to which additional properties (attributes) apply or override the properties of similar properties contained in SERVICE SPECIFICATION CHARACTERISTIC. |
|
|
|
Reference |
Relationship between the value of a characteristic of a Service Specification with the value of a related Resource Specification Characteristic. Typically, it is a dependence relationship. |
|
Reference |
A aggregation, migration, substitution, dependency, or exclusivity relationship between or among SERVICE SPECIFICATION CHARACTERISTIC VALUEs. |
|
|
Reference |
Describes a use of the SERVICE SPECIFICATION CHARACTERISTIC VALUE by an ENTITY SPECIFICATION to which additional properties (attributes) apply or override the properties of similar properties contained in SERVICE SPECIFICATION CHARACTERISTIC VALUE. |
|
|
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 aggregation, migration, substitution, dependency, or exclusivity relationship between or among SERVICE SPECIFICATION CHARACTERISTICs. |
|
|
Reference |
A SERVICE SPECIFICATION CHARACTERISTIC VALUE defines a set of attributes, each of which can be assigned to a corresponding set of attributes in a SERVICE SPECIFICATION CHARACTERISTIC. The values of the attributes in the SERVICE SPECIFICATION CHARACTERISTIC VALUE describe the values of the attributes that a corresponding SERVICE SPECIFICATION CHARACTERISTIC can take on. |
|
|
Reference |
A SERVICE SPECIFICATION CHARACTERISTIC VALUE defines a set of attributes, each of which can be assigned to a corresponding set of attributes in a SERVICE SPECIFICATION CHARACTERISTIC. The values of the attributes in the SERVICE SPECIFICATION CHARACTERISTIC VALUE describe the values of the attributes that a corresponding SERVICE SPECIFICATION CHARACTERISTIC can take on. |
|
|
Reference |
This entity defines SERVICE SPECIFICATIONs that are formed by aggregating other SERVICE SPECIFICATIONs. The types of SERVICE SPECIFICATIONs that are aggregated may be ServiceSpecAtomic or SERVICE SPECIFICATION COMPOSITEs. A SERVICE SPECIFICATION COMPOSITE collectively defines all of the invariant characteristics of Services that it serves as a template for. |
|
|
Reference |
Defines the relationship between Service Spec and Product, for example, to track which Product requires which Service Spec. |
|
|
Reference |
Relationship between SERVICE SPECIFICATIONs (dependencies, exclusion, and so on). |
|
|
Reference |
Defines the relationship between SERVICE SPECIFICATION and Resource Spec. For example, to track which Resource Specifications are required for a certain type of SERVICE SPECIFICATION to work. |
|
|
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. |
|
|
Lookup |
Type ofSERVICE SPECIFICATION, for grouping purposes. |
|
|
Reference |
This entity represents the ability to distinguish between different instances of SERVICE SPECIFICATIONs. It 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 |
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 |
A detailed description of a service usage event (for example, a purchase or a usage of a service). |
|
|
Reference |
Represents the semantics (for example, exists, uses, and other relationships) that exist when a PHYSICAL RESOURCE is used to help supply or support a particular SERVICE. |
|
|
Base |
Describes a session from a computing perspective rather than from an UDR EVENT perspective (for example GPRS Session). |
|
|
Lookup |
Lists the possible types of SESSIONs that will be dealt with for grouping purpose. |
|
|
Reference |
Set-top box for Television service. |
|
|
Reference |
Set-top box model specification. |
|
|
|
Data Mining |
Specifies settings of Attribute Importance algorithm. |
|
|
Data Mining |
Specifies settings of Decision Tree algorithm for customer churn analysis. |
|
|
Data Mining |
Specifies the cost of misclassification for customer churn analysis using Decision Tree algorithm. |
|
|
Data Mining |
Specifies settings of SVM algorithm for customer churn analysis. |
|
|
Data Mining |
Specifies prior probabilities for customer churn analysis using SVM algorithm. |
|
|
Data Mining |
Specifies settings of GLMR algorithm for customer life time value and life time survival analysis. |
|
|
Data Mining |
Specifies settings of K-Means algorithm for customer profiling. |
|
|
Data Mining |
Specifies settings of SVM algorithm for sentiment analysis. |
|
|
Data Mining |
Specifies storing parameter settings for mining. |
|
Reference |
Regulates traffic flow to an average bit rate, taking into account any bursting capability that is desired. Normally, a shaper service includes buffering. Thus, any packets that cannot be transmitted are queued. |
|
|
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 Resource). 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. |
|
|
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 PRODUCT SUBSCRIPTION. |
|
|
Lookup |
A reason why a SIM CARD is associated with a PRODUCT 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. |
|
|
Reference |
The part played by a SITE in a given context with any characteristics, such as expected pattern of behavior, attributes, and/or associations that it entails. |
|
|
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 |
Stock Keeping Unit or unit identification, typically the UPC, used to track store inventory and sales. Each SKU is associated with an item, variant, product line, bundle, service, fee, or attachment.
|
|
|
Lookup |
Lookup indicating which subtype the SKU ITEM is. For example:
|
|
|
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. |
|
|
Base |
Subtype of UDR EVENT, which collects all information of product usage of Short Message Service (SMS). |
|
|
Reference |
Subtype of PRODUCT OFFERING PRICE, reserved for Short Message Service (SMS), and also Multimedia Messaging Service (MMS), service. |
|
|
Reference |
Sub-type of SERVICE, containing the information relative to the SMS 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 RESOURCE. Thus, Software Commands represent the specific commands that are available in a device, whereas Capabilities represent higher-level generic functions available in a RESOURCE. 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 RESOURCE. Thus, Software Feature Sets represent groups of commands that are available in a device, whereas Capabilities represent higher-level generic functions available in a RESOURCE. 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. |
|
|
Lookup |
Lists the Special Numbers available to (or used by) customers. |
|
|
Reference |
Defines the relationship between a special number and a third Party Operator Numbers, with grouping attributes for reporting purpose. |
|
|
Reference |
Defines the most common type of marker, which sets existing bits in specific fields of a packet or frame. |
|
|
Reference |
Super entity to model statistics. Subtype of ROOT ENTITY. |
|
|
Aggregate |
Monthly summary of shop efficiency details including customer and transaction counts, wait times, and so on, by ORGANIZATION BUSINESS UNIT and GEOGRAPHY REGION. |
|
|
Derived |
Daily aggregate of shop efficiency details including customer and transaction counts, wait times, and so on, by ORGANIZATION BUSINESS UNIT and GEOGRAPHY REGION. |
|
|
Reference |
Names (and history) associated with GEOGRAPHY STREETs for address location. |
|
|
Reference |
Defines various segments of a street when necessary. Street Segment is a subtype of MARKET AREA. Is linked to a GEOGRAPHY STREET. |
|
|
Reference |
Association of ADDRESS LOCATION to specific Segment of a given Street. |
|
|
Reference |
This type of SCHEDULING SERVICE assigns each Queue a priority, and then visits each Queue in priority order. However, as long as a Queue of a higher priority has traffic enqueued, Queues of lower priority are starved. Subtype of SCHEDULING SERVICE. |
|
|
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 |
Defines the relationship between PRODUCT SUBSCRIPTION and the role a RESOURCE takes with respect to this subscription. |
|
|
Reference |
The relationship between PRODUCT 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 PRODUCT SUBSCRIPTION. |
|
|
Aggregate |
Monthly summary of Subscriber Churn by PRODUCT SPECIFICATION, PRODUCT OFFERING, CUSTOMER TYPE, GEOGRAPHY ENTITY, ORGANIZATION BUSINESS UNIT. |
|
|
Base |
Value assignments for Subscription Terms as pertains to a PRODUCT SUBSCRIPTION and PRODUCT SPECIFICATION. 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 an agreement. |
|
|
Lookup |
Lookup for type code and description of a Subsidy. |
|
|
Reference |
Supplementary Services are Add-on or Value Add services that are normally available but have to be explicitly triggered by the customer in any way to work. CLIP, CLIR, Conference Call, and so on, are typical Supplementary Services that runs on top of a normal call and should be charged in a particular way. |
|
|
Derived |
Daily summary of SUPPLEMENTARY SERVICE usage. This table can be customized to include more services. |
|
|
|
Aggregate |
Monthly aggregate of the SUPPLEMENTARY SERVICE usage. |
|
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 consider layer two information, such as bandwidth and QoS. Traditional routing protocols are designed to evaluate each frame's layer three header only. Several methods are available for accomplishing the task of looking at layer two 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. |
|
|
Lookup |
List of Symbology available (for representation on a map). |
|
|
Base |
UDR EVENTs invoked by our customer on partners network. Those events should be attached to the account for billing purposes. |
|
|
Base |
UDR 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 SPECIFICATION. |
|
|
Lookup |
Lookup for the types of Traffic Channel. For example:
|
|
|
Lookup |
Technology names and descriptions that can define a RESOURCE. For example:
|
|
|
Lookup |
Lookup for available type codes and descriptions that can classify or categorize a TECHNOLOGY. For example:
|
|
|
Reference |
The template for SERVICE LEVEL AGREEMENT spec. |
|
|
Reference |
Tender includes all the forms of payment that are accepted by the organization in settling sales and other transactions. |
|
|
Lookup |
A type of TENDER with common characteristics. |
|
|
Base |
A type of transaction that records the physical movement of tender from one TENDER repository to another. |
|
|
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 |
Type of Loyalty Tier Card. |
|
|
Reference |
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. |
|
|
Reference |
Represents the top most level of Time. This is needed to enable Ad-Hoc Reporting involving the Time Dimension. |
|
|
Lookup |
Lookup for the Geographic time zone as related to the Greenwich Mean Time (GMT +0.00). |
|
|
Derived |
Target entity to store the various TMF KPIs on a monthly level. Defines the TMF Business Metric Automation data exchange. |
|
|
Reference |
Information related to the TOKEN BUCKET and the SERVICE associated. |
|
|
Reference |
Defines semantics that specify how traffic is forwarded based on the value of the ToS byte of a packet. Subtype of QOS SERVICE. |
|
|
Base |
Tracking records allow the tracking of modifications on the Problem. The tracking records should not be embedded in the problem to allow retrieving the problem without the tracking records. |
|
|
Reference |
Defines an abstract base entity that is the parent for different types of traffic conditioning services defined in the DEN-ng Service model. TRAFFIC CONDITIONING SERVICEs control how packets and flows are treated compared to other packets and flows in the system. Please see the DEN-ng Service model for more details. |
|
|
Reference |
Defines the TRAFFIC IDENTIFICATION SERVICE; an abstract base entity that is the parent for different types of traffic identification services defined in the DEN-ng Service model. TRAFFIC IDENTIFICATION SERVICE are one example of a RESOURCE FACING SERVICE. TRAFFIC IDENTIFICATION SERVICEs control how packets and flows are identified and distinguished from other packets and flows in the system. Without these services, traffic conditioning cannot work.Please see the DEN-ng Service model for more details. |
|
|
Reference |
Define selection criteria for the CLASSIFIER SERVICE to use so that the CLASSIFIER SERVICE can separate ingress traffic into sets of flows. This entity contains data, metadata, and links to POLICY RULEs to govern the selection criteria. |
|
|
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. |
|
|
Lookup |
A code to denote the type of transaction. |
|
|
Lookup |
Further classifications of TRANSACTION CATEGORY. |
|
|
Lookup |
Code to indicate type of INVENTORY TRANFER. For example:
|
|
|
Base |
Subtype of BUSINESS INTERACTION. |
|
|
Base |
Specifies relationships between customer field support and the potential trouble tickets open associated to this support. |
|
|
Base |
Subtype of BUSINESS INTERACTION ITEM. |
|
|
Lookup |
Group of Trunks, for reporting or network management purpose. |
|
|
Reference |
Type of PRODUCT associating a Television Channel with a PTV USAGE EVENT. |
|
|
Base |
Abstracted event for all events that happened to the operator network because of customer usage; UDR EVENTs are usually the basis for customer billing. |
|
|
Base |
Defines the relationship between one UDR EVENT and another UDR EVENT. |
|
|
Reference |
A detailed description of an attribute that defines a particular type of UDR EVENT, described by its name, category, type, presence and a set of allowed values. Subtype of FLEXIBLE CHARACTERISTIC. |
|
|
|
Reference |
The relationship between network or UDR event characteristic, like aggregation, migration, substitution, dependency, or exclusivity. |
|
Lookup |
A category representing a high-level aspect of the UDR EVENT information described by the characteristic. Subtype of FLEXIBLE CHARACTERISTIC TYPE. |
|
|
Reference |
Subtype of FLEXIBLE CHARACTERISTIC VALUE. |
|
|
Reference |
Specifications associated with any Usage related Event (or UDR EVENT). |
|
|
Reference |
Specifies an attribute that defines a particular type of UDR EVENT, described by its name, category, type, presence and a set of allowed values. Subtype of FLEXIBLE CHARACTERISTIC. |
|
|
Reference |
Subtype of FLEXIBLE CHARACTERISTIC RELATIONSHIP. |
|
|
Reference |
The relationship between or among UDR EVENT SPECIFICATION CHARACTERISTIC VALUE, such as aggregation, migration, substitution, dependency, or exclusivity. Subtype of FLEXIBLE CHARACTERISTIC ASSIGNMENT. |
|
|
Reference |
Subtype of FLEXIBLE CHARACTERISTIC VALUE. |
|
|
Reference |
The relationship between or among UDR EVENT SPECIFICATION CHARACTERISTIC USEs, such as aggregation, migration, substitution, dependency, or exclusivity. Subtype of FLEXIBLE CHARACTERISTIC VALUE RELATIONSHIP. |
|
|
Reference |
A use of the Characteristic Value by a UDR EVENT to which additional properties, attributes, apply or override the properties of similar properties contained in UDR EVENT CHARACTERISTIC VALUE. Subtype of FLEXIBLE CHARACTERISTIC VALUE ASSIGNMENT. |
|
|
Reference |
Relationships,dependencies or exclusions, between various UDR EVENT SPECIFICATION. |
|
|
Lookup |
Determines whether a UDR EVENT SPECIFICATION is of type composite or Atomic. |
|
|
Reference |
Small variation of UDR EVENT SPECIFICATION that does not require the creation of an independent UDR EVENT SPECIFICATION. Typically, it could correspond to the evolution of the standard (like TAP file, or GSMA standard CDR definition). |
|
|
Lookup |
Lookup for possible status of UDR EVENTs. For example:
|
|
|
Lookup |
Lookup for available types of UDR EVENTs. |
|
|
Reference |
A particular form or variety of a UDR EVENT TYPE that is different from others or from the original. The form represents differences in properties that characterize a UDR EVENT TYPE, that are not enough to warrant creating a new UDR EVENT TYPE. |
|
|
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 UDR 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:
|
|
|
Base |
Describes the free unit allowance (for PREPAID or other products) given to the subscribers every month. The allowance could be SMS, MMS, Minutes, VAS Events, KB/MB, or even an option on the fly where you can have 2 mn or 4 SMS or 1 MMS (in this relationship ratio), whatever comes first. |
|
|
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. |
|
|
Lookup |
Specifies the type of usage of a specific service or UDR EVENT. In some billing systems, it may be an internal code that represents an attribute of a customer account, leveraged for rating a usage (for example, Friends and Family); |
|
|
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. |
|
|
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. |
|
|
Derived |
Monthly Aggregation of VALUE ADDED SERVICE Details by CUSTOMER and ACCESS METHOD. |
|
|
Aggregate |
Monthly Summary of VALUE ADDED SERVICE Details by CUSTOMER TYPE. |
|
|
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. |
|
|
Reference |
Time bound agreement with VENDOR. |
|
|
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 |
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 |
Defines any individual having an active session on the website of the Communication Service Provider (defined as Visitor). This visitor shall NOT be registered as customer (he/she does not login). |
|
|
Lookup |
Type of VISITOR depending on their behavior on the site. |
|
|
Derived |
Daily aggregate of Voice Call statistics by TIME SLOT, Business Unit, County, PRODUCT SPECIFICATION, CUSTOMER TYPE, Call Source, Call Destination, CALL DIRECTION, Call Success/Failure, Roaming Service. |
|
|
Aggregate |
Monthly Summary of Voice Call statistics by Business Unit, County, PRODUCT SPECIFICATION, CUSTOMER TYPE, CALL CATEGORY, CALL DIRECTION, Call Success/Failure. |
|
|
Reference |
Subtype of SERVICE. |
|
|
Base |
The subtype of UDR EVENT, specialized for Voice Over IP (VOIP) Calls. |
|
|
Lookup |
Characterizes UDR 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 UDR 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-44 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 website. 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 |
Defines all the Web Sites provided by or of interest to the Communications Service Providers. |
|
|
Reference |
List the website users, who are visitors that have registered (logged in). |
|
|
Reference |
Cumulative time transformations at the week level. |
|
|
Reference |
Time transformations at the week level. |
|
|
Reference |
Calendar weekdays. |
|
|
Reference |
Defines a cross between priority queuing and fair queuing, seeking to garner the best from both algorithms. All queues are serviced so that none are starved, but some queues are serviced more than others. A portion of the bandwidth of a DEVICE INTERFACE is allocated to each active flow. Subtype of FAIR QUEUING SERVICE. |
|
|
Reference |
Extension of algorithm to the standard ROUND ROBIN SCHEDULING SERVICE to allow to accommodate variable packet sizes. Subtype of ROUND ROBIN SCHEDULING SERVICE. |
|
|
Base |
Defines occurrence of wireless call. |
|
|
Base |
Type of UDR EVENT, to track wireless content downloading such as music, video clips, and so on. |
|
|
Reference |
Subtype of PRODUCT OFFERING PRICE, reserved for wireless voice and data services. |
|
|
Reference |
Resource hierarchy specifically associated to the wireless network for analytical purpose. Defines all geographical and network related information about each (important) Wireless Resources. |
|
|
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. |