Skip Headers

Oracle® Communications Data Model Reference 11g Release 2 (11.2) Part Number E15886-05 |
Home | Book List | Contents | Index | Contact Us

Previous | Next
| PDF · Mobi · ePub

# 2 Logical Data Model Foundation

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:

- Major Area Reference Entities

- Business Area Logical Entities

- Logical Data Model Entity Dictionary

## Major Area Reference Entities

The following are the major area reference logical data model entities:

- Account Simple Entity

- Customer Entity

- Dealer Entity

- Geography Entity

- Organization Business Unit Entity

- Party Entity

- Party Subject Area Entity

- Product Entity

- Product Instance Entity

- Service Entity

- Subscription Entity

- Time Calendar Entity

- Vendor Entity

- Wireless Network Entity

Note:

The major reference 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 at `https://support.oracle.com`.

### Account Simple Entity

Table 2-1 lists the Account Simple entities.

Table 2-1 Account Simple Reference Entity

Account Simple Entity List
ACCOUNT
ACCOUNT ASSIGNMENT
ACCOUNT ASSIGNMENT REASON
ACCOUNT PROFILE
ACCOUNT TYPE

### Customer Entity

Table 2-2 lists the Customer entities.

Table 2-2 Customer Reference Entity

Customer Entity List
ACCOUNT
ACCOUNT PAYMENT
ADDRESS LOCATION
ARPU BAND
BARING REASON
BLACK LIST HISTORY
CALENDAR MONTH
CONTRACT
CUSTOMER
CUSTOMER CLASS
CUSTOMER INDIVIDUAL
CUSTOMER MINING
CUSTOMER OCCASION
CUSTOMER OCCASION TYPE
CUSTOMER ORGANIZATION
CUSTOMER RESTRICTED INFO
CUSTOMER REVENUE BAND
CUSTOMER REVENUE BAND ASSIGNMENT
CUSTOMER REVENUE TYPE
CUSTOMER SCORE
CUSTOMER SEGMENT
CUSTOMER SEGMENTATION MODEL
CUSTOMER SIC ASSIGNMENT
CUSTOMER SOURCE
CUSTOMER TYPE
DERIVED VALUE
EDUCATION
EVENT PARTY INTERACTION
EXTERNAL ORGANIZATION TYPE
GENDER
HOUSEHOLD
INDIVIDUAL DEMOGRAPHY VALUE
INITIATIVE RESULT TYPE
INITIATIVE TYPE
INVOICE
JOB
LANGUAGE
MEDIA OBJECT
NATIONALITY
PARTY PROMOTION RESPONSE
PARTY STATUS HISTORY
PARTY STATUS HISTORY
PROMOTION
PROSPECT
PROSPECT INDIVIDUAL
PROSPECT ORGANIZATION
SEGMENT CRITERIA
SOC JOB
VALUE MEASURE
VALUE TYPE

### Dealer Entity

Table 2-3 lists the Dealer entities.

Table 2-3 Dealer Reference Entity

Dealer Entity List
CHANNEL
DEALER
DEALER DISCOUNT GROUP ASSIGNMENT
DISCOUNT GROUP
OTHER INDIVIDUAL
PARTY
SALES CHANNEL

### Geography Entity

Table 2-4 lists the Geography entities.

Table 2-4 Geography Reference Entity

Geography Entity List
ADDRESS LOCATION
ADDRESS RELATED
ADDRESS RELATED REASON
ADDRESS STATUS
ADDRESS STATUS REASON
ADDRESS TYPE
ACCOUNT TYPE
EMPLOYEE
GEOGRAPHY CITY
GEOGRAPHY COUNTRY
GEOGRAPHY COUNTY
GEOGRAPHY DEMOGRAPHIC GROUP
GEOGRAPHY DEMOGRAPHY ATTRIBUTE
GEOGRAPHY DEMOGRAPHY VALUE
GEOGRAPHY ENTITY
GEOGRAPHY HIERARCHY
GEOGRAPHY HIERARCHY LEVEL
GEOGRAPHY HIERARCHY LEVEL ASSIGNMENT
GEOGRAPHY LEVEL
GEOGRAPHY LEVEL ATTRIBUTE
GEOGRAPHY LEVEL ATTRIBUTE VALUE
GEOGRAPHY REGION
GEOGRAPHY STATE
GEOGRAPHY SUB REGION
GEOGRAPHY WORLD
PARTY ADDRESS LOCATION ASSIGNMENT
POSTCODE
TIME ZONE

### Organization Business Unit Entity

Table 2-5 lists the Organization Business Unit entities.

Table 2-5 Organization Reference Entity

Organization Entity List
ORGANIZATION AREA
ORGANIZATION BANNER
ORGANIZATION BUSINESS UNIT
ORGANIZATION CHAIN
ORGANIZATION COMPANY
ORGANIZATION CORPORATE
ORGANIZATION DISTRICT
ORGANIZATION DIVISION
ORGANIZATION REGION

### Party Entity

Table 2-6 lists the Party entities.

Table 2-6 Party Reference Entity

Party Entity List
ACCESS METHOD PARTY ASSIGNMENT
BLACK LIST HISTORY
BUSINESS LEGAL STATUS
CHANNEL
COST
CUSTOMER
CUSTOMER INDIVIDUAL
BUSINESS LEGAL STATUS
EVENT PARTY ASSIGNMENT
INDIVIDUAL DEMOGRAPHY VALUE
LANGUAGE
NATIONALITY
ORGANIZATION BUSINESS UNIT
ORGANIZATIONAL DEMOGRAPHY VALUE
PARTY
PARTY ACCOUNT ASSIGNMENT
PARTY ADDRESS LOCATION ASSIGNMENT
PARTY ASSIGNMENT
PARTY CONTACT INFORMATION
PARTY CONTACT LIST PARTICIPATION
PARTY COST ASSIGNMENT
PARTY GEOGRAPHY ENTITY ASSIGNMENT
PARTY IDENTIFICATION
PARTY INTERACTION THREAD
PARTY ORDER ASSIGNMENT
PARTY ROLE ASSIGNMENT
PARTY SIM CARD ASSIGNMENT
PARTY STATUS HISTORY
PARTY SUBSCRIPTION ASSIGNMENT
PARTY TYPE
SOURCE SYSTEM KEY MAPPING

### Party Subject Area Entity

Table 2-7 lists the Party Subject Area entities.

Table 2-7 Party Subject Area Reference Entity

Party Subject Area Entity List
ACCOUNT
ANZSIC CLASSIFICATION
BANK
BLACK LIST HISTORY
BUSINESS LEGAL STATUS
COLLECTION AGENCY
CONTACT ROLES
CONTENT PROVIDER
COST
COST CENTER
CUSTOMER
CUSTOMER OCCASION
CUSTOMER OCCASION TYPE
CUSTOMER SIC ASSIGNMENT
DEALER
DEMOGRAPHY ATTRIBUTE
DEMOGRAPHY GROUP
EMPLOYEE
EMPLOYEE JOB ROLE ASSIGNMENT
EVENT
EXTERNAL INFORMATION SOURCE
EXTERNAL OPERATOR
EXTERNAL ORGANIZATION TYPE
INDIVIDUAL DEMOGRAPHY VALUE
ISP
JOB ROLE
LANGUAGE
NAICS CLASSIFICATION
ORGANIZATION BUSINESS UNIT
PARTY
PARTY ADDRESS LOCATION ASSIGNMENT
PARTY ASSIGNMENT
PARTY ASSIGNMENT REASON
PARTY ASSIGNMENT TYPE
PARTY CONTACT INFORMATION
PARTY CONTACT INFORMATION TYPE
PARTY COST ASSIGNMENT
PARTY GEOGRAPHY ENTITY ASSIGNMENT
PARTY LOCATION REASON
PARTY LOYALTY PROGRAM PARTICIPATION
PARTY ROLE
PARTY ROLE ASSIGNMENT
PARTY ROLE STATUS
PARTY STATUS CATEGORY
PARTY STATUS CHANGE REASON
PARTY STATUS HISTORY
PARTY STATUS TYPE
PARTY TYPE
PROSPECT
SIC ASSIGNMENT
SIC ASSIGNMENT REASON
SIC CLASSIFICATION
SOURCE SYSTEM
SOURCE SYSTEM KEY MAPPING
VENDOR

### Product Entity

Table 2-8 lists the Product entities.

Table 2-8 Product Reference Entity

Product Entity List
ACCESSORIES
ADDITIONAL TEXT
ADDRESS LOCATION
BROADBAND
BROADBAND RATING PLAN
CABLE MODEM
CALL FORWARD
CALLER ID
CONTENT
DISCOUNT GROUP
DOCUMENT CONDITION TYPE
DOCUMENT TYPE
DSL MODEM
EQUIPMENT
EQUIPMENT FUNCTIONALITY
EQUIPMENT FUNCTIONALITY ASSIGNMENT
EQUIPMENT INSTANCE
EQUIPMENT INSTANCE STATUS HISTORY
EQUIPMENT INSTANCE STATUS TYPE
FIXED LINE
FIXED LINE RATING PLAN
GPRS SERVICE
HANDSET INSTANCE
HANDSET MODEL
IDD
ITEM
LANGUAGE
MARKET PLAN SUBSTITUTE BY DOC
MARKET PLAN TERM VALUE
MUSIC DOWNLOAD
NETWORK TOUCHPOINT
ORGANIZATION ITEM SELLING PRICE
PARTY
PAY TV
POSTPAID WIRELESS
PREPAID WIRELESS
PRODUCT
PRODUCT ASSIGNMENT
PRODUCT ASSIGNMENT REASON
PRODUCT CAPABILITY
PRODUCT CAPABILITY TYPE
PRODUCT CAPABILITY VALUE
PRODUCT CHARGE TYPE
PRODUCT CHARGE TYPE RELATIONSHIP
PRODUCT CHARGE TYPE RLTN REASON
PRODUCT CHARGING REASON
PRODUCT FEATURE
PRODUCT FEATURE ASSIGNMENT
PRODUCT FUNCTIONALITY DEPENDENCY
PRODUCT GEOGRAPHY ASSIGNMENT
PRODUCT GROUP
PRODUCT GROUP ASSIGNMENT
PRODUCT GROUP TYPE
PRODUCT INSTANCE
PRODUCT MANAGEMENT HISTORY
PRODUCT MANAGEMENT REASON
PRODUCT MANAGEMENT ROLE
PRODUCT MARKET PLAN
PRODUCT MARKET PLAN ASSIGNMENT
PRODUCT MARKET PLAN ASSIGNMENT TYPE
PRODUCT MARKET PLAN GEOGRAPHY ASSIGNMENT
PRODUCT MARKET PLAN GROUP
PRODUCT MARKET PLAN GROUP ASSIGNMENT
PRODUCT MARKET PLAN GROUP TYPE
PRODUCT MARKET PLAN TYPE
PRODUCT NETWORK ASSIGNMENT
PRODUCT PACKAGE
PRODUCT PACKAGE ASSIGNMENT
PRODUCT PACKAGE CHARGE TYPE
PRODUCT RATING PLAN
PRODUCT RATING PLAN DETAIL
PRODUCT RATING PLAN TYPE
PRODUCT STATUS HISTORY
PRODUCT STATUS TYPE
PRODUCT TYPE
PRODUCT VERSION
RATING METHOD TYPE
RINGTONE
SERVICE
SET TOP BOX
SET TOP BOX MODEL
SIM CARD HANDSET ASSIGNMENT
SMS RATING PLAN
SUPPLEMENTARY SERVICE
TV CHANNEL
VALUE ADDED SERVICE
VOICE MESSAGE SERVICE
WIRELESS RATING PLAN

### Product Instance Entity

Table 2-9 lists the Product Instance entities.

Table 2-9 Product Instance Reference Entity

Product Instance Entity List
ACCESS METHOD EQUIPMENT ASSIGNMENT
ADDRESS LOCATION
CABLE MODEM
CONTENT
CONTENT DELIVERY EVENT
CONTENT PRICE
CONTENT PRICING TYPE
CONTENT PROVIDER
CONTENT TYPE
CUSTOMER ORDER LINE ITEM
DSL MODEM
EQUIPMENT INSTANCE
EQUIPMENT INSTANCE RENTING CONTRACT
EQUIPMENT INSTANCE STATUS HISTORY
EVENT EQUIPMENT INSTANCE
HANDSET INSTANCE
NETWORK TOUCHPOINT
PARTY
PRODUCT
PRODUCT INSTANCE
SERVICE
SERVICE EQUIPMENT ASSIGNMENT
SET TOP BOX
SIM CARD HANDSET ASSIGNMENT
SUBSCRIPTION
VALUE ADDED SERVICE

### Service Entity

Table 2-10 lists the Service entities.

Table 2-10 Service Reference Entity

Service Entity List
BROADBAND
CONTENT
FIXED LINE
GPRS SERVICE
IDD
MUSIC DOWNLOAD
PAY TV
POSTPAID WIRELESS
PREPAID WIRELESS
SERVICE
VALUE ADDED SERVICE
VOICE MESSAGE SERVICE

### Subscription Entity

Table 2-11 lists the Subscription entities.

Table 2-11 Subscription Reference Entity

Subscription Entity List
ACCESS METHOD SUBSCRIPTION ASSIGNMENT
ACCOUNT
ACCOUNT CREDIT LIMIT
CAMPAIGN CHANNEL
CHANNEL
CONTRACT
CUSTOMER
EQUIPMENT INSTANCE
EQUIPMENT INSTANCE RENTING CONTRACT
EVENT SUBSCRIPTION CHANGE
HANDSET INSTANCE
ORGANIZATION BUSINESS UNIT
PARTY SUBSCRIPTION ASSIGNMENT
PARTY SUBSCRIPTION ROLE
PRODUCT
PRODUCT MARKET PLAN
SALES CHANNEL REPRESENTATIVE
SIM CARD SUBSCRIPTION ASSIGNMENT
SUBSCRIPTION
SUBSCRIPTION ASSIGNMENT
SUBSCRIPTION ASSIGNMENT TYPE
SUBSCRIPTION PMP ASSIGNMENT
SUBSCRIPTION STATUS
SUBSCRIPTION STATUS CATEGORY
SUBSCRIPTION STATUS HISTORY
SUBSCRIPTION STATUS REASON
SUBSCRIPTION TERM TYPE
SUBSCRIPTION TERM VALUE
SUBSCRIPTION TYPE
VAS SUBSCRIPTION

### Time Calendar Entity

Table 2-12 lists the Time Calendar entities.

Table 2-12 Time Calendar Entity

Time Calendar Entity List
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
DAY

### Vendor Entity

Table 2-13 lists the Vendor entities.

Table 2-13 Vendor Entity

Vendor Entity List
APPOINTMENT TYPE
DEAL
DEAL VENDOR ITEM ASSIGNMENT
FACTOR COMPANY
ORGANIZATION BUSINESS UNIT
VENDOR
VENDOR APPOINTMENT
VENDOR CLASS
VENDOR CONTRACT
VENDOR FACTOR COMPANY ASSIGNMENT
VENDOR RATING
VENDOR SITE
VENDOR SITE COURIER ASSIGNMENT

### Wireless Network Entity

Table 2-14 lists the Wireless Network entities.

Table 2-14 Wireless Network Entity

Wireless Network Entity List
ADDRESS LOCATION
BASE STATION CONTROLLER
BASE TRANSCEIVER STATION
CELL
CELL SECTOR
CELL SITE
CELL SITE TYPE
CELL TYPE
CIRCUIT CATEGORY
CIRCUIT COMPONENT
CIRCUIT TRAFFIC
CIRCUIT TYPE
EQUIPMENT CENTER
EXTERNAL OPERATOR
IN PLATFORM
MOBILE SWITCHING CENTER
NETWORK
NETWORK SERVICE COVERAGE ASSIGNMENT
NETWORK TOUCHPOINT
NETWORK TOUCHPOINT CLASS
NETWORK TOUCHPOINT TYPE
NETWORK TYPE
PARTY
RF CARRIER
ROUTING DEVICE
SERVICE COVERAGE AREA
SERVICE COVERAGE AREA TYPE
SERVICE COVERAGE GEO DETAIL
SWITCH
SWITCH CAPABILITY
SWITCH CAPABILITY TYPE
SWITCH ROUTING DEVICE ASSIGNMENT
SWITCH TYPE
TECHNOLOGY
TECHNOLOGY TYPE

## Business Area Logical Entities

The following are the business area logical data model entities:

- Cost Business Area Logical Entity

- Customer Management Business Area Logical Entity

- Marketing Business Area Logical Entity

- Network Business Area Logical Entity

- Partner Management Business Area Logical Entity

- Product Management Business Area Logical Entity

- Provisioning and Service Business Area Logical Entity

- Revenue Business Area Logical Entity

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 at `https://support.oracle.com`.

### Cost Business Area Logical Entity

Table 2-15 lists the Cost entities.

Table 2-15 Cost Business Area Logical Entities

Cost Entity List
ACCOUNT COST
BUSINESS HALF MONTH
BUSINESS HALF YEAR
BUSINESS MONTH
BUSINESS QUARTER
BUSINESS WEEK
BUSINESS YEAR
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
CAMPAIGN COST
COURIER COST
CELL SITE COST
CHANNEL COST
CONTACT LIST COST
COST
COST CENTER BUDGET
COST REASON
COST SUBTYPE
COST TYPE
CUSTOMER
CUSTOMER CLASS
CUSTOMER CLASS ASSIGNMENT
CUSTOMER COST
CUSTOMER SCORE
CUSTOMER SEGMENT
CUSTOMER SOURCE
CUSTOMER TYPE
DAY
EMPLOYEE ACTUAL LABOR HOURLY
EMPLOYEE ACTUAL LABOR SALARIED
EMPLOYEE COST
EMPLOYEE TYPE
EQUIPMENT
EQUIPMENT CENTER COST
EVENT COST
EVENT EMPLOYEE PAYROLL
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
HANDSET MODEL
INVOICE PAYMENT ASSIGNMENT
MEDIA OBJECT COST
NETWORK ELEMENT COST
ORGANIZATION AREA
ORGANIZATION BANNER
ORGANIZATION BUSINESS UNIT
ORGANIZATION BUSINESS UNIT COST
ORGANIZATION CHAIN
ORGANIZATION COMPANY
ORGANIZATION CORPORATE
ORGANIZATION DISTRICT
ORGANIZATION DIVISION
ORGANIZATION REGION
ORGANIZATION WAREHOUSE
PARTY ORDER ASSIGNMENT
PAY CATEGORY
PAY TYPE
PLANNING PERIOD
PLANNING QUARTER
PLANNING SEASON
PLANNING WEEK
PLANNING YEAR
PRODUCT
PRODUCT COST
PRODUCT MARKET PLAN COST
PRODUCT PACKAGE
PRODUCT TYPE
PROMOTION COST
SALES CHANNEL
SELLING LOCATION TYPE
SUBSIDY TYPE
TIME SLOT
TIME STANDARD BY DAY
TIME STANDARD BY WEEK

### Customer Management Business Area Logical Entity

Table 2-16 lists the Customer Management entities.

Table 2-16 Customer Management Business Area Logical Entities

Customer Management Entity List
ACCESS METHOD ACCOUNT ASSIGNMENT
ACCESS METHOD ASSIGNMENT
ACCESS METHOD ELEMENT
ACCESS METHOD EQUIPMENT ASSIGNMENT
ACCESS METHOD GEOGRAPHY ASSIGNMENT
ACCESS METHOD PARTY ASSIGNMENT
ACCESS METHOD POOL
ACCESS METHOD SEGMENT
ACCESS METHOD STATUS HISTORY
ACCESS METHOD SEGMENT PROD CAPABILITY RL
ACCESS METHOD SUBSCRIPTION ASSIGNMENT
ACCESS METHOD TYPE
ACCOUNT ADJUSTMENT REASON
ACCOUNT ASSIGNMENT
ACCOUNT ASSIGNMENT REASON
ACCOUNT BALANCE ADJUSTMENT
ACCOUNT BALANCE ADJUSTMENT TYPE
ACCOUNT BALANCE HISTORY
ACCOUNT BALANCE TYPE
ACCOUNT BILLING CYCLE HISTORY
ACCOUNT BILLING FREQUENCY HISTORY
ACCOUNT BILLING PERIOD HISTORY
ACCOUNT CONTRACT RELATIONSHIP
ACCOUNT CREDIT LIMIT
ACCOUNT DEBT WRITE OFF
ACCOUNT EVENT TYPE
ACCOUNT MANAGEMENT HISTORY
ACCOUNT PARTY PMP RELATIONSHIP
ACCOUNT PAYMENT METHOD STATUS
ACCOUNT PAYMENT METHOD STATUS REASON
ACCOUNT PAYMENT METHOD STATUS TYPE
ACCOUNT PMP PARTICIPATION HISTORY
ACCOUNT PREFERRED INVOICE DELIVERY
ACCOUNT PROFILE
ACCOUNT REFUND REASON
ACCOUNT SEGMENT
ACCOUNT SEGMENT ASSIGNMENT HISTORY
ACCOUNT SEGMENTATION MODEL
ACCOUNT STATUS HISTORY
ACCOUNT STATUS REASON
ACCOUNT STATUS TYPE
ACCOUNT SUBSCRIPTION ASSIGNMENT
ACCOUNT SUBSCRIPTION ASSIGNMENT REASON
ACCOUNT TYPE
ACCOUNTING CYCLE
ACCOUNTING ITEM CATEGORY
ADDRESS LOCATION
ADDRESS RELATED
ADDRESS STATUS
AGE BAND
AGE ON NET BAND
ARPU BAND
AWARD LEVEL
BANK
BANK DIRECT DEBIT CHANNEL
BARING REASON
BILLING CYCLE
BILLING FREQUENCY
BILLING PERIOD
BILLING STATUS CATEGORY
BILLING STATUS TYPE
BLACK LIST HISTORY
BUSINESS HALF MONTH
BUSINESS HALF YEAR
BUSINESS MONTH
BUSINESS QUARTER
BUSINESS UNIT JOB ROLE
BUSINESS UNIT SHIFT
BUSINESS WEEK
BUSINESS YEAR
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
CALL CENTER AGENT
CALL CENTER AGENT TYPE
CALL CENTER CASE SUB TYPE
CALL CENTER CASE TITLE
CALL CENTER CASE TYPE
CALL CENTER SERVICE CAPABILITY
CHANGE PROPOSED BY TYPE
CHURN PREDICT SOURCE DERIVED
CHURN REASON
CONTRACT
CONTRACT APPROVAL
CONTRACT ASSIGNMENT
CONTRACT ASSIGNMENT REASON
CONTRACT ASSIGNMENT TYPE
CONTRACT CHANGE INITIATOR TYPE
CONTRACT CHANGE TYPE
CONTRACT DOCUMENT
CONTRACT PRODUCT ASSIGNMENT
CONTRACT STATUS
CONTRACT STATUS TYPE
CONTRACT TERM TYPE
CREDIT CATEGORY
CURRENCY GEOGRAPHY ENTITY ASSIGNMENT
CUSTOMER
CUSTOMER CLASS
CUSTOMER CLASS ASSIGNMENT
CUSTOMER COST
CUSTOMER FIELD INSTALLATION
CUSTOMER FIELD SERVICE ACTIVITY
CUSTOMER FIELD SERVICE DETAIL
CUSTOMER FIELD SUPPORT
CUSTOMER INDIVIDUAL
CUSTOMER OCCASION
CUSTOMER OCCASION TYPE
CUSTOMER ORDER
CUSTOMER ORDER LINE ITEM
CUSTOMER ORDER LINE ITEM STATE ASSIGN
CUSTOMER ORDER PAYMENT
CUSTOMER ORDER STATE ASSIGNMENT
CUSTOMER ORGANIZATION
CUSTOMER RESTRICTED INFO
CUSTOMER REVENUE BAND
CUSTOMER REVENUE BAND ASSIGNMENT
CUSTOMER REVENUE TYPE
CUSTOMER SCORE
CUSTOMER SEGMENT
CUSTOMER SEGMENTATION MODEL
CUSTOMER SIC ASSIGNMENT
CUSTOMER SOURCE
CUSTOMER TYPE
DATA SERVICE EVENT
DAY
DAY ACTUAL CONDITION
DAY TODATE TRANSFORMATION
DAY TRANSFORMATION
DEBT AGING BAND
DERIVED VALUE
EDUCATION
EMPLOYEE
EMPLOYEE DESIGNATION
EMPLOYEE DISCOUNT GROUP ASSIGNMENT
EMPLOYEE JOB ROLE ASSIGNMENT
EMPLOYEE JOB ROLE TYPE
EMPLOYEE DESIGNATION
EMPLOYEE RESTRICTED INFO
EMPLOYEE SCHEDULE
EMPLOYEE TRAINING RECORD
EMPLOYEE TYPE
EQUIPMENT
EQUIPMENT INSTANCE RENTING CONTRACT
EVENT ACCOUNT
EVENT GEOGRAPHY
EVENT LOCATION
EVENT PARTY INTERACTION
EVENT PARTY INTERACTION CALL
EVENT PARTY INTERACTION EMAIL
EVENT PARTY INTERACTION VISIT
EVENT PARTY PROFILE
EVENT PARTY ROLE
EVENT RESOLUTION
EXTERNAL INFORMATION SOURCE
EXTERNAL ORGANIZATION TYPE
FACTOR COMPANY
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
FRAUD PROFILE CLASS
GENDER
GEOGRAPHY CITY
GEOGRAPHY COUNTRY
GEOGRAPHY COUNTY
GEOGRAPHY DEMOGRAPHIC GROUP
GEOGRAPHY DEMOGRAPHY ATTRIBUTE
GEOGRAPHY DEMOGRAPHY VALUE
GEOGRAPHY ENTITY
GEOGRAPHY ENTITY ASSIGNMENT
GEOGRAPHY ENTITY HIER LEVEL ASSIGNMENT
GEOGRAPHY HIERARCHY
GEOGRAPHY HIERARCHY LEVEL
GEOGRAPHY HIERARCHY LEVEL ASSIGNMENT
GEOGRAPHY LEVEL
GEOGRAPHY LEVEL ATTRIBUTE
GEOGRAPHY LEVEL ATTRIBUTE VALUE
GEOGRAPHY REGION
GEOGRAPHY STATE
GEOGRAPHY SUB REGION
GEOGRAPHY WORLD
GPRS SERVICE
HALF HOUR
HALF MONTH TODATE TRANSFORMATION
HALF MONTH TRANSFORMATION
HALF YEAR TODATE TRANSFORMATION
HALF YEAR TRANSFORMATION
HOUR
HOUSEHOLD
INITIATIVE RESULT TYPE
INITIATIVE TYPE
INTERACTION ANSWER CHOICE
INTERACTION CHANNEL
INTERACTION DIRECTION
INTERACTION QUESTION RESPONSE
INTERACTION REASON
INTERACTION RESULT TYPE
INTERACTION STATUS
INTERACTION TYPE
INVOICE
IP ADDRESS POOL
JOB
JOB ROLE
LANGUAGE
LEGAL PROCESS STATUS TYPE
LETTER TYPE
MAILBOX
MANAGE ACTION TYPE
MARITAL STATUS
MEDIA OBJECT
MUSIC DOWNLOAD
NAICS INDUSTRY SUBSECTOR
NATIONALITY
NP MOBILE MSISDN
NP REQUEST HEADER
NP REQUEST LINE ITEM
NP REQUEST LINE ITEM STATE HISTORY
NP REQUEST LINE ITEM STATE TYPE
NP REQUEST STATE HISTORY
NP REQUEST STATE TYPE
NP REQUEST TYPE
NP STEP
NUMBER AREA
NUMBER COUNTRY
ORDER LINE ITEM STATE
ORDER LINE ITEM STATE
ORDER STATUS
ORDER TYPE
ORGANIZATION AREA
ORGANIZATION BANNER
ORGANIZATION BUSINESS UNIT
ORGANIZATION CHAIN
ORGANIZATION COMPANY
ORGANIZATION CORPORATE
ORGANIZATION DISTRICT
ORGANIZATION DIVISION
ORGANIZATION REGION
OTHER INDIVIDUAL
PARTY ACCOUNT ASSIGNMENT
PARTY ACCOUNT ASSIGNMENT TYPE
PARTY ADDRESS LOCATION ASSIGNMENT
PARTY ASSIGNMENT
PARTY CONTACT INFORMATION
PARTY CONTACT LIST ROLE
PARTY CONTRACT ASSIGNMENT
PARTY CONTRACT ASSIGNMENT ROLE
PARTY CONTRACT ASSIGNMENT TYPE
PARTY EVENT TYPE
PARTY GEOGRAPHY ENTITY ASSIGNMENT
PARTY IDENTIFICATION
PARTY IDENTIFICATION TYPE
PARTY ORDER ASSIGNMENT TYPE
PARTY PROMOTION RESPONSE
PARTY ROLE ASSIGNMENT
PARTY ROLE STATUS
PARTY SEGMENTATION METHOD
PARTY SIM CARD ASSIGNMENT
PARTY STATUS CHANGE REASON
PARTY STATUS HISTORY
PARTY SUBSCRIPTION ASSIGNMENT
PAYMENT CHANNEL
PERIOD TO DATE TRANSFORMATION
PERIOD TRANSFORMATION
POSTAL SERVICE TYPE
POSTCODE
POSTPAID WIRELESS
PREPAID WIRELESS
PRICE DERIVATION RULE
PRODUCT
PRODUCT PACKAGE
PRODUCT TYPE
PROMOTION
PROMOTION RESULT TYPE
PROMOTION TERM TYPE
PROSPECT
PROSPECT INDIVIDUAL
PROSPECT ORGANIZATION
PTV FULL CHANNEL ACTIVATION
PUBLICATION TYPE
QUARTER HOUR
QUARTER TO DATE TRANSFORMATION
QUARTER TRANSFORMATION
REDEMPTION TYPE
RINGTONE
ROLES HIERARCHY
SCRIPT
SCRIPT QUESTION
SCRIPT QUESTION TYPE
SEASON
SECOND
SEGMENT CRITERIA
SEGMENT TYPE
SERVICE REQUEST
SIC ASSIGNMENT
SIC DIVISION
SIC INDUSTRY GROUP
SIM CARD SUBSCRIPTION REASON
SOC JOB
SOC JOB CATEGORY
SOC JOB GROUP
SOC JOB MAJOR GROUP
SOURCE SYSTEM
SOURCE SYSTEM KEY MAPPING
SUBSCRIBER ACTIVATION REASON
TAX EXEMPT
TIME SLOT
TIME STANDARD BY DAY
TIME STANDARD BY WEEK
USER
VALUE MEASURE
VALUE TYPE
VENDOR FACTOR COMPANY ASSIGNMENT
VIRTUAL TEAM
WEATHER CONDITION
WEEK TODATE TRANSFORMATION
WEEK TRANSFORMATION
YEAR TRANSFORMATION

### Marketing Business Area Logical Entity

Table 2-17 lists the Marketing entities.

Table 2-17 Marketing Business Area Logical Entity

Marketing Entity List
ACCOUNT PMP PARTICIPATION HISTORY
ADVERTISING PERIOD
ADVERTISING QUARTER
ADVERTISING WEEK
ADVERTISING YEAR
AWARD LEVEL
BUSINESS HALF MONTH
BUSINESS HALF YEAR
BUSINESS MONTH
BUSINESS QUARTER
BUSINESS WEEK
BUSINESS YEAR
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
CAMPAIGN
CAMPAIGN CHANNEL
CAMPAIGN CHANNEL TYPE
CAMPAIGN MANAGEMENT HISTORY
CAMPAIGN MESSAGE
CAMPAIGN MESSAGE CREATIVE
CAMPAIGN MESSAGE DEPICTION
CAMPAIGN PURPOSE TYPE
CAMPAIGN STATUS
CAMPAIGN TYPE
CONTACT LIST
CONTACT LIST CHANGE REASON
CONTACT LIST RECURRENCE TYPE
COST
DAY
DEMOGRAPHY ATTRIBUTE
DEMOGRAPHY GROUP
DSL MODEM
EMPLOYEE DESIGNATION
EMPLOYEE JOB ROLE TYPE
EMPLOYEE TYPE
EQUIPMENT
EVENT GIFT REDEMPTION
EVENT LOCATION
EVENT RESPONSE REASON
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
GEOGRAPHY LEVEL ATTRIBUTE
INDIVIDUAL DEMOGRAPHY PROFILE
INDIVIDUAL DEMOGRAPHY VALUE
INITIATIVE TYPE
INTERACTION DIRECTION
INTERACTION REASON
INTERACTION RESULT TYPE
INTERACTION STATUS
INTERACTION TYPE
LETTER TYPE
LOYALTY PROGRAM PARTY ROLE
MANAGE ACTION TYPE
MARKET AREA
MARKET AREA LEVEL
MARKET PLAN MANAGEMENT
MARKET PLAN SUBSTITUTE BY DOC
MARKET PLAN TERM VALUE
MEDIA OBJECT
MEDIA OBJECT ASSIGNMENT
MINUTE ALLOWANCE
ORGANIZATION AREA
ORGANIZATION BANNER
ORGANIZATION BUSINESS UNIT
ORGANIZATION CHAIN
ORGANIZATION COMPANY
ORGANIZATION CORPORATE
ORGANIZATION DISTRICT
ORGANIZATION DIVISION
ORGANIZATION REGION
PARTNER PROMOTION PROGRAM
PARTY CONTACT LIST PARTICIPATION
PARTY CONTACT LIST ROLE
PARTY GEOGRAPHY ENTITY ASSIGNMENT
PARTY MANAGEMENT ROLE
PRODUCT
PRODUCT MARKET PLAN
PRODUCT PACKAGE
PRODUCT TYPE
PROMOTION
PROMOTION CLUSTER USAGE
PROMOTION CONTACT LIST UTILIZATION
PROMOTION MANAGEMENT HISTORY
PROMOTION MARKET PLAN ASSIGNMENT
PROMOTION MESSAGE RENDERING
PROMOTION RESULT TYPE
PROMOTION TERM VALUE
PUBLICATION
PUBLICATION TYPE
RETAIL STORE
SCRIPT QUESTION TYPE
SEASON
SELLING LOCATION
SOURCE SYSTEM TYPE
TARGET ACCESS METHOD
TARGET ACCOUNT
TARGET CONTRACT
TARGET GEOGRAPHY AREA
TARGET TYPE
TIME SLOT
TIME STANDARD BY DAY
TIME STANDARD BY WEEK
WEATHER CONDITION
WEEK TODATE TRANSFORMATION
WEEK TRANSFORMATION
WEEKDAY
YEAR TRANSFORMATION

### Network Business Area Logical Entity

Table 2-18 lists the Network entities.

Table 2-18 Network Business Area Logical Entity

Network Entity List
ACCOUNT BALANCE ADJUSTMENT
ADDRESS LOCATION
ANZSIC CLASSIFICATION
BASE STATION CONTROLLER
BASE TRANSCEIVER STATION
BER FER TYPE
BROADBAND
BROADBAND RATING PLAN
BROADBAND USAGE EVENT
BUSINESS HALF MONTH
BUSINESS HALF YEAR
BUSINESS MONTH
BUSINESS QUARTER
BUSINESS WEEK
BUSINESS YEAR
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
CALL DIRECTION
CALL FORWARD
CALL OTHER TYPE
CALL RECYCLED REASON
CALL SUCCESS FAILURE TYPE
CALL SURCHARGE
CALL TERMINATION REASON
CELL
CELL OUTAGE REASON
CELL SITE
CELL SITE TYPE
CELL TYPE
CIRCUIT CATEGORY
CIRCUIT COMPONENT
CIRCUIT RENTAL
CIRCUIT RENTAL EVENT TYPE
CIRCUIT TRAFFIC
CIRCUIT TYPE
CONTENT DELIVERY EVENT
DAY
DESTINATION TYPE
DISTANCE BAND
DIVERT RETRIEVE REASON
DIVERT RETRIEVE TYPE
EQUIPMENT CENTER
EVENT
EVENT ACCESS METHOD ACTIVITY
EVENT ASSIGNMENT
EVENT ASSIGNMENT REASON
EVENT ASSIGNMENT TYPE
EVENT CATEGORY
EVENT CIRCUIT RENTAL
EVENT CLASS
EVENT GEOGRAPHY
EVENT PARTY INTERACTION EMAIL
EVENT PARTY INTERACTION LETTER
EVENT PARTY INTERACTION VISIT
EVENT PREPAID MOBILE
EVENT PRODUCT PACKAGE
EVENT STATUS
EVENT SUBSCRIPTION
EVENT SUBSCRIPTION CHANGE
EVENT WEB REGISTRATION
EXTERNAL OPERATOR
FAULT RESOLUTION TYPE
FAULT TYPE
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
FIXED LINE CALL EVENT
FIXED LINE PORT
GEOGRAPHY CITY
GEOGRAPHY COUNTRY
GEOGRAPHY REGION
GEOGRAPHY STATE
GEOGRAPHY SUB REGION
GEOGRAPHY WORLD
IDD CALL EVENT
IN PLATFORM
INTERACTION DIRECTION
INTERACTION REASON
INTERACTION RESULT TYPE
INTERACTION STATUS
INTERACTION TYPE
INTERNET ACCESS EVENT
LETTER TYPE
LOYALTY PROGRAM
MEDIATED CALL EVENT
MMS EVENT
MOBILE SWITCHING CENTER
MONTH TODATE TRANSFORMATION
MONTH TRANSFORMATION
NETWORK
NETWORK ELEMENT
NETWORK ELEMENT COST
NETWORK EVENT
NETWORK EVENT STATUS
NETWORK EVENT TYPE
NETWORK FAULT
NETWORK SERVICE COVERAGE ASSIGNMENT
NETWORK TOUCHPOINT
NETWORK TOUCHPOINT CLASS
NETWORK TOUCHPOINT STATUS
NETWORK TOUCHPOINT TYPE
NETWORK TYPE
NOTIFICATION TYPE
NUMBER NETWORK TYPE
ON OFF NET TYPE
PARTY
PARTY INTERACTION THREAD
PCU OUTAGE REASON
PEAK OFFPEAK TIME
PREPAID MOBILE EVENT TYPE
PROMOTION RESULT TYPE
PROMOTION TERM TYPE
PTV QPI SERVICE EVENT
PUBLICATION TYPE
RETAIL STORE
RF CARRIER
ROUTING DEVICE
SCRIPT QUESTION TYPE
SEASON
SERVICE CLASS
SERVICE CLASS TYPE
SERVICE COVERAGE AREA
SERVICE COVERAGE AREA TYPE
SERVICE COVERAGE GEO DETAIL
SERVICE EQUIPMENT ASSIGNMENT
SERVICE REQUEST
SMS EVENT
SWITCH
SWITCH CAPABILITY
SWITCH CAPABILITY TYPE
SWITCH COMMAND
SWITCH ROUTING DEVICE ASSIGNMENT
SWITCH TYPE
TCH TYPE
TECHNOLOGY
TECHNOLOGY TYPE
TELEPHONE NUMBER POOL
TIME BAND
TIME SLOT
TIME STANDARD BY DAY
TIME STANDARD BY WEEK
UMS ACCESS TYPE
UMS EVENT
VAS SUBSCRIPTION
VOIP CALL EVENT
VOLUME BAND
WIRELESS CALL EVENT
WIRELESS CONTENT DOWNLOADING EVENT
WIRELESS NETWORK ELEMENT
YEAR TRANSFORMATION

### Partner Management Business Area Logical Entity

Table 2-19 lists the Partner Management entities.

Table 2-19 Partner Management Business Area Logical Entity

Partner Management Entity List
ACCESS METHOD PORTING HISTORY
APPOINTMENT TYPE
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
COLLECTION AGENCY
CONTENT
CONTENT PRICE
CONTENT PRICING TYPE
CONTENT PROVIDER
CONTENT TYPE
DEAL
DEAL VENDOR ITEM ASSIGNMENT
DEALER
DEALER DISCOUNT GROUP ASSIGNMENT
DISCOUNT GROUP
EVENT PARTY ASSIGNMENT
EVENT PARTY PROFILE
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
ISP
ISP BUSINESS
ISP BUSINESS ASSIGNMENT
ISP BUSINESS TYPE
ISP TYPE
ISP USER
NP REQUEST LINE ITEM STATE TYPE
NP REQUEST STATE TYPE
NP REQUEST TYPE
NP STEP
OPERATOR GROUP
OPERATOR TYPE
ORGANIZATION BUSINESS UNIT
PARTNER SETTLEMENT REASON
PARTY
PARTY EVENT TYPE
PARTY IDENTIFICATION
PARTY ORDER ASSIGNMENT TYPE
PROMOTION
SIC INDUSTRY GROUP
TIME SLOT
TIME STANDARD BY DAY
TIME STANDARD BY WEEK
VENDOR
VENDOR APPOINTMENT
VENDOR CLASS
VENDOR CONTRACT
VENDOR RATING
VENDOR RATING TYPE
VENDOR SITE
VENDOR SITE COURIER ASSIGNMENT
VENDOR SITE TYPE

### Product Management Business Area Logical Entity

Table 2-20 lists the Product Management entities.

Table 2-20 Product Management Business Area Logical Entity

Product Management Entity List
ACCESSORIES
ADDITIONAL TEXT
BRAND
BROADBAND RATING PLAN
BUSINESS HALF MONTH
BUSINESS HALF YEAR
BUSINESS MONTH
BUSINESS QUARTER
CABLE MODEM
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
CALLER ID
CELL
CELL SECTOR
CELL SITE
CHANGE PROPOSED BY TYPE
CHANNEL
CHANNEL TYPE
CONTENT
DISCOUNT GROUP
DOCUMENT CONDITION TYPE
DOCUMENT TYPE
EQUIPMENT
EQUIPMENT FUNCTIONALITY
EQUIPMENT FUNCTIONALITY ASSIGNMENT
EQUIPMENT INSTANCE
EQUIPMENT INSTANCE STATUS HISTORY
EQUIPMENT INSTANCE STATUS TYPE
EVENT PRODUCT PACKAGE
EVENT SIM CARD
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
FIXED LINE
FIXED LINE RATING PLAN
GIVE AWAY TYPE
HANDSET INSTANCE
HANDSET MODEL
IDD
ITEM
ITEM TYPE
LANGUAGE
MARKET PLAN SUBSTITUTE BY DOC
MARKET PLAN TERM VALUE
MINUTE
MMS
MODEL TYPE
NAICS CLASSIFICATION
NAICS INDUSTRY
NAICS INDUSTRY GROUP
NAICS INDUSTRY SECTOR
NAICS INDUSTRY SUBSECTOR
NETWORK TOUCHPOINT
ORGANIZATION BUSINESS UNIT
ORGANIZATION ITEM SELLING PRICE
ORGANIZATION WAREHOUSE
PARTY
PAY TV
PPA CATEGORY
PPA DEDUCTION TYPE
PREPAID VOUCHER INSTANCE
PREPAID WIRELESS
PRODUCT
PRODUCT ADDITIONAL TEXT
PRODUCT ASSIGNMENT
PRODUCT ASSIGNMENT REASON
PRODUCT CAPABILITY
PRODUCT CAPABILITY TYPE
PRODUCT CAPABILITY VALUE
PRODUCT CHARGE TYPE
PRODUCT CHARGE TYPE RELATIONSHIP
PRODUCT CHARGE TYPE RLTN REASON
PRODUCT CHARGING REASON
PRODUCT FEATURE
PRODUCT FEATURE ASSIGNMENT
PRODUCT FUNCTIONALITY DEPENDENCY
PRODUCT GEOGRAPHY ASSIGNMENT
PRODUCT GROUP
PRODUCT GROUP ASSIGNMENT
PRODUCT GROUP TYPE
PRODUCT INSTANCE
PRODUCT MANAGEMENT HISTORY
PRODUCT MANAGEMENT REASON
PRODUCT MANAGEMENT ROLE
PRODUCT MARKET PLAN
PRODUCT MARKET PLAN ASSIGNMENT
PRODUCT MARKET PLAN ASSIGNMENT TYPE
PRODUCT MARKET PLAN GEOGRAPHY ASSIGNMENT
PRODUCT MARKET PLAN GROUP
PRODUCT MARKET PLAN GROUP ASSIGNMENT
PRODUCT MARKET PLAN GROUP TYPE
PRODUCT MARKET PLAN TYPE
PRODUCT NETWORK ASSIGNMENT
PRODUCT PACKAGE
PRODUCT PACKAGE ASSIGNMENT
PRODUCT PACKAGE CHARGE TYPE
PRODUCT RATING PLAN DETAIL
PRODUCT RATING PLAN TYPE
PRODUCT STATUS HISTORY
PRODUCT STATUS TYPE
PRODUCT TYPE
PRODUCT VERSION
RATING METHOD TYPE
SECURITY REQUIRED TYPE
SERVICE
SERVICE CLASS
SERVICE CLASS TYPE
SET TOP BOX
SET TOP BOX MODEL
SIM CARD
SIM CARD ACCESS METHOD ASSIGNMENT
SIM CARD HANDSET ASSIGNMENT
SIM CARD SUBSCRIPTION ASSIGNMENT
SMS
SMS RATING PLAN
SUPPLEMENTARY SERVICE
TIME BAND
TIME SLOT
TIME STANDARD BY WEEK
TV CHANNEL
VALUE ADDED SERVICE
WIRELESS RATING PLAN
YEAR TRANSFORMATION

### Provisioning and Service Business Area Logical Entity

Table 2-21 lists the Provisioning and Service entities.

Table 2-21 Provisioning and Service Business Area Logical Entity

Provisioning and Service Entity List
ACCESS METHOD
ACCESS METHOD ASSIGNMENT TYPE
ACCESS METHOD ELEMENT TYPE
ACCESS METHOD PARTY ASSIGNMENT
ACCESS METHOD STATUS REASON
ACCESS METHOD STATUS TYPE
ACCESS METHOD TYPE
ACCOUNT
ADDRESS LOCATION
APPOINTMENT CALENDAR
BLACK LIST HISTORY
BUSINESS HALF MONTH
BUSINESS HALF YEAR
BUSINESS MONTH
BUSINESS QUARTER
BUSINESS WEEK
BUSINESS YEAR
CALENDAR HALF MONTH
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
CALL CATEGORY
CALL CENTER
CALL CENTER AGENT TYPE
CALL CENTER CASE SUB TYPE
CALL CENTER CASE TITLE
CALL CENTER CASE TYPE
CALL FORWARD
CALL ROUTING TYPE
CALL SOURCE DESTINATION
CALL TYPE
CHANGE PROPOSED BY TYPE
CONTRACT
CONTRACT TERM VALUE
COURIER
COURIER COST
CUSTOMER
CUSTOMER CLASS
CUSTOMER CLASS ASSIGNMENT
CUSTOMER ORDER
CUSTOMER SCORE
CUSTOMER SEGMENT
CUSTOMER SOURCE
CUSTOMER TYPE
DAY
EQUIPMENT
EVENT ASSIGNMENT REASON
EVENT ASSIGNMENT TYPE
EVENT CATEGORY
EVENT GEOGRAPHY
EVENT RESPONSE REASON
FIELD ACTIVITY RESULT TYPE
FIELD ACTIVITY TYPE
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
GEOGRAPHY CITY
GEOGRAPHY COUNTY
GEOGRAPHY REGION
GEOGRAPHY STATE
GEOGRAPHY SUB REGION
GEOGRAPHY WORLD
INTERACTION DIRECTION
INTERACTION REASON
INTERACTION RESULT TYPE
INTERACTION STATUS
INTERACTION TYPE
ISP USAGE EVENT
ITEM
LETTER TYPE
MANAGE ACTION TYPE
MARKET PLAN MANAGEMENT
MARKET PLAN SUBSTITUTE BY DOC
MARKET PLAN TERM VALUE
NETWORK EVENT
NP REQUEST LINE ITEM STATE HISTORY
NP REQUEST STATE TYPE
NP REQUEST TYPE
NP STEP
ORDER STATUS
ORDER TYPE
ORGANIZATION AREA
ORGANIZATION BANNER
ORGANIZATION BUSINESS UNIT
ORGANIZATION CHAIN
ORGANIZATION COMPANY
ORGANIZATION CORPORATE
ORGANIZATION DISTRICT
ORGANIZATION DIVISION
ORGANIZATION REGION
OTHER INDIVIDUAL
PARTY AM PMP ASSIGNMENT HISTORY
PARTY AM PMP ASSIGNMENT STATUS
PARTY CONTACT LIST ROLE
PARTY SIM CARD ROLE
PMP ORGANIZATION AVAILABILITY
PREPAID VOUCHER
PREPAID WIRELESS
PRODUCT
PRODUCT MARKET PLAN
PRODUCT MARKET PLAN ASSIGNMENT
PRODUCT MARKET PLAN GEOGRAPHY ASSIGNMENT
PRODUCT PACKAGE
PRODUCT RATING PLAN
PRODUCT RATING PLAN DETAIL
PRODUCT TYPE
PROMOTION RESULT TYPE
PROMOTION TERM TYPE
PTV USAGE EVENT
PUBLICATION TYPE
SCRIPT QUESTION TYPE
SEASON
SERVICE
SERVICE CLASS
SERVICE CLASS TYPE
SERVICE REQUEST
SIM CARD ACCESS METHOD REASON
SIM CARD ACTIVATION REASON
SIM CARD ACTIVATION TYPE
SIM CARD SUBSCRIPTION REASON
SIM CARD TYPE
SUBSCRIBER ACTIVATION REASON
SUBSCRIPTION
TIME SLOT
TIME STANDARD BY DAY
TIME STANDARD BY WEEK
UMS ACCESS TYPE
VOICE MESSAGE SERVICE
WIRELESS NETWORK ELEMENT
YEAR TRANSFORMATION

### Revenue Business Area Logical Entity

Table 2-22 lists the Revenue entities.

Table 2-22 Revenue Business Area Logical Entities

Revenue Entity List
ACCESS METHOD
ACCESS METHOD TYPE
ACCOUNT ACCOUNTING CYCLE HISTORY
ACCOUNT PAYMENT
ACCOUNT PREFERRED PAYMENT METHOD
ACCOUNT REFUND
ADDRESS LOCATION
BUSINESS HALF MONTH
BUSINESS HALF YEAR
BUSINESS MONTH
BUSINESS QUARTER
BUSINESS WEEK
BUSINESS YEAR
CALENDAR HALF MONTH
CALENDAR HALF YEAR
CALENDAR MONTH
CALENDAR QUARTER
CALENDAR WEEK
CALENDAR YEAR
CAMPAIGN
CAMPAIGN TYPE
CELL
CELL SITE
COLLECTION AGENCY
COMMISSION TYPE
CONTRACT
CURRENCY EXCHANGE RATE
CUSTOMER
CUSTOMER CLASS
CUSTOMER CLASS ASSIGNMENT
CUSTOMER SCORE
CUSTOMER SEGMENT
CUSTOMER SOURCE
CUSTOMER TYPE
DAY
DEBT AGING BAND
DEBT COLLECTION
DEBT COLLECTION ASSIGNMENT
DEBT COLLECTION ASSIGNMENT BATCH
DIRECT DEBIT STATUS REASON
EQUIPMENT
EVENT FINANCIAL
EVENT INVOICE DELIVERY
EVENT LOYALTY PROGRAM
EVENT LOYALTY PROGRAM ACCUMULATION
EVENT LOYALTY PROGRAM REDEMPTION
FACTOR COMPANY
FISCAL HALF MONTH
FISCAL HALF YEAR
FISCAL MONTH
FISCAL QUARTER
FISCAL WEEK
FISCAL YEAR
FRAUD PROFILE CLASS
GEOGRAPHY CITY
GEOGRAPHY COUNTRY
GEOGRAPHY COUNTY
GEOGRAPHY REGION
GEOGRAPHY STATE
GEOGRAPHY SUB REGION
GEOGRAPHY WORLD
GL REFERENCE
INVOICE
INVOICE ADJUSTMENT
INVOICE ADJUSTMENT QUOTA
INVOICE ADJUSTMENT REASON
INVOICE ADJUSTMENT TYPE
INVOICE DELIVERY TYPE
INVOICE DISCOUNT
INVOICE DISCOUNT REASON
INVOICE DISCOUNT TYPE
INVOICE ITEM
INVOICE ITEM DETAIL
INVOICE ITEM DETAIL TYPE
INVOICE ITEM TYPE
INVOICE PAYMENT TERM
INVOICE PAYMENT TERM TYPE
INVOICE TYPE
IP ADDRESS POOL
LANGUAGE
LOYALTY PROGRAM CHANNEL
LOYALTY PROGRAM EVENT CATEGORY
LOYALTY PROGRAM EVENT TYPE
LOYALTY PROGRAM PARTY ROLE
LOYALTY PROGRAM POINTS BALANCE
NETWORK
NETWORK ELEMENT
NETWORK TYPE
ORGANIZATION AREA
ORGANIZATION BANNER
ORGANIZATION BUSINESS ENTITY
ORGANIZATION BUSINESS UNIT
ORGANIZATION BUSINESS UNIT TYPE
ORGANIZATION CHAIN
ORGANIZATION COMPANY
ORGANIZATION CORPORATE
ORGANIZATION DISTRICT
ORGANIZATION DIVISION
ORGANIZATION HIERARCHY
ORGANIZATION HIERARCHY LEVEL
ORGANIZATION HIERARCHY LEVEL ASSIGNMENT
ORGANIZATION HIERARCHY VERSION
ORGANIZATION ITEM SELLING PRICE
ORGANIZATION LEVEL
ORGANIZATION LEVEL ATTRIBUTE VALUE
ORGANIZATION LEVEL ATTRIBUTES
ORGANIZATION MARKET DATA
ORGANIZATION REGION
ORGANIZATION SERVICE WEBSITE
ORGANIZATIONAL DEMOGRAPHY VALUE
PARTY LOYALTY PROGRAM PARTICIPATION
PAYMENT METHOD TYPE
PAYMENT TRANSACTION TYPE
PREPAID RECHARGE
PRODUCT
PRODUCT CHARGE TYPE
PRODUCT PACKAGE
PRODUCT RATING PLAN
PRODUCT TYPE
PROMOTION
PROMOTION TYPE
RECHARGE REVENUE SLAB
SALES CHANNEL
SALES CHANNEL REPRESENTATIVE
SALES COMMISSION DETAIL
SALES COMMISSION PAYROLL
SALES COMMISSION PLAN
SALES COMMISSION PLAN DETAIL
SUBSCRIPTION
SUBSCRIPTION ASSIGNMENT
SUBSCRIPTION ASSIGNMENT TYPE
SUBSCRIPTION EVENT TYPE
SUBSCRIPTION PMP ASSIGNMENT
SUBSCRIPTION SERVICE CLASS ASSIGNMENT
SUBSCRIPTION STATUS
SUBSCRIPTION STATUS CATEGORY
SUBSCRIPTION STATUS HISTORY
SUBSCRIPTION STATUS REASON
SUBSCRIPTION TERM TYPE
SUBSCRIPTION TERM VALUE
SUBSCRIPTION TYPE
TAX EXEMPT
TIME SLOT
TIME STANDARD BY DAY
TIME STANDARD BY WEEK
YEAR TRANSFORMATION

## Logical Data Model Entity Dictionary

Table 2-23 through Table 2-29 list the logical data model entities, in alphabetical order.

Table 2-23 A to C Entity Descriptions

Entity Name | Type | Description
--- | --- | ---
`ACCESS METHOD` | Reference | Methods that a customer accesses or utilizes a service. For example: Fixed Line telephone numbers Wireless telephone numbers xDSL account IDD Calling card number
`ACCESS METHOD ACCOUNT ASSIGNMENT` | Reference | Assigns ACCESS METHODs to an account.
`ACCESS METHOD ASSIGNMENT TYPE` | Lookup | Type of relationship between two ACCESS METHODs. For example: Replace Bind together
`ACCESS METHOD ASSIGNMENT` | Reference | Assignment of an ACCESS METHOD to a related ACCESS METHOD.
`ACCESS METHOD ELEMENT` | 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: Country code Area code Local number
`ACCESS METHOD ELEMENT TYPE` | Lookup | Lookup for type of ACCESS METHOD ELEMENT. For example: Country code of phone number Area code of phone number
`ACCESS METHOD EQUIPMENT ASSIGNMENT` | Reference | How the access method binds to an equipment instance. For example: Cell phone number binds onto a cell phone Login code binds to a modem
`ACCESS METHOD GEOGRAPHY ASSIGNMENT` | Reference | Assigns the access method to a geographic region.
`ACCESS METHOD PARTY ASSIGNMENT` | Reference | Assigns access method to a party.
`ACCESS METHOD PARTY ASSIGNMENT TYPE` | Lookup | Lookup for type of relationship between ACCESS METHOD and PARTY. For example: Management Owned by The management type of access method party relationship specifies that an employee may be responsible for the maintenance of a group of access methods.
`ACCESS METHOD POOL` | Reference | The logical network resources. For example: Telephone number IP address
`ACCESS METHOD PORTING HISTORY` | Base | The history of access methods that the customer brought to the operator from another telecom operator, according to the number porting scheme.
`ACCESS METHOD SEGMENT` | Reference | Segments of ACCESS METHODs defined for usage tracking. For example: Phone number may have the segments: Country_Code + Area_Code + Local_Number IP address may have the segments: Type A, B, C, D, E subnetwork
`ACCESS METHOD SEGMENT PROD CAPABILITY RL` | Reference | The relationship between ACCESS METHOD SEGMENT and PRODUCT CAPABILITY to define which product capabilities require which access method segment.
`ACCESS METHOD STATUS HISTORY` | Base | The status of an ACCESS METHOD. Defines both current status and historical status. For example: Active Suspended Deactivated
`ACCESS METHOD STATUS REASON` | Lookup | Lookup for available reasons an ACCESS METHOD may have a change in status. For example: Customer relocation Suspension due to late-payment
`ACCESS METHOD STATUS TYPE` | Lookup | Lookup for available ACCESS METHOD status types and descriptions. For example: Active Inactive Suspended Future Activated
`ACCESS METHOD SUBSCRIPTION ASSIGNMENT` | Reference | Assigns ACCESS METHOD(s) to a SUBSCRIPTION.
`ACCESS METHOD TYPE` | Lookup | Lookup for ACCESS METHOD type: Defines the types of methods by which a customer may use or access services or products. For example: Fixed Line telephone numbers Wireless telephone numbers xDSL account IDD Calling card number
`ACCESSORIES` | Reference | The accessories that may be purchased from the service provider in addition to the item, product, or service. For example: Handset chains Starter kit Headset (earphones) USB Cable
`ACCOUNT` | Reference | The account is generated by a contract between service provider and customer. For the service provider hosting different network, including CDMA, GSM, broadband, and others, one customer may have a different account for a different network or can be unified. Once set up, a customer can use account for self service from the Web site or from a Service Provider terminal. In this case the account is normally protected by a password.
`ACCOUNT ASSIGNMENT TYPE` | Reference | The type of relationship between two accounts. For example, a corporate account has several affiliated accounts.
`ACCOUNT ACCOUNTING CYCLE HISTORY` | Base | Billing cycle status history for accounts.
`ACCOUNT ADJUSTMENT REASON` | Lookup | Lookup of all the reasons for adjustments. For example: Goodwill Agreement after complaint
`ACCOUNT ASSIGNMENT` | Reference | Relationship assignments between accounts. For example, parent and child accounts.
`ACCOUNT ASSIGNMENT REASON` | Lookup | Lookup for available reasons accounts may be related.
`ACCOUNT BALANCE ADJUSTMENT` | Base | Contains the list of all adjustments to any account balance. These are pure adjustments and not just additional payments or costs. An account balance adjustment is usually related to the party interaction thread.
`ACCOUNT BALANCE ADJUSTMENT TYPE` | Lookup | Lookup of all the types of adjustments. For example: Free Monthly Fee Free Service Direct credit amount
`ACCOUNT BALANCE BUCKET` |  | Tracks the expire date and recharge date for each “Bucket” of the prepaid balance.
`ACCOUNT BALANCE HISTORY` | Base | Balance history of account subjected to the primary currency. The balance value was classified by the balance type. For example: Monetary value deposit Free allowance minutes balance over wireless call
`ACCOUNT BALANCE TYPE` | Lookup | Type of account balance. For example: Broadband PTV Wireless free call allowance
`ACCOUNT BILLING CYCLE HISTORY` | Reference | Billing cycle status history for accounts.
`ACCOUNT BILLING FREQUENCY HISTORY` | Reference | Billing frequency history for accounts.
`ACCOUNT BILLING OCCURRENCE` | 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.
`ACCOUNT BILLING PERIOD HISTORY` | Reference | Billing period history for accounts.
`ACCOUNT BUSINESS INTERACTION ROLE` | Reference | The business interaction role which can be assigned by a Customer Account.
`ACCOUNT CONTRACT RELATIONSHIP` | Reference | Assignment of ACCOUNT to a CONTRACT.
`ACCOUNT COST` | Base | Subtype of COST, which associates a specific incurred cost to an ACCOUNT (through an EMPLOYEE).
`ACCOUNT CREDIT LIMIT` | Base | Credit limit assigned to an account, subscription, or contract.
`ACCOUNT DEBT DAY DRVD` | Derived | The summarized daily debt status for each account.
`ACCOUNT DEBT MONTH AGGR` | Aggregate | Derived from ACCOUNT DEBT DAY DRVD. The summarized monthly debt status for each CUSTOMER TYPE.
`ACCOUNT DEBT WRITE OFF` | Base | The transaction to write off debt, and clear it out from accounts receivable.
`ACCOUNT EVENT TYPE` | Lookup | Lookup for account event types.
`ACCOUNT MANAGEMENT HISTORY` | 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.
`ACCOUNT PARTY PMP RELATIONSHIP` | Reference | Assigns accounts and parties to PRODUCT MARKET PLAN.
`ACCOUNT PAYMENT` | 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.
`ACCOUNT PAYMENT DAY DRVD` | Derived | Daily aggregation of payments made by all customers.
`ACCOUNT PAYMENT METHOD STATUS` | Base | Status history of each account preferred payment method. For example: Active Inactive Invalid
`ACCOUNT PAYMENT METHOD STATUS HIST AGGR` | Aggregate | Collects all changes to the payment method status and the reason of the changes over time.
`ACCOUNT PAYMENT METHOD STATUS HIST DRVD` | Derived | Collects the changes on payment method status.
`ACCOUNT PAYMENT METHOD STATUS REASON` | Lookup | Lookup for specific status of the account payment method. For example: Activated Deactivated Disabled
`ACCOUNT PAYMENT METHOD STATUS TYPE` | Lookup | Lookup for types of ACCOUNT PAYMENT METHOD STATUS. For example: Active Inactive Payment Rejected
`ACCOUNT PAYMENT MONTH AGGR` | Aggregate | Monthly summary of payments made by all customers.
`ACCOUNT PMP PARTICIPATION HISTORY` | Base | Defines the history of how account uses the PRODUCT MARKET PLAN.
`ACCOUNT PREFERRED INVOICE DELIVERY` | Reference | The preferred invoice delivery type history for account.
`ACCOUNT PREFERRED PAYMENT METHOD` | Reference | Contains preferred payment methods for the account.
`ACCOUNT PROFILE` | Reference | Records more details about the account.
`ACCOUNT RECHARGE` | Base | The recharge (refill) made into the customer account.
`ACCOUNT REFUND` | Base | The customer refund is the money transferred back to customer account, which is normally based on an invoice adjustment.
`ACCOUNT REFUND DAY DRVD` | Derived | The daily summary of refund to customers and the impacts to revenue.
`ACCOUNT REFUND MONTH AGGR` | Aggregate | The monthly summary of refunds to customers and the impacts to revenue.
`ACCOUNT REFUND REASON` | Lookup | Lookup for the reasons why a refund may occur. For example: Invoice Adjustment Tax Refund
`ACCOUNT SEGMENT` | Reference | The segments identifying distinct groupings of accounts with similar characteristics. The account segments are typically generated from the data mining analysis.
`ACCOUNT SEGMENT ASSIGNMENT HISTORY` | Reference | Assign account segment to each account.
`ACCOUNT SEGMENTATION MODEL` | Reference | Used to cluster the account.
`ACCOUNT STATISTIC DRVD` | Derived | Account statistics for each account. One account normally has multiple SUBSCRIPTIONs, and CONTRACTs, all values on which are summed into the account level. Any deleted or blocked accounts are also included and are deemed as Churned, regardless of whether the deletion or block was voluntary.
`ACCOUNT STATISTIC TYPE AGGR` | Aggregate | Account statistical information at higher level by CUSTOMER TYPE.
`ACCOUNT STATUS DRVD` | Derived | The status change information about all accounts at every month.
`ACCOUNT STATUS HISTORY` | Base | The history of account status change, including activation, suspension, and so on.
`ACCOUNT STATUS REASON` | Lookup | Lookup for account status reasons, or possible reasons a given account status has been changed.
`ACCOUNT STATUS TYPE` | Lookup | Lookup for account status types.
`ACCOUNT STATUS TYPE AGGR` | Aggregate | Account statistical information at a higher level by customer type.
`ACCOUNT SUBSCRIPTION ASSIGNMENT` | Reference | History of subscriptions by an account.
`ACCOUNT SUBSCRIPTION ASSIGNMENT REASON` | Lookup | Each account to subscription relationship may have a reason associated with it. For example: Warrant account Payment account
`ACCOUNT TYPE` | Lookup | Lookup for account type. For example: Prepaid Postpaid
`ACCOUNTING CYCLE` | Lookup | Internal Billing cycle which is used to calculate the usage amount and update the account balance for accounting GL purpose.
`ACCOUNTING ITEM CATEGORY` | Lookup | Lookup for categories that can be associated with incurred costs. For example: Operations Staffing Supplies
`ADDITIONAL TEXT` | Reference | Additional text can save multiple lingual notes or comments for products, parties, and other information.
`ADDRESS LOCATION` | Reference | Address details for physical or mailing address.
`ADDRESS LOCATION NAME` | Reference | Tracks other names used by the same ADDRESS LOCATION.
`ADDRESS RELATED` | 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.
`ADDRESS RELATED REASON` | Lookup | Lookup for reasons addresses may be related.
`ADDRESS RELATED TYPE` | Lookup | Lookup for the type of relationship between two addresses.
`ADDRESS STATUS` | Base | Current status of an address location. For example: Active Current Changed Old address
`ADDRESS STATUS REASON` | Lookup | Lookup for the reason for a change to the current ADDRESS STATUS.
`ADDRESS TYPE` | Lookup | Lookup for address types. For example: Home Office Warehouse Billing
`ADVERTISING PERIOD` | Reference | Defines an advertising period.
`ADVERTISING QUARTER` | Reference | Defines a quarter in an advertising calendar.
`ADVERTISING WEEK` | Reference | Defines a week in an advertising calendar.
`ADVERTISING YEAR` | Reference | Defines a year in an advertising calendar.
`AGE BAND` | Lookup | Lookup to bin the customer into different groups according age. For example: 0~20 years 20~30 year 40-50 years 50-60 years
`AGE ON NET BAND` | Lookup | Defines subscriber life cycle ranges. For example: 0-1 month 1-2 months
`AGGREGATION INTERFACE` | 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.
`ALLOWANCE SBRP PRICE ALTERNATION` | Reference | An allowance, a number of something allowed before charging begins, for a SUBSCRIPTION.
`AMERICAN PROPERTY ADDRESS` | Reference | The Property Address format used in USA.
`ANZSIC CLASSIFICATION` | Reference | The SIC code used in Australia and New Zealand.
`APPOINTMENT CALENDAR` | Base | Appointments assigning times for vendor or provider to deliver or provide a service.
`APPOINTMENT TYPE` | Lookup | Lookup for appointment types. For example: Recurring Scheduled
`ARPU BASE CUSTOMER TYPE AGGR` | Aggregate | The monthly summary of revenue values for ARPU calculation on CUSTOMER TYPE level.
`ARPU BASE DRVD` | Derived | The monthly summary of revenue values and revenue value components along with the subscriber base count; used to calculate the ARPU values.
`ARPU BAND` | Lookup | Average Revenue per Unit Band definitions. For example: $0-100 $101-200
`ASSET` | 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.
`ATM INTERFACE` | 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.
`AUTONOMOUS SYSTEM` | Reference | An Autonomous System (AS) provides a structured view of routing by segregating the system that is using routing. For example: The Internet A corporate intranet Company extranet This segregates the system into a set of separately administered domains and each has its own independent routing policies. This is defined in RFC1771.
`AUXILIARY COMPONENT` | 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.
`AWARD LEVEL` | Lookup | The level of customer's loyalty, based on the LOYALTY PROGRAM and ability to contribute to the revenue of the carrier. For example: Platinum Gold Silver Bronze
`BANK` | Reference | Bank information that may be used in transactions.
`BANK DIRECT DEBIT CHANNEL` | Reference | Subtype of the PAYMENT CHANNEL, which tracks various bank channels where customers can pay by direct debt method.
`BARING REASON` | Lookup | Lookup defining reasons a customer may be banned from using a service.
`BASE DAY` | Reference | The abstracted information about a day, which serves as a base for DAY.
`BASE STATION CONTROLLER` | Reference | Subtype of NETWORK ELEMENT, which lists the Base Station Controller (BSC) of the network. The Base Station Controller provides, classically, the intelligence behind the BASE TRANSCEIVER STATION (BTS)s. Typically a BSC has tens or hundreds of BTSs under its control. The BSC handles allocation of radio channels, receives measurements from the mobile phones, and controls handovers from BTS to BTS.
`BASE TRANSCEIVER STATION` | Reference | Base Transceiver Station (BTS) is the equipment which facilitates the wireless communication between User Equipment (UE) and the network.
`BER FER ERROR RATIO DAY DRVD` | Derived | Daily BER (Bit Error Rate) and FER (Frame Error Rate) statistics about the network elements.
`BER FER ERROR RATIO MONTH AGGR` | Aggregate | Monthly BER (Bit Error Rate) and FER (Frame Error Rate) statistics about the network elements. Derived from BER FER ERROR RATIO DAY DRVD.
`BER FER TYPE` | Lookup | Lookup to indicate the statistics value for BER (Bit Error Rate) or FER (Frame Error Rate).
`BILLING CYCLE` | 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: The first day of month 10th day of month
`BILLING FREQUENCY` | Lookup | The billing frequency specifies the number of billing periods that comprise the billing cycle.
`BILLING OCCURRENCE TYPE` | Lookup | Type of billing occurrence which could be classified by the trigger type. For example: Triggered by customer inquiry. Triggered by automatic billing cycle.
`BILLING PERIOD` | Lookup | The billing period specifies the unit to be used to calculate the billing cycle (such as days or months).
`BILLING STATUS CATEGORY` | Lookup | Lookup for category of billing status. For example: Successfully Billed Failure to Bill
`BILLING STATUS TYPE` | Lookup | Lookup for the status type of billing result, including the reasons. For example: Incorrect_data_failed Incorrect_user_not_found Successful
`BLACK LIST HISTORY` | Base | History of all black-listed customers.
`BRAND` | Reference | The brands associated with hardware (usually this applies for handsets, but also for ITEMs).
`BRIDGING PROTOCOL` | 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.
`BROADBAND` | Reference | Broadband is subtype of PRODUCT service. Describes the characteristics specific to the broadband product.
`BROADBAND RATING PLAN` | Reference | Subtype of PRODUCT RATING PLAN applied to BROADBAND product.
`BROADBAND USAGE EVENT` | 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.
`BUNDLED NETWORK EVENT` | Base | A detailed product bundle usage event. A bundled network event is comprised of other Product Usage event(s), that may be either Product Bundle Usage or Product Component Usage.
`BUSINESS HALF MONTH` | Reference | Defines month-in-half in a business calendar.
`BUSINESS HALF YEAR` | Reference | Defines half year in a business calendar.
`BUSINESS INTERACTION` | Reference | Describes an arrangement, contract, communication, or joint activity between one or more PARTY ROLEs, Element Roles, or Customer Accounts. A Business Interaction may consist of one or more BUSINESS INTERACTION ITEMs. A BUSINESS INTERACTION ITEM may refer to a Product, Service, Element, or one of their specifications. A Business Interaction is further defined by one or more Places. One Business Interaction may reference another Business Interaction and one BUSINESS INTERACTION ITEM may reference another BUSINESS INTERACTION ITEM on the same or different Business Interaction. There are five types of Business Interactions: Requests Responses Notifications Agreements Instructions
`BUSINESS INTERACTION ASSIGNMENT` | Reference | Defines the relationship between two BUSINESS INTERACTIONs.
`BUSINESS INTERACTION ASSIGNMENT TYPE` | Lookup | Interaction type such as subordinate business interaction.
`BUSINESS INTERACTION ITEM` | Base | The purpose for the Business Interaction expressed in terms of a Product Type, PRODUCT MARKET PLAN, Service Type, or NETWORK ELEMENT TYPE or may refer to a Product, Service, or NETWORK ELEMENT. The detail items included in the BUSINESS INTERACTION.
`BUSINESS INTERACTION ITEM PRICE` | Base | This is the actual price charged to the BUSINESS INTERACTION ITEM, despite the original list and discount price from product setting. An amount associated with a BUSINESS INTERACTION ITEM that is valued by the associated PMP Price
`BUSINESS INTERACTION LOCATION ASSIGNMENT` | Reference | The BUSINESS INTERACTION ROLE which can be assigned to an address. For example: Billing address Shipment address
`BUSINESS INTERACTION ROLE` | Reference | The roles which can be played by PARTY or other business interaction elements like Resource, and so on.
`BUSINESS INTERACTION TYPE` | Lookup | Type of BUSINESS INTERACTION. For example: Customer Order Contract
`BUSINESS INTERACTION VERSION` | Reference | Represents the ability to distinguish between different instances of ElementSpecifications. It represents a particular form or variety of a ElementSpecification that is different from others or from the original. The form represents differences in attributes, methods, relationships, or constraints that characterize this particular ElementSpecification, but which are not enough to warrant creating a new ElementSpecification.
`BUSINESS LEGAL STATUS` | Lookup | The legal status of the company. For example, a Public Company, Private, and so on.
`BUSINESS MONTH` | Reference | Defines month in a business calendar.
`BUSINESS QUARTER` | Reference | Defines quarter in a business calendar.
`BUSINESS UNIT JOB ROLE` | Reference | Assigns job roles to a business unit within the organization.
`BUSINESS UNIT SHIFT` | Reference | Work shift associated with the Business Unit, mapped to the Employee job roles for the allocation for these shifts.
`BUSINESS WEEK` | Reference | Defines week in a business calendar.
`BUSINESS YEAR` | Reference | Defines year in a business calendar.
`CABLE` | Reference | A container of conductors or fibres. At least two connectors are attached to a cable.
`CABLE MODEM` | 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.
`CALENDAR HALF MONTH` | Reference | Defines month-in-half in a Gregorian or Normal Calendar.
`CALENDAR HALF YEAR` | Reference | Defines half year in a Gregorian or Normal Calendar.
`CALENDAR MONTH` | Reference | Defines month in a Gregorian or Normal Calendar.
`CALENDAR QUARTER` | Reference | Defines quarter in a Gregorian or Normal Calendar.
`CALENDAR WEEK` | Reference | Defines weeks in a Gregorian or Normal Calendar.
`CALENDAR YEAR` | Reference | Defines years in a Gregorian or Normal Calendar.
`CALL CATEGORY` | Lookup | Lookup for call categories. For example: Data, Fax, or Voice.
`CALL CENTER` | Reference | Defines call centers for a carrier or provider.
`CALL CENTER AGENT` | Reference | Agents of a call center.
`CALL CENTER AGENT TYPE` | Lookup | Lookup for call center agent types. For example: Employee or IVR.
`CALL CENTER CALL DAY DRVD` | Derived | The daily aggregate of customer call statistics from the call center. The customer calls are analyzed for the time of the call, duration of the call, subscriber or non-subscriber calling, and the call direction.
`CALL CENTER CALL MONTH AGGR` | Aggregate | Monthly summary of customer call statistics for the call center.
`CALL CENTER CASE DAY DRVD` | Derived | Statistics for all the cases initiated or resolved by the call center. For example: Customer Compliant Customer Inquiry
`CALL CENTER CASE MONTH AGGR` | Aggregate | Monthly summary of statistics for all the cases initiated or resolved by the call center.
`CALL CENTER CASE SUB TYPE` | 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".
`CALL CENTER CASE TITLE` | 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: Handset Technical Support Product Usage Technical Support Network Fault Technical Support
`CALL CENTER CASE TYPE` | Lookup | Lookup for type of call center cases. For example: Cmpl: Complaint Inqry: Inquiry Srv: Service Request
`CALL CENTER SERVICE CAPABILITY` | Reference | Assigns to the CALL CENTER, the languages, products, or geographical areas which the call center can serve.
`CALL DIRECTION` | Lookup | To indicate incoming call or outgoing call.
`CALL FORWARD` | Reference | A type of phone service. The calling party can be on hold if receiving party is in a call.
`CALL OTHER TYPE` | Lookup | This is to record any other characteristics of the call, such as, 3-party call, or any user defined special type of call.
`CALL RECYCLED REASON` | Lookup | Lookup for reasons why the voice carrying channel is being recycled during the call.
`CALL ROUTING TYPE` | Lookup | Lookup to define how the call was routed. For example: Calling from external carrier From Wireless to Land Phone
`CALL SERVICE TYPE` | Lookup | Lookup for service types that could be used in a call. For example: Toll-Free number such as 800/400 Emergency Call such as 911, 112, 110
`CALL SOURCE DESTINATION` | Reference | All the possible call sources or call destinations. The call sources or call destinations classify the calls into different groups, such as: local call, long distance domestic call, or internal call.
`CALL SUCCESS FAILURE TYPE` | 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.
`CALL SURCHARGE` | Lookup | Any extra charge on the call in addition to the normal rating.
`CALL TERMINATION REASON` | Lookup | Lookup for the reasons a call may be terminated. For example: Dropped Successful End
`CALL TYPE` | Lookup | Lookup to further classify call category into call types. For example: Voice Voice SMS and MMS Data and FAX Information services GPRS services for Data and Fax
`CALLER ID` | Reference | Subtype of PRODUCT, with specific information about CALLER ID service.
`CAMPAIGN` | 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.
`CAMPAIGN CHANNEL` | 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.
`CAMPAIGN CHANNEL ASSIGNMENT` | Reference | The assignment to define which CAMPAIGN is lunched at which CAMPAIGN CHANNEL.
`CAMPAIGN CHANNEL TYPE` | Lookup | Lookup for campaign channel type. For example: newspaper, Television, Magazine.
`CAMPAIGN CHARACTERISTIC` | 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.
`CAMPAIGN CHARACTERISTIC VALUE` | Reference | A number or text that can be assigned to a CAMPAIGN CHARACTERISTIC.
`CAMPAIGN COST` | Base | Subtype of COST which can apply to a CAMPAIGN.
`CAMPAIGN DOCUMENT` | Reference | The customer documents provided during campaign activities.
`CAMPAIGN MANAGEMENT HISTORY` | 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.
`CAMPAIGN MESSAGE` | Reference | Details regarding message broadcast or sent during a CAMPAIGN.
`CAMPAIGN MESSAGE CREATIVE` | Base | Information about the creative content of the message.
`CAMPAIGN MESSAGE DEPICTION` | Reference | Details about how the execution message is depicted for a CAMPAIGN.
`CAMPAIGN PURPOSE TYPE` | Lookup | Lookup for types of campaign purposes. For example: Acquire new customers Consolidate existing customers Retention existing customers
`CAMPAIGN RELATIONSHIP` | Reference | Defines the relationship between two CAMPAIGNs. For example: Replace/upgrade Enhance
`CAMPAIGN STATUS` | Lookup | Status of CAMPAIGN.
`CAMPAIGN TERM VALUE` | Reference | The term value for a given campaign.
`CAMPAIGN TYPE` | Lookup | Lookup for type of campaign. For example: A targeted promotion (to specific individuals, account or group of accounts) A mass market promotion (to a massive audience usually through radio, Television and newspaper)
`CANNIBALIZATION DETAIL DAY DRVD` | 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".
`CANNIBALIZATION DETAIL MONTH AGGR` | Aggregate | The calculated tariff or package change summary of all customers at the month level. For prepaid customers, usually it is impossible to track customer movement between products due to lack of customer identification.
`CAPACITY` | 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.
`CARD` | Reference | Represents a type of physical container that can be plugged into a SLOT. A card may represent a primary function, for example, a networking card, or an auxiliary function, for example, a memory card, that supports another card. All objects of this type are capable of carrying electrical and optical signals. A card also provides a mounting point for other types of Managed Physical Elements, such as Chips or Cards.
`CARD RELATIONSHIP` | 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.
`CELL` | Reference | The cell in a wireless network such as GSM, which is an area serviced by the BASE TRANSCEIVER STATION (BTS).
`CELL OUTAGE REASON` | Lookup | Lookup for reasons a cell outage could occur. For example: Power failure Natural disaster Theft
`CELL SECTOR` | 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.
`CELL SITE` | Reference | This is where the base station radio equipment and their antennas are located. A cell site gives radio coverage to a cell.
`CELL SITE COST` | Base | Subtype of COST which could apply to a CELL SITE. For example: Expenses for the cell site building Rent Maintenance
`CELL SITE TYPE` | Lookup | Lookup for type of CELL SITE. For example: the cell site type can be classified by GSM/CDMA/PHS/broadband/Pay TV.
`CELL STATISTIC DAY DRVD` | Derived | The network parameters and runtime statistics captured at the cell level.
`CELL STATISTIC MONTH AGGR` | Aggregate | The network parameters and runtime statistics for all CELL SITEs aggregated at the month and certain geography level.
`CELL TYPE` | Lookup | Lookup for all possible cell types. For example, Macro, Micro, and Pico: Macro cells are large geographical area where subscriber base is less dense. Micro cells are small cells in side the macro cells to cover high subscriber density and uneven distribution. Pico cells are used in large buildings, where signals from ground towers are poor.
`CFS SPEC VERSION DETAIL` | 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.
`CHANGE PROPOSED BY TYPE` | Lookup | Lookup for who proposed the changes for a customer tariff change. For example: By customer By operator
`CHANNEL` | Reference | Identifies all the channels through which customers interact with the telco provider for sales or services purposes.
`CHANNEL COST` | Base | Subtype of COST, which collects all costs specifically related to a given sales channel.
`CHANNEL TYPE` | Lookup | Lookup for types of channels as defined by their functions. For example: Sales channel Payment channel Debt collection channel Loyalty program channel (where to join/change/redeem loyalty program)
`CHASSIS` | 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.
`CHASSIS POSITION` | 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.
`CHURN PREDICT SOURCE DERIVED` | Derived | Monthly statistics regarding each account, which acts as source material for training the Churn Predict Mining Model.
`CHURN REASON` | Lookup | Lookup for reasons an account may churn.
`CIRCUIT CATEGORY` | Lookup | Lookup for categories to classify the type of circuit. For example: Analogue Voice Digital Data Services (DDS) ATM
`CIRCUIT COMPONENT` | 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: From the customer site to the exchange/switch From the switch to another switch From the second switch to the second customer site There are two scenarios: The circuit component links two switches. The circuit component links a switch with a customer site 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.
`CIRCUIT RENTAL` | Base | Business activities of renting some circuits to other operators, in return for a monthly, or fixed, revenue.
`CIRCUIT RENTAL EVENT TYPE` | Lookup | Lookup for types of rental events. For example: Rental Initial Monthly Charge Maintenance Charge Termination
`CIRCUIT TRAFFIC` | Base | The traffic volume statistics over certain periods, where periods are implementation dependent but generally hourly, for each CIRCUIT COMPONENT.
`CIRCUIT TYPE` | Lookup | Lookup for type of detailed circuit types. For example: For interconnect: T1 or E1, carry 1.5mbps T2 6.312 Mbit/s T3 44Mbit/s For customer connection ADSL: ADSL 1: Normally 1Mbit/s ADSL 2x
`COLLECTION` | 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.
`COLLECTION AGENCY` | Reference | Subtype of a PARTY, who collects the customer debt on behalf of the operator under a financial agreement. For example: Debt collection Roaming settlement collection
`COMMISSION DAY DRVD` | Derived | Statistics of all commissions granted to the sales agents because of the sales of products and services in the given period.
`COMMISSION MONTH AGGR` | Aggregate | Monthly aggregation of all commissions granted to the sales agents because of the sales of products and services in the given period.
`COMMISSION TYPE` | Lookup | Lookup for commission types that may be paid to sales representatives. For example: FLAT: flat rate PERCENTAGE: percent of transaction amount
`COMMUNICATION SERVICE` | Reference | The service type of product, including fixed line phone call, wireless phone call, and so on.
`COMP INTEL CHARACTERISTIC` | Reference | A characteristic quality or distinctive feature of a COMPETITOR INTELLIGENCE. The characteristic can take on a discrete value, such as number of press releases, can take on a range of values, for example, number customers within a MARKET SEGMENT (50,000 - 100,000), or can be derived from a formula, for example, number of products offered in a MARKET SEGMENT = the number of the COMPETITOR's Product instances associated to the MARKET SEGMENT.
`COMP INTEL CHARACTERISTIC VALUE` | Reference | A number or text that can be assigned to a COMP INTEL CHARACTERISTIC.
`COMP INTEL MARKET SEGMENT` | Reference | A MARKET SEGMENT in which a COMPETITOR makes Product available.
`COMP PROD CRRL CHARACTERISTIC` | 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).
`COMP PROD CRRL CHARACTERISTIC ASSIGNMENT` | Reference | Assign the COMP PROD CRRL CHARACTERISTIC to the related COMPETITOR INTELLIGENCE characteristic.
`COMP PROD CRRL CHARACTERISTIC RELATIONSHIP` | Reference | Defines the relationship between two COMP PROD CRRL CHARACTERISTICs.
`COMP PROD CRRL CHARACTERISTIC VALUE` | Reference | A number or text that can be assigned to a COMP PROD CRRL CHARACTERISTIC.
`COMPETITIVE TIER` | Reference | A classification of a COMPETITOR, such as by size, product lines offered, and so on.
`COMPETITOR` | Reference | A PARTY that offers PRODUCT similar to the enterprise's PRODUCT in a MARKET SEGMENT.
`COMPETITOR INTELLIGENCE` | Reference | Facts gathered about a COMPETITOR's plans and activities. These facts perform COMPETITOR SWOT analysis to better understand a COMPETITOR.
`COMPETITOR INTELLIGENCE PARTY ROLE` | Reference | The PARTY who developed the COMPETITOR INTELLIGENCE.
`COMPETITOR MARKET SEGMENT ASSIGNMENT` | Reference | A MARKET SEGMENT served by a COMPETITOR.
`COMPETITOR MARKET SEGMENT SWOT` | Reference | Specifies a Strength, Weakness, Opportunity, or Threat in a MARKET SEGMENT served by a COMPETITOR.
`COMPETITOR PRODUCT CORRELATION` | Reference | A comparison or relationship between an enterprise-s PRODUCT with a COMPETITORs' Product. Information about the correlation may include MARKET SEGMENTs, Product Offering life cycle stage, Jurisdiction, or definable COMP PROD CRRL CHARACTERISTICs.
`COMPETITOR SWOT` | Reference | General (non-MARKET SEGMENT specific) Strength, Weakness, Opportunity, or Threat when compared to a COMPETITOR.
`COMPETITOR TIER ASSIGNMENT` | Reference | A classification of a COMPETITOR, such as by size, product lines offered, and so forth.
`COMPONENT SUBSCRIPTION PRICE` | Reference | Part of a Product Price representing a single element of the price.
`COMPOSITE COMP PROD CRRL CHARACTERISTIC` | 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.
`COMPOSITE PRODUCT RATING PLAN` | Reference | A special type of PRODUCT RATING PLAN to represent a group of rating plans together forming another new rating plan.
`COMPOSITE PRODUCT RATING PLAN ASSIGNMENT` | Reference | Defines the relationship of which PRODUCT RATING PLAN each COMPOSITE PRODUCT RATING PLAN contains.
`COMPOSITE SERVICE` | Reference | A group of services together forming a new service.
`COMPOSITE SERVICE INCLUSION` | Reference | Defines the relationship between COMPOSITE SERVICE and atomic service. Composite service inclusion defines how the COMPOSITE SERVICE is formed.
`COMPOSITE SERVICE TYPE INCLUSION` | Reference | Tracks the relationship of which atomic service type each composite service type includes.
`COMPOSITE SUBSCRIPTION PRICE` | Reference | A Product Price that is made up of parts. The parts may be other Composite Prod Prices or Component Prod Prices.
`COMPOUND ELEMENT` | Reference | This is the abstract base entity for all composite entities that are inherently manageable and form a PRODUCT. The key difference between network element and COMPOUND ELEMENT is that network element describes either a Physical or a Logical entity. In contrast, COMPOUND ELEMENT describes managed entities that are collections of other managed entities. A key point is that each managed entity that is part of a COMPOUND ELEMENT can be individually managed as either a PHYSICAL ELEMENT or a LOGICAL ELEMENT.
`COMPOUND ELEMENT COLLECTION` | Reference | An entity that is individually manageable. A Compound Element Collection is an aggregate entity consisting of NETWORK ELEMENT and optionally Compound Element Collection entities. As such, a Compound Element Collection represents a set of PHYSICAL ELEMENTs and LOGICAL ELEMENTs that collectively represent a managed entity. For example, a Network is a subclass of Compound Element Collection. A Network can be made up of other Networks and SubNetworks. Each Network or SubNetwork can be made up of physical and logical components, gathered and represented by an Element Collection. Each node in the network can be represented by a NETWORK ELEMENT.
`COMPOUND ELEMENT COMPOUND DETAIL` | Reference | Defines the semantics of aggregating COMPOUND ELEMENT into a COMPOUND ELEMENT.
`COMPOUND ELEMENT DETAIL` | Reference | Defines the semantics of the COMPOUND ELEMENT aggregation. Compound Element Detail is abstract, because only its subclasses should be instantiated. There are three concrete subclasses of this class, which are used to represent the aggregation of PHYSICAL ELEMENT, LOGICAL ELEMENT, and COMPOUND ELEMENT into this particular COMPOUND ELEMENT.
`COMPOUND ELEMENT LOGICAL DETAIL` | Reference | This is a concrete entity that defines the semantics of aggregating LOGICAL ELEMENT into a COMPOUND ELEMENT.
`COMPOUND ELEMENT PHYSICAL DETAIL` | Reference | This is a concrete entity that defines the semantics of aggregating PHYSICAL ELEMENT into a COMPOUND ELEMENT.
`COMPOUND ELEMENT ROLE` | Reference | This entity is a role that is defined by the interaction between PHYSICAL ELEMENT ROLEs and LOGICAL ELEMENT ROLE. There must be at least one or more PHYSICAL ELEMENT ROLEs and one or more LOGICAL ELEMENT ROLE to form a Compound Element Role. However, neither a PHYSICAL ELEMENT ROLE nor a Logical Element Role has to belong to a Compound Element Role.
`COMPOUND ELEMENT ROLE ASSIGNMENT` | Reference | Implements the relationship between COMPOUND ELEMENT and network element role.
`COMPOUND ELEMENT ROLE SPEC` | Reference | Implements the relationship between COMPOUND ELEMENT and network element role.
`COMPOUND ELEMENT SPEC` | Reference | This is the abstract base entity that defines the invariant characteristics and behavior, attributes, methods, constraints, and relationships, of a COMPOUND ELEMENT. The key difference between a Compound Element Spec and either a PHYSICAL ELEMENT SPEC and a LOGICAL ELEMENT SPEC is that a PHYSICAL ELEMENT SPEC and LOGICAL ELEMENT SPEC define templates for specifying the invariant characteristics and behavior of PHYSICAL ELEMENTs and LOGICAL ELEMENTs, respectively. In contrast, a Compound Element Spec describes templates that contain at least one PHYSICAL ELEMENT SPEC and at least one LOGICAL ELEMENT SPEC. Optionally, one or more Compound Element Specs may also be specified. Thus, a Compound Element Spec is in effect a "shorthand notation" for specifying complementary PHYSICAL ELEMENT SPECs and LOGICAL ELEMENT SPECs.
`COMPOUND ELEMENT SPEC ATOMIC` | Reference | This entity describes specific attributes, behavior, relationships, constraints, and semantics for building COMPOUND ELEMENT objects. The purpose of this entity is to track specifications of COMPOUND ELEMENTs separately from other types of Element Specifications. This entity inherits the Modifies Element Spec aggregation, and therefore can be used with the corresponding COMPOUND ELEMENT entity. The key difference between a COMPOUND ELEMENT SPEC and either a PHYSICAL ELEMENT SPEC and a Logical Element Type is that a PHYSICAL ELEMENT SPEC and Logical Element Type define templates for specifying the invariant characteristics and behavior of PHYSICAL ELEMENTs and LOGICAL ELEMENTs, respectively. In contrast, a COMPOUND ELEMENT SPEC describes templates that contain at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type. Optionally, one or more COMPOUND ELEMENT SPECs may also be specified. The difference between a Compound Element Spec Atomic entity and a COMPOUND ELEMENT SPEC COMPOSITE entity is that a Compound Element Spec Atomic entity is designed to be a standalone entity. Note that it still aggregates at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type; however, the result is that this Compound Element Spec Atomic entity can be used by itself.) In contrast, a COMPOUND ELEMENT SPEC COMPOSITE entity is made up of one or more COMPOUND ELEMENT SPECs, one of which must be a Compound Element Spec Atomic entity.
`COMPOUND ELEMENT SPEC COMPOSITE` | Reference | This entity describes specific attributes, behavior, relationships, constraints, and semantics for building composite COMPOUND ELEMENT objects. The purpose of this entity is to track specifications of COMPOUND ELEMENTs separately from other types of Element Specifications. This entity inherits the modifies Element Spec aggregation, and therefore can be used with the corresponding COMPOUND ELEMENT entity. The key difference between a COMPOUND ELEMENT SPEC and either a PHYSICAL ELEMENT SPEC and a Logical Element Type is that a PHYSICAL ELEMENT SPEC and Logical Element Type define templates for specifying the invariant characteristics and behavior of PHYSICAL ELEMENTs and LOGICAL ELEMENTs, respectively. In contrast, a COMPOUND ELEMENT SPEC describes templates that contain at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type. Optionally, one or more COMPOUND ELEMENT SPECs may also be specified. The difference between a COMPOUND ELEMENT SPEC ATOMIC entity and a Compound Element Spec Composite entity is that a COMPOUND ELEMENT SPEC COMPOSITE entity is designed to be a standalone entity. (Note that it still aggregates at least one PHYSICAL ELEMENT SPEC and at least one Logical Element Type; however, the result is that this COMPOUND ELEMENT SPEC ATOMIC entity can be used by itself.) In contrast, a Compound Element Spec Composite entity is made up of one or more COMPOUND ELEMENT SPECs, one of which must be a COMPOUND ELEMENT SPEC COMPOSITE entity.
`COMPOUND ELEMENT TP DETAIL` | Reference | Concrete entity that links TERMINATION POINT to COMPOUND ELEMENT. For example, it will describe characteristics and behavior of the TERMINATION POINTs that comprise this particular Element Port in terms of dependencies and how a TERMINATION POINT interacts with other TERMINATION POINTs.
`COMPOUND ELEMENT UNIT` | Reference | A Element Unit is an entity that is individually manageable. The Compound Element Unit is an aggregate entity consisting of both physical and logical aspects of a managed Element. For example, a ROUTER is a Element Unit. Different PHYSICAL ELEMENT objects can model the physical aspects of the ROUTER in detail. For example, its CARDs, the number and type of PHYSICAL PORTs that are on each CARD, and so forth), and different LOGICAL ELEMENT objects can model the logical aspects of the ROUTER in detail (For example, what Software it is running, how many DEVICE INTERFACEs of what type are currently enabled, if there are any outstanding Faults or Alarms, and so forth). Resource Element aggregates all PHYSICAL ELEMENT and LOGICAL ELEMENT objects, enabling a high-level view of the physical and logical aspects of the Element to be provided.
`CONNECT DISCONNECT DAY DRVD` | Derived | Statistics about all connections and disconnections from each ACCESS METHOD on the network per day. This is related to the network usage or traffic. This entity is not related to counting "subscriptions" to a given service.
`CONNECT DISCONNECT MONTH AGGR` | Aggregate | Monthly aggregation of all connections and disconnections on the network per day, for network usage or traffic analysis.
`CONNECTION` | 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.
`CONNECTION TERMINATION POINT` | 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.
`CONSEQUENCE PERFORMANCE NOTIFICATION` | 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.
`CONSEQUENCE PERFORMANCE NOTIFICATION SPEC` | 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.
`CONTACT LIST` | 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.
`CONTACT LIST CHANGE REASON` | Lookup | Lookup for possible reasons for changing the CONTACT LIST.
`CONTACT LIST COST` | 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).
`CONTACT LIST RECURRENCE TYPE` | Lookup | A categorization of the recurrence of a CONTACT LIST. For example: W = Once a Week M = Once a Month Y = Once a Year MI = Once a Month with Invoice.
`CONTACT ROLES` | Lookup | Describes the various roles a contact individual may play in the relationship with the operator.
`CONTENT` | Reference | Keeps all downloadable content provided to the customer through the operator's network. For example: Weather reports Constellation Jokes
`CONTENT DELIVERY EVENT` | Base | EVENT in which content was downloaded.
`CONTENT PRICE` | Reference | Price for downloading/ordering the content. This price is for individual content clip. There might be other contents priced as a flat rate rather than different price for each content. In this case, the pricing information should be in PRODUCT RATING PLAN.
`CONTENT PRICING TYPE` | Lookup | Lookup for types of content pricing. For example: Charge per download Monthly fixed rate
`CONTENT PROVIDER` | Reference | Provider for content that would be consumed by end user. The contents could be video, audio clips, or text content.
`CONTENT TYPE` | Lookup | Lookup for content types. For example: Constellation Jokes Weather report
`CONTRACT` | Reference | Legal agreement between a Communications Service Provider and an account.
`CONTRACT APPROVAL` | Base | Approval for the CONTRACT from the operator's authorized employee, if the contract requires higher level approval or review.
`CONTRACT ASSIGNMENT` | Reference | Defines relationship(s) between contracts.
`CONTRACT ASSIGNMENT REASON` | Lookup | Lookup for reasons of why two contracts are related. For example: The reason for one contract to be replaced by another: CNRT-END: The first contract was naturally terminated DLT-Delete: CUST-CHNG: Voluntary change by customer OP-INIT: Service Provider, operator, solicited the contract change, normally to increase the ARPU value The reason for one contract to depend on another: Equipment dependency Network dependency
`CONTRACT ASSIGNMENT TYPE` | Lookup | Lookup for types of assignment between two contracts. For example: RPLC: a new contract replaces the original contract UPGRADE: a new contract replace original one with upgraded product DEPEND: a contract depends on existence of another contract
`CONTRACT CHANGE INITIATOR TYPE` | Lookup | Lookup to classify the initiator of the contract change.
`CONTRACT CHANGE TYPE` | Lookup | Lookup of all the type of contract changes. For example: Contract Renew Contract Terminate
`CONTRACT CHANGED DRVD` | Derived | Derived information about a customer's current/future contract for analytical purpose. This entity captures only changed, current or future, contracts.
`CONTRACT DOCUMENT` | Reference | The document(s) provided by the customer when a contract was signed. For example: Photocopy image of customer ID The contract itself Any other documents attached to the contract
`CONTRACT DRVD` | Derived | Derived information about a customer's current/future contract for analytical purpose. The entity only contains changed contract (current or future).
`CONTRACT ITEM` | Reference | Detail items for the CONTRACT. Each item may use a different PRODUCT.
`CONTRACT MONTH AGGR` | Aggregate | Derived information about a customer's current/future contract for analytical purpose. The entity only contains changed contract (current or future).
`CONTRACT PRODUCT ASSIGNMENT` | Reference | To accommodate special link or additional usage of product in contract.
`CONTRACT STATUS` | Base | The status history of the CONTRACT.
`CONTRACT STATUS REASON` | Lookup | Lookup for description of the contract status change. For example: Customer originated product change Customer originated churn Provider originated: Bad payment (leading to suspension) Customer originated: Debt paid (leading to reactivation) Customer originated: Banqueroute
`CONTRACT STATUS TYPE` | Lookup | Lookup for all possible types of CONTRACT STATUS. For example: Newly created for new account Renewed automatically Naturally expired or terminated
`CONTRACT TERM TYPE` | Lookup | Lookup for all possible terms which may be attached to a CONTRACT. For example: Monetary amount Period Premium Initial points Cancellation policy Subsidy
`CONTRACT TERM VALUE` | Base | The value of terms attached to the CONTRACT. For example: Monetary amount Period Premium Initial points The value can vary at different time period of contract. For example, the monthly fee might be 100 for the first six months and 80 for the last six months. A penalty calculation can also be based on the months left in contract.
`CONTRACT TYPE` | Lookup | Lookup for contract types.
`CORE INTERFACE` | 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.
`COST` | Base | Costs that have been incurred from operations and events at trackable levels. For example: Gift offer expense Employee salary Commission Promotion delivery cost Carrier billing charge (for roaming/LAC/and so on)
`COST CENTER` | Reference | Cost Center of a COURIER or provider to which costs can be charged.
`COST CENTER BUDGET` | Base | The budget of each cost center at a specific financial period.
`COST CUSTOMER MONTH AGGR` | Aggregate | Statistics of various costs incurred to the customer. These details are important for analysis such as: Subscriber retention cost Subscriber acquisition cost
`COST CUSTOMER DRVD` | Derived | Monthly aggregation of various cost incurred to the customer. These details are important for analysis such as: Subscriber retention cost Subscriber acquisition cost
`COST ORGANIZATIONAL MONTH AGGR` | Aggregate | Monthly aggregation of all expenses by each business unit inside the carrier.
`COST ORGANIZATIONAL DRVD` | Derived | Statistics of all expenses by each business unit inside the carrier. These values can be useful for auditing and budgeting purposes.
`COST REASON` | Lookup | Lookup of all possible reasons why the cost occurred. For example: Natural disaster Operator error
`COST SUBTYPE` | Lookup | Lookup to further classify COST TYPEs. For example: Acquisition cost Retention cost Salary Damaged New machine Repair fee
`COST TYPE` | 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).
`COURIER` | Reference | The party who provides the Courier service for the Telecom Operator.
`COURIER COST` | Base | Subtype of COST which applies to a COURIER for delivering products or invoices to the customer.
`CPE LOGICAL DEVICE ROLE` | Reference | Defines required logical features to implement the specific role of a CPE (Customer Premise Edge) device, as used in a PRODUCT or SERVICE.
`CREDIT CATEGORY` | Reference | List of credit categories available that may be assigned to customers. For example: Excellent Good High risk
`CREDIT CATEGORY MONTH AGGR` | Aggregate | Credit category aggregation over all customers at each month.
`CREDIT CATEGORY DRVD` | Derived | Credit category assigned to each customer at each month. The credit categories are defined in the credit category dimension.
`CREDIT SCORE PROVIDER` | Reference | Provides reference financial rating scores for each customers to the service provider. This information is also called the "Credit Rating Agency".
`CURRENCY` | Lookup | Lookup for currencies that may be used in a transaction.
`CURRENCY EXCHANGE RATE` | Base | Exchange rate against the primary currency, as determined by exchange rate type and value date.
`CURRENCY GEOGRAPHY ENTITY ASSIGNMENT` | Reference | Assigns currency usage to a geographic area.
`CUSTOMER` | Reference | Information pertaining to customers.
`CUSTOMER ACQUISITION SUMMARY DAY DRVD` | Derived | Aggregate daily new customer count by PRODUCT.
`CUSTOMER ACQUISITION SUMMARY MONTH AGGR` | Aggregate | Monthly summary of newly acquired customers by PRODUCT.
`CUSTOMER CLASS` | Lookup | Lookup for Customer Classification codes. For example: HLCU-High Local Call Usage Customers HNCU-High National Call Usage Customers HINCU-High InterNational Call Usage Customers
`CUSTOMER CLASS ASSIGNMENT` | 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.
`CUSTOMER COST` | Base | Subtype of COST which applies to a customer. For example, the cost of a gift that is sent to a customer.
`CUSTOMER DEBT COLLECTION MONTH AGGR` | Aggregate | Statistics on Customer fraud and debt collection.
`CUSTOMER DEBT COLLECTION DRVD` | Derived | Monthly summary of customer fraud and debt collection.
`CUSTOMER DOCUMENT` | Reference | Various types of customer proof documents provided for a CUSTOMER ORDER, contract, and so on.
`CUSTOMER EQUIPMENT INSTALLATION DAY DRVD` | 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
`CUSTOMER EQUIPMENT INSTALLATION MO AGGR` | Aggregate | Monthly summary of customer equipment installation activities. These statistics typically include: modems, routers, or DSL boxes for internet and Television equipment.
`CUSTOMER FACING SERVICE` | Reference | This is the base entity for defining CUSTOMER FACING SERVICEs. A CUSTOMER FACING SERVICE is an abstraction that defines the characteristics and behavior of a particular SERVICE as seen by the Customer or other appropriate PARTY ROLE. Thus, this PARTY ROLE purchases, leases, uses, and/or is otherwise directly aware of this type of SERVICE. This is in direct contrast to RESOURCE FACING SERVICEs which support CUSTOMER FACING SERVICEs but are not seen or purchased directly by the Customer. For example, a VPN is an example of a CUSTOMER FACING SERVICE, while the sub-services that perform different types of routing between network devices making up the VPN are examples of RESOURCE FACING SERVICEs.
`CUSTOMER FACING SERVICE ROLE` | 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.
`CUSTOMER FACING SERVICE SPEC` | Lookup | This is the base entity for defining Customer Facing Service Specifications. A Customer Facing Service Specification is an abstraction that defines the invariant characteristics and behavior of a particular CUSTOMER FACING SERVICE as seen by the Customer. The invariant portion serves as a single common basis to build a set of variable CUSTOMER FACING SERVICEs that all use this common Customer Facing Service Specification.
`CUSTOMER FACING SERVICE SPEC ATOMIC` | Lookup | This entity defines CUSTOMER FACING SERVICE SPECs that do not have any subordinate CUSTOMER FACING SERVICE SPECs. In other words, a Customer Facing Service Spec Atomic is a standalone CUSTOMER FACING SERVICE SPEC, and does not require any supporting CUSTOMER FACING SERVICE SPECs to define the invariant characteristics (that is, non-changing attributes, methods, relationships, and constraints) of any CUSTOMER FACING SERVICEs that it serves as a template for.
`CUSTOMER FACING SERVICE SPEC COMPOSITE` | Lookup | This entity defines an integrated set of CUSTOMER FACING SERVICEs that collectively meets the needs of a SERVICE requested by a Customer. For example, the Customer may have requested GoldService, which is a SERVICE PACKAGE that defines a set of SERVICE BUNDLEs, each of which has its own QoS. Each individual CUSTOMER FACING SERVICE that is part of the SERVICE PACKAGE can be derived from a CUSTOMER FACING SERVICE SPEC. In this case, a Customer Facing Service Spec Composite will aggregate all of the individual CUSTOMER FACING SERVICE SPECs into a single named object. This object is a standalone object. However, it consists of other Customer Facing Service Spec Composite and/or the CUSTOMER FACING SERVICE SPEC ATOMIC entities. That is the primary difference between this entity and the Customer Facing Service Spec Atomic entity.
`CUSTOMER FACING SERVICE SPEC ROLE` | 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.
`CUSTOMER FACING SERVICE SPEC VERSION` | Reference | Keeps the historical versions of CUSTOMER FACING SERVICE SPEC.
`CUSTOMER FIELD INSTALLATION` | Base | The activities to install services at the customer site. For example: Broadband model installation (xDSL modem, cable modem) Pay TV (Digital) installation with set-top box
`CUSTOMER FIELD SERVICE ACTIVITY` | Base | On site installation for the customer with particular equipment instance.
`CUSTOMER FIELD SERVICE DETAIL` | Base | Details regarding customer service.
`CUSTOMER FIELD SUPPORT` | Base | The activities of providing on site support to a customer.
`CUSTOMER GROUP` | Lookup | The lookup code for grouping the customers based on any criterias defined by the service operator.
`CUSTOMER GROUP ASSIGNMENT` | Reference | A grouping of the customers based on any criterias defined by the service operator.
`CUSTOMER INDIVIDUAL` | Reference | Subtype of CUSTOMER (and PARTY), which contains details of individuals as opposed to organizations.
`CUSTOMER LTV BAND` | Lookup | The band of customer life time value that is predicted from the data mining model. For example, 0~100 USD, 100~200 USD, and so on.
`CUSTOMER MINING` | Derived | The result measures from mining analysis, including churn probabilities, Life Time Value (LTV) mining, and other result measures.
`CUSTOMER OCCASION` | Reference | Event celebrated or observed by a customer. For example: Birthday Anniversary Company establishment day
`CUSTOMER OCCASION TYPE` | Lookup | Lookup for occasion type. For example: Wedding Anniversary, Birthday, Company founding anniversary, and so on.
`CUSTOMER ORDER` | 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.
`CUSTOMER ORDER DOCUMENT` | Reference | The document provided while submitted CUSTOMER ORDER.
`CUSTOMER ORDER LINE ITEM` | Base | Details regarding items in the CUSTOMER ORDER.
`CUSTOMER ORDER LINE ITEM STATE ASSIGN` | Base | Current state of an order line item.
`CUSTOMER ORDER PAYMENT` | Base | Payments applied to a CUSTOMER ORDER.
`CUSTOMER ORDER PRIORITY TYPE` | Lookup | Lookup for possible priorities which can be assigned to a CUSTOMER ORDER.
`CUSTOMER ORDER STATE ASSIGNMENT` | Base | Current state of a CUSTOMER ORDER.
`CUSTOMER ORDER STATE CHANGE REASON` | Lookup | All type of reason for customer order state and customer order line item state changes.
`CUSTOMER ORGANIZATION` | 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).
`CUSTOMER RESTRICTED INFO` | Reference | Detail information about a customer that may be deemed private.
`CUSTOMER REVENUE BAND` | Lookup | Entity contains a customer classification in revenue terms. For example: Customer with charges between $100 to $200.
`CUSTOMER REVENUE BAND ASSIGNMENT` | Reference | Assigns a revenue band to a customer.
`CUSTOMER REVENUE TYPE` | Lookup | Lookup for types of revenue a customer may bring to the operator. For example: Recharging Rent fee One time equipment purchase
`CUSTOMER SCORE` | Reference | Scores or Score ranges that may be assigned to a customer based on credit, behavior, or other criteria. For example: 1, 2, 3, 4, 5 1-10, 11-20
`CUSTOMER SEGMENT` | Reference | Market or customer segments to which customer may be assigned.
`CUSTOMER SEGMENTATION MODEL` | Reference | The segmentation model used to profile the customers. For example: KMeans by Revenue from Market Department O-Clustering by IT department
`CUSTOMER SENTIMENT` | Lookup | Lookup for the various customer feelings as reported during a party interaction (on the phone, as email, or from simple mail). The value can be used for text mining. For example: Angry Happy Neutral
`CUSTOMER SIC ASSIGNMENT` | Reference | Assigns SIC/NASIC code to customers.
`CUSTOMER SOURCE` | Reference | Initial source or contact with customer. For example: Sales campaign Advertisement Call center Dealer
`CUSTOMER TYPE` | Lookup | Lookup for type of customer. For example: Individual or Corporate.

Table 2-24 D to F Entity Descriptions

Entity Name | Type | Description
--- | --- | ---
`DATA SERVICE EVENT` | Base | Data Service Events. For example Fixed Line modem dial Broadband access GPRS service
`DATA USAGE DAY DRVD` | Derived | Daily aggregate of data usage.
`DATA USAGE MONTH AGGR` | Aggregate | Monthly aggregate of data usage.
`DAY` | Reference | Defines day, the lowest level of all calendars.
`DAY ACTUAL CONDITION` | Reference | Weather, external and internal conditions that may have impacted performance on a given day at a given location.
`DAY TODATE TRANSFORMATION` | Reference | Documents how todate transformation can be implemented at day level.
`DAY TRANSFORMATION` | 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.
`DEAL` | 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.
`DEAL VENDOR ITEM ASSIGNMENT` | 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.
`DEALER` | Reference | The PARTY who resells products from the operator.
`DEALER DISCOUNT GROUP ASSIGNMENT` | Reference | Assigns DEALER to a discount group(s).
`DEBT AGING BAND` | Lookup | Ranges of time used to group debt based on the age of the debt. For example: 0-90 days 91-180 days
`DEBT COLLECTION` | Base | A special type of interaction to collect defaulted payment from a customer by the in-house debt collector.
`DEBT COLLECTION ASSIGNMENT` | Base | The assignment of a debt collection case to an external debt collection agency.
`DEBT COLLECTION ASSIGNMENT BATCH` | Base | Grouping of collection assignments sent to collector.
`DEMOGRAPHIC CHARACTERISTIC` | Reference | A feature or quality used to make recognizable or to define somebody or something, such as age, income, education, revenue, and so forth.
`DEMOGRAPHIC CHARACTERISTIC VALUE` | Reference | A single value or range of values that defines a DEMOGRAPHIC CHARACTERISTIC.
`DEMOGRAPHY ATTRIBUTE` | Reference | User defined demographic attributes that can be assigned values.
`DEMOGRAPHY GROUP` | Reference | The domain of classifications used to group profile information about a PARTY. For example: CH - Credit History ED- Education EM - Employment EQ- Equipment HB - Hobbies HH - Household OR - Organization And other relevant demographics and psychographics.
`DERIVED VALUE` | Reference | Derived value of the customer based on predetermined criteria.
`DESTINATION TYPE` | Lookup | Lookup for the types of call source destinations. For example: National International Particular continent
`DEVICE INTERFACE` | Reference | This is a concrete entity that represents the (logical) interface or sub-interface of a device. This entity is not a transmission entity; rather, DEVICE INTERFACEs are used to program SERVICEs and LOGICAL ELEMENTs on a Device. For example, use a Device Interface to program a logical connection from a device to a network medium. Different types of Device Interfaces exist for the different types of network media. For example IP compared with ATM, that are used in a network to enable such media to be programmed. The combination of a LOGICAL DEVICE and a Device Interface is what a developer programs to define SERVICEs that run on the device.
`DEVICE INTERFACE DETAIL` | 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.
`DEVICE INTERFACE PHYSICAL PORT ASSIGNMENT` | Lookup | Defines which PHYSICAL PORT can support which DEVICE INTERFACE.
`DEVICE INTERFACE ROLE` | Reference | Represents different types of roles that can be associated with a particular DEVICE INTERFACE.
`DEVICE INTERFACE TP ASSIGNMENT` | Reference | Defines the relationship between DEVICE INTERFACE and TERMINATION POINT.
`DIRECT DEBIT STATUS REASON` | Lookup | Lookup for the various reasons the current status is direct debit payment. For example: Customer preferred choice: when the customer does not want to use a credit card. Customer imposed: which means the CSP imposes this status after problems with credit card or cash payments.
`DISCOUNT GROUP` | Reference | Discount groups that employees or partners may be a part of.
`DISCOUNT SBRP PRICE ALTERATION` | Reference | A discount, a reduction of price, for a SUBSCRIPTION.
`DISTANCE BAND` | Lookup | Distance ranges to characterize network events by geographical distance.
`DIVERT RETRIEVE REASON` | Lookup | Lookup for all reasons for diverting a call or retrieving a call from a Mailbox. For example: Line busy (divert) Line off (divert) No answer (divert) Customer originated (divert / retrieve) Mailbox originated (retrieve only)
`DIVERT RETRIEVE TYPE` | Lookup | Lookup for types for diverting a call or retrieving a call. For example: Divert Retrieve 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.
`DOCUMENT CONDITION TYPE` | Lookup | Lookup for possible document condition types. For example: Complete Incomplete Unavailable
`DOCUMENT TYPE` | Lookup | Lookup for document types. For example: Driver license photocopy Address certification Bank card photocopy
`DOCUMENT TYPE GROUP` | Lookup | The group of DOCUMENT TYPEs of which customer may provide to service provider for identification. For example: Mandatory Document Legal Requirement Income Proof Document
`DOCUMENT TYPE GROUP ASSIGNMENT` | Reference | Assigns different DOCUMENT TYPEs into different DOCUMENT TYPE GROUPs.
`DSL MODEM` | Reference | The xDSL modem to implement Broadband on copper wire (router).
`EDGE INTERFACE` | 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.
`EDUCATION` | Lookup | Demographic education levels that may be assigned to customers.
`ELEMENT CHARACTERISTIC` | Reference | A characteristic quality or distinctive feature of an Element Specification. The characteristic can take on a discrete value, such as color, can take on a range of values, for example, sensitivity of 100-240 mV, or can be derived from a formula for example, usage time (hrs) = 30 - talk time *3. Certain characteristics, such as color, may be configured during the ordering or some other process.
`ELEMENT CHARACTERISTIC ASSIGNMENT` | Reference | A use of the Element Spec Characteristic by an Service Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Element Spec Characteristic.
`ELEMENT CHARACTERISTIC RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between or among Element Spec Characteristics.
`ELEMENT CHARACTERISTIC VALUE` | Reference | A number or text that can be assigned to an Element Spec Characteristic.
`ELEMENT CHARACTERISTIC VALUE ASSIGNMENT` | Reference | A use of the Element Spec Characteristic Value by an Entity Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Element Spec Characteristic Value.
`ELEMENT CHARACTERISTIC VALUE RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between or among Element Spec Characteristic Values.
`EMPLOYEE` | Reference | Subtype of individual indicating an employee of the provider.
`EMPLOYEE ACTUAL LABOR HOURLY` | Base | Worked shifts by hourly employees.
`EMPLOYEE ACTUAL LABOR SALARIED` | Base | Worked shifts by salaried employees.
`EMPLOYEE COST` | Base | Subtype of COST, which applies to employee. For example, salary and bonus for employee.
`EMPLOYEE DESIGNATION` | Lookup | The various designations present in an organization for the employees. For example: Call Center Agent Manager Customer Care Consultant Principal Consultant
`EMPLOYEE DISCOUNT GROUP ASSIGNMENT` | Reference | Assigns EMPLOYEE to DISCOUNT GROUP(s).
`EMPLOYEE EXPENSE REPORT` | 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.
`EMPLOYEE EXPENSE REPORT ITEM` | Base | The detail line item of each expense report.
`EMPLOYEE JOB ROLE ASSIGNMENT` | Reference | Assigns EMPLOYEE to JOB ROLE(s).
`EMPLOYEE JOB ROLE TYPE` | Lookup | Relevance of job role assignment to employee. For example: Primary, Secondary, and so on.
`EMPLOYEE LANGUAGE CAPABILITY` | Reference | Specifies the languages the employee can use to serve customers, especially for call center agents and sales representatives.
`EMPLOYEE RESTRICTED INFO` | Reference | Detail information about the EMPLOYEE that may be deemed private.
`EMPLOYEE SCHEDULE` | Reference | Planned staffing schedule of location, role, shift, and employees.
`EMPLOYEE TRAINING RECORD` | 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.
`EMPLOYEE TYPE` | Lookup | Lookup of employee type. For example: Part-Time Contractual Full-Time
`ENTITY` | Reference | This entity represents entities that cannot be directly managed. For example, a hub.
`ENTITY ROLE` | 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.
`ENTITY SPECIFICATION` | Reference | This is an abstract base entity that defines the invariant characteristics, attributes, methods, constraints, and relationships, of another entity.
`EQUIPMENT` | 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.
`EQUIPMENT CENTER` | Reference | Facility housing devices.
`EQUIPMENT CENTER COST` | Base | Subtype of COST, which collects all costs that are specifically related to a given EQUIPMENT CENTER (facility rent, taxes, and so on).
`EQUIPMENT FUNCTIONALITY` | Reference | The function of the EQUIPMENT. For example: Make wireless calls Send SMS Send MMS
`EQUIPMENT FUNCTIONALITY ASSIGNMENT` | Reference | Assigns functionality to EQUIPMENT.
`EQUIPMENT HOLDER` | 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.
`EQUIPMENT INSTANCE` | Reference | Implement communications. For example: Handset (with IMEI) Land line phone (with serial number) Set-top box Cable modem
`EQUIPMENT INSTANCE RENTING CONTRACT` | Reference | Subtype of CONTRACT in which customers lease some EQUIPMENT. This equipment still belongs to the service provider. When a contract terminates the device should be returned to the service provider. For example: ADSL modem lease Handset short term renting
`EQUIPMENT INSTANCE STATUS HISTORY` | Base | A history of the status for an EQUIPMENT INSTANCE. For example: New Broken Returned Lost Reserved (for VIP loyalty program customer)
`EQUIPMENT INSTANCE STATUS TYPE` | Lookup | Lookup for type of specific equipment instance status type. For example: Purchased from vendor In inventory In customer Broken Reserved
`EQUIPMENT SUBSCRIPTION` | Reference | A subtype of SUBSCRIPTION to track tangible device usage by the customer.
`EQUIPMENT TYPE` | Lookup | The lookup code for type of (customer side) equipment. For example: ADSL Modem 3G data card
`ERRORED MEDIATED CALL EVENT` | Base | The errored/recycled mediated event record from billing engine.
`ERRORED RATED WIRELESS CALL EVENT` | Base | The errored/recycled rated event record from billing engine.
`ERRORED RAW WIRELESS CALL EVENT` | Base | The errored/recycled/rejected raw event record from the mediation process.
`EVENT` | 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.
`EVENT ACCESS METHOD ACTIVITY` | Base | Occurrence of Access Method Usage.
`EVENT ACCOUNT` | Base | Events occurring on an account. For example: Account create Account suspension/resume Line (account) termination attempted (convinced back by representatives) Line termination
`EVENT ASSIGNMENT` | Base | Describes relationship between unique events.
`EVENT ASSIGNMENT REASON` | Lookup | Lookup for all possible reasons why a relationship exists between two EVENTs. For example: Premise Result in
`EVENT ASSIGNMENT TYPE` | Lookup | Lookup for all types of relationships between two EVENTs.
`EVENT CATEGORY` | Lookup | Lookup for EVENT CATEGORY which is further grouped into EVENT TYPE. For example: Loyalty Program Event Access Method Event
`EVENT CIRCUIT RENTAL` | Base | Subtype of "Non Network Events", corresponding to the rental of a fixed line (broadband or phone line). The rental normally incurs charges for various type of activities. For example: Initial Installation Maintenance Check Termination
`EVENT CLASS` | Lookup | Lookup for the classification for the types of EVENTs that can occur. For example: IN: involves only Communications Service Provider OUT: involves customer
`EVENT COST` | Base | Subtype of COST, which is specifically related to a given EVENT. This cost is usually for a non-network event such as an interaction with a customer. For example, for on-site maintenance after a service issue or a break-down.
`EVENT EMIT DETAIL` | 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.
`EVENT EMPLOYEE PAYROLL` | Base | Event in which payroll payment was made to an employee (excludes sales commission). Subtype of EVENT.
`EVENT EQUIPMENT INSTANCE` | Base | Events per instance of EQUIPMENT. Subtype of EVENT.
`EVENT FINANCIAL` | Base | Financial event involving an account or billing statement. Subtype of EVENT.
`EVENT GEOGRAPHY` | Base | Events affecting a Geographic Area that may have an impact on a provider's business. Subtype of EVENT. For example: Earthquake Power Outage Labor Strike
`EVENT GIFT REDEMPTION` | Base | A gift redemption event occurred for a contract or subscription; normally because of a product market plan promotion. Operators may also give away gift items because of events such as a wrong billing. The redemption does not involve a LOYALTY PROGRAM.
`EVENT INVOICE DELIVERY` | Base | The delivery of invoice to customer. For example: Printed letter Email Duplicate printed letter on request
`EVENT LOCATION` | Reference | Assigns an address location to the EVENT.
`EVENT LOYALTY PROGRAM` | Base | Events associated with each event or transaction on a customer loyalty program. For example: Loyalty points earned by the customer Bonus points awarded to the customer Points redeemed by the customer
`EVENT LOYALTY PROGRAM ACCUMULATION` | Base | Subtype of EVENT LOYALTY PROGRAM, where a customer receives loyalty program points, a credit, based on network usage, a payment, or some other event.
`EVENT LOYALTY PROGRAM REDEMPTION` | Base | Subtype of EVENT LOYALTY PROGRAM, where a customer uses loyalty program points, a credit, to redeem gift items including cash placed in their account balance or some other redemption gift item such as a toy.
`EVENT PARTY ASSIGNMENT` | Base | Many to many relationship assigning a party or multiple parties to event(s).
`EVENT PARTY INTERACTION` | Base | Interactions or communications with the customer. For example: Faults Inbound and outbound telemarketing Direct mail SMS Email Service calls Complaints Debt collection
`EVENT PARTY INTERACTION CALL` | Base | Subtype of EVENT PARTY INTERACTION which represents all phone call interactions from the customer with detailed information including: Hold time Queue time Interaction time Run by the Automated Voice Response (AVR)
`EVENT PARTY INTERACTION EMAIL` | Base | Subtype of EVENT PARTY INTERACTION which represents email interaction from customers.
`EVENT PARTY INTERACTION LETTER` | Base | Subtype of EVENT PARTY INTERACTION which represents the interaction with customers through letters.
`EVENT PARTY INTERACTION VISIT` | Base | Visits to a store by a customer. Subtype of EVENT.
`EVENT PARTY PROFILE` | Base | Event in which party profile information was modified or updated.
`EVENT PARTY ROLE` | Reference | Role played by a PARTY in an EVENT. For example: Customer who reported the event Customer affected by event Party who caused the event
`EVENT PREPAID MOBILE` | Base | Actions involving PREPAID MOBILE EVENT TYPE account. Subtype of EVENT ACCOUNT. For example: Initial activation Recharges Adjustments Deactivation
`EVENT PRODUCT PACKAGE` | Base | Events associated with an offer or PRODUCT PACKAGE. Subtype of EVENT.
`EVENT REASON` | Lookup | Lookup for event reasons. For example: arrearage.
`EVENT REASON CATEGORY` | Lookup | Lookup for event reason categories. Categories are further grouped into event reasons.
`EVENT RESOLUTION` | Reference | The domain of results that may occur in the resolution of an EVENT.
`EVENT RESPONSE REASON` | Lookup | Lookup for possible response reasons that may be used in an EVENT.
`EVENT RESULT` | Lookup | Lookup for the description of a result or any events. For example: Successfully processed Escalated Refused by CSP Refused by customer Failed – Impossible Failed – process error
`EVENT SIM CARD` | Base | Events associated with a SIM CARD. Subtype of EVENT.
`EVENT STATUS` | Base | Lookup for event status. For example: Completed Pending In-Progress Suspended Cancelled Abandoned
`EVENT STATUS REASON` | Lookup | Lookup for event status reasons. For example: Insufficient funds Stolen card
`EVENT STATUS TYPE` | Lookup | Lookup for EVENT STATUS. For example: Complete Pending In-Progress Suspended Cancelled Abandoned
`EVENT SUBSCRIPTION` | Base | Events associated with a subscription. Subtype of EVENT. For example: Subscription activation Reimbursement on prepaid account Termination Suspension because of insufficient deposit
`EVENT SUBSCRIPTION CHANGE` | Base | Events involving temporal provisioning and relinquishment of products and services to current subscription base.
`EVENT TRIGGER DETAIL` | Reference | Tracks the execution, evaluation of POLICY RULE on each POLICY EVENT.
`EVENT TYPE` | Lookup | Lookup for event type. For example: In Loyalty Program Event 1.1 Points Accumulation 1.2 Redemption Access Method Event 2.1 Access Method Login (connect) 2.2 Access Method Logout (disconnect) 2.3 Access Method Suspension (because of late payment or other reason)
`EVENT WEB REGISTRATION` | Base | The event of a customer registering at Web site to apply for service.
`EVENT WEB VISIT` | Base | Subtype of Customer Interaction event, to track the customer visit on a service provider Web site.
`EXCLUDE PORT DETAIL` | Reference | The attribute exclusionFunction is designed to be populated from an external management system, and represents the criteria for excluding one or more Element Ports. A predefined exclusion function is to limit the role that a Element Port plays to an edge role. However, this entity enables additional functions to be used to exclude Element Ports.
`EXTERNAL CREDIT PROFILE` | Reference | A source of information that helps define the credit worthiness of the customer.
`EXTERNAL CREDIT PROFILE ASSIGNMENT` | Reference | Indicate which external agency or institute provided the credit profile for the given customer.
`EXTERNAL DEBT COLLECTION DAY DRVD` | Derived | Daily collections by external collector.
`EXTERNAL DEBT COLLECTION MONTH AGGR` | Aggregate | Monthly collections by external collector.
`EXTERNAL INFORMATION SOURCE` | Reference | Source from which the demographic information or customer information is obtained.
`EXTERNAL OPERATOR` | Reference | All operators the Service Provider does business with, including inland competitors or roaming partners.
`EXTERNAL ORGANIZATION TYPE` | Lookup | Lookup for types of external organizations.
`FACTOR COMPANY` | Reference | Stores the information about the factor company, which is the financial instrument holding the receivables.
`FAULT RESOLUTION TYPE` | Lookup | Lookup for available types of network fault resolution.
`FAULT TYPE` | Lookup | Lookup for available types of faults.
`FIELD ACTIVITY RESULT TYPE` | Lookup | Lookup for available result types for customer field activities that are performed by support engineers. For example: S - Successful F - Failed
`FIELD ACTIVITY TYPE` | Lookup | Lookup for types of customer field activities that may be performed by support engineers. For example: Installation Troubleshooting Upgrade
`FISCAL HALF MONTH` | Reference | Defines half-month in a fiscal calendar.
`FISCAL HALF YEAR` | Reference | Defines half-year in a fiscal calendar.
`FISCAL MONTH` | Reference | Defines month in a fiscal calendar.
`FISCAL QUARTER` | Reference | Defines quarter in a fiscal calendar.
`FISCAL WEEK` | Reference | Defines week in a fiscal calendar.
`FISCAL YEAR` | Reference | Defines year in a fiscal calendar.
`FIREWALL ROLE` | 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.
`FIXED LINE` | Reference | Subtype of PRODUCT that provides detailed information on the fixed line service.
`FIXED LINE CALL EVENT` | Base | Event involving a call made on a Fixed Line telephone.
`FIXED LINE PORT` | 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.
`FIXED LINE RATING PLAN` | Reference | Subtype of PRODUCT RATING PLAN associated only with Fixed Lines.
`FLEXIBLE CHARACTERISTIC` | 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.
`FLEXIBLE CHARACTERISTIC ASSIGNMENT` | Reference | Assigns the characteristic to the subject.
`FLEXIBLE CHARACTERISTIC ASSIGNMENT TYPE` | Reference | Lookup of ASSIGNMENT TYPE. For example: Depending on Having feature of Conflict with
`FLEXIBLE CHARACTERISTIC RELATIONSHIP` | Reference | Relationship between characteristics, for example, one characteristic may conflict with another.
`FLEXIBLE CHARACTERISTIC TYPE` | Reference | Lookup of FLEXIBLE CHARACTERISTIC types.
`FLEXIBLE CHARACTERISTIC VALUE` | Reference | Possible values that a characteristic may take, including predefined choices or free numeric values.
`FLEXIBLE CHARACTERISTIC VALUE ASSIGNMENT` | Reference | Assigns the characteristic value to the applicable subject.
`FLEXIBLE CHARACTERISTIC VALUE RELATIONSHIP` | Reference | Relationship between two flexible characteristic values. For example, exclusiveness, same as, and so on.
`FRAUD PROFILE CLASS` | Lookup | Lookup for all possible classes of fraud profile that customers or dealers may commit.

Table 2-25 G to J Entity Descriptions

Entity Name | Type | Description
--- | --- | ---
`GENDER` | Lookup | Lookup for gender.
`GEOGRAPHY BUILDING` | Reference | Building level in GEOGRAPHY HIERARCHY.
`GEOGRAPHY CITY` | Reference | Cities defined in a Geography.
`GEOGRAPHY COUNTRY` | Reference | Countries defined in a Geography.
`GEOGRAPHY COUNTY` | Reference | Counties defined in a Geography.
`GEOGRAPHY DEMOGRAPHIC GROUP` | Reference | User-defined classification for DEMOGRAPHY ATTRIBUTEs.
`GEOGRAPHY DEMOGRAPHY ATTRIBUTE` | Reference | User defined attributes to describe demographic information for a given Geography.
`GEOGRAPHY DEMOGRAPHY VALUE` | Reference | User defined values corresponding to the DEMOGRAPHY ATTRIBUTEs.
`GEOGRAPHY ENTITY` | Reference | User defined geographic units.
`GEOGRAPHY ENTITY ASSIGNMENT` | Reference | Assignment of GEOGRAPHY ENTITYs to a user defined hierarchy level.
`GEOGRAPHY ENTITY HIER LEVEL ASSIGNMENT` | Reference | Assigns GEOGRAPHY ENTITYs to GEOGRAPHY HIERARCHY LEVELs.
`GEOGRAPHY HIERARCHY` | Reference | User defined geographic hierarchies.
`GEOGRAPHY HIERARCHY LEVEL` | Reference | User defined levels within a geographic hierarchy.
`GEOGRAPHY HIERARCHY LEVEL ASSIGNMENT` | Reference | Assignment of a GEOGRAPHY HIERARCHY level to a GEOGRAPHY ENTITY.
`GEOGRAPHY LEVEL` | Reference | User defined name and descriptions for GEOGRAPHY HIERARCHY LEVEL.
`GEOGRAPHY LEVEL ATTRIBUTE` | Reference | User defined attributes associated with a GEOGRAPHY LEVEL.
`GEOGRAPHY LEVEL ATTRIBUTE VALUE` | Reference | Values assigned to the GEOGRAPHY LEVEL ATTRIBUTEs.
`GEOGRAPHY NEIGHBORHOOD` | Reference | Defines a neighborhood in GEOGRAPHY HIERARCHY.
`GEOGRAPHY REGION` | Reference | Defines a region in a Geography.
`GEOGRAPHY STATE` | Reference | Defines a state in a Geography.
`GEOGRAPHY STREET` | Reference | Defines a city in GEOGRAPHY HIERARCHY.
`GEOGRAPHY SUB REGION` | Reference | Defines a subregion in a Geography.
`GEOGRAPHY WORLD` | Reference | Top level of Geography.
`GIVE AWAY ITEM DAY DRVD` | Derived | Statistics of all give away items to the customer for promotion or retention purposes.
`GIVE AWAY ITEM MONTH AGGR` | Aggregate | Monthly aggregation of all give away items given to customers for promotion or retention purposes.
`GIVE AWAY TYPE` | Lookup | Lookup for types of give-aways.
`GL REFERENCE` | Reference | Groups or Categories referred from General Ledger to classify all revenue related activities.
`GPRS PCU DAY DRVD` | Derived | Statistics on the PCU (Packet Control Unit) for the GPRS (General Packet Radio Service) such as bytes sent, bytes received, the transferred data volume, and so on.
`GPRS PCU MONTH AGGR` | Aggregate | Monthly aggregation of statistical values on PCU (Packet Control Unit) for the GPRS (General Packet Radio Service). For example: Bytes sent Bytes received
`GPRS SERVICE` | Reference | Subtype of PRODUCT, with more information about GPRS (General Packet Radio Service). The service provider provides various services such as Internet, WAP to its customers or subscribers over GPRS. The information about the usage of these services is to be analyzed at individual and aggregate level. The GPRS service dimension organizes all GPRS services.
`GPRS SERVICES DAY DRVD` | Derived | Daily summation regarding GPRS services provided to subscribers.
`GPRS SERVICES MONTH AGGR` | Aggregate | Monthly summation regarding GPRS services provided to subscribers.
`HALF HOUR` | Reference | Half-hours defined as part of time.
`HALF MONTH TODATE TRANSFORMATION` | Reference | Todate transformation information at the half-month level.
`HALF MONTH TRANSFORMATION` | Reference | Transformations with respect to half-month. For example: This half-month last year This year last half-month
`HALF YEAR TODATE TRANSFORMATION` | Reference | Cumulative time transformations at the half-year level.
`HALF YEAR TRANSFORMATION` | Reference | Transformations with respect to half-year. For example: This half-year last year This year last half-year
`HANDSET INSTANCE` | Reference | Instance of a handset.
`HANDSET MODEL` | Reference | Models of handsets.
`HANDSET STOCK DAY DRVD` | Derived | Daily Aggregate of Handset Stock statistics by CUSTOMER, SALES CHANNEL, and SALES CHANNEL REPRESENTATIVE.
`HANDSET STOCK MO AGGR` | Aggregate | Monthly Summary of Handset Stock statistics by SALES CHANNEL and SALES CHANNEL REPRESENTATIVE.
`HANDSET SUBSIDY DAY DRVD` | Derived | Daily summation of handset distributions involving gift, discount, or loyalty voucher points.
`HANDSET SUBSIDY MONTH AGGR` | Aggregate | Monthly summation of handset distributions involving gift, discount, or loyalty voucher points.
`HARDWARE` | 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.
`HOLDER ATOMIC` | 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.
`HOLDER COMPOSITE` | 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.
`HOUR` | Reference | Hours defined as part of time.
`HOUSEHOLD` | Reference | Captures household information for the household that the individual customer may belong to.
`IDD` | Reference | Subtype of PRODUCT that provides information about IDD service.
`IDD CALL EVENT` | Base | Event involving an International Direct Dial (IDD) call.
`IN PLATFORM` | Reference | IN (Intelligent Network) platforms operated by the telecom service provider. The Prepaid mobile or toll-free business normally relies on IN platform.
`IN PLATFORM DAY DRVD` | Derived | Daily summation of parameters related to the IN PLATFORM functioning and performance on a daily level.
`IN PLATFORM MONTH AGGR` | Aggregate | Monthly summation of parameters related to the IN PLATFORM functioning and performance on a monthly level.
`IN ROUTING DEVICE` | 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).
`INDIVIDUAL DEMOGRAPHY PROFILE` | Reference | The demographic values for individual customer and customer household.
`INDIVIDUAL DEMOGRAPHY VALUE` | Reference | Values assigned to user-defined DEMOGRAPHY ATTRIBUTEs.
`INDIVIDUAL NAME` | Reference | Records all names used by the individual party along the history.
`INITIATIVE RESULT TYPE` | Lookup | Lookup for all possible results of initiatives. For example, the result is: Becomes a customer Does not become a customer
`INITIATIVE TYPE` | Lookup | Lookup for available initiative types.
`INTERACTION ANSWER CHOICE` | Base | Defined answers, choices, corresponding to initiative questions.
`INTERACTION CHANNEL` | Reference | Channels used for Provider or Customer interactions. For example: Call center Online business system Counter
`INTERACTION DIRECTION` | Lookup | Lookup for available directions for initiatives. For example: Inbound Outbound
`INTERACTION QUESTION RESPONSE` | Base | Responses provided by CUSTOMER to interaction questions.
`INTERACTION REASON` | Lookup | Lookup for interaction reasons. For example: Debt collection Service call Inbound marketing Outbound marketing Customer complaints
`INTERACTION RESULT TYPE` | Lookup | Lookup for possible responses to customer interaction. For example: Showed interest without decision Offer accepted Never call again
`INTERACTION STATUS` | Lookup | Lookup for available interaction status. For example: Planned In-progress Executed Closed
`INTERACTION TYPE` | Lookup | Lookup for types of interactions between company and CUSTOMER. For example: Email Call Center Inbound Call Center Outbound Walk-In to the shop Letter
`INTERNAL DEBT COLLECTION DAY DRVD` | Derived | Daily summary of payment and collection by internal collector.
`INTERNAL DEBT COLLECTION MONTH AGGR` | Aggregate | Monthly summary of payment and collection by internal collector.
`INTERNET ACCESS EVENT` | Base | Subtype of NETWORK EVENT, which captures customer internet surfing history with detailed URL and time information.
`INVOICE` | Base | Invoices issued to accounts representing request for payment for goods and services for a specified period.
`INVOICE ADJUSTMENT` | Base | Adjustments made on the INVOICE.
`INVOICE ADJUSTMENT MONTH AGGR` | Aggregate | Monthly aggregation of calculated measures for all adjustments made on the INVOICEs.
`INVOICE ADJUSTMENT DRVD` | Derived | Calculated measures for all adjustments made on the INVOICEs.
`INVOICE ADJUSTMENT QUOTA` | Reference | Quota of INVOICE ADJUSTMENTs assigned to EMPLOYEE.
`INVOICE ADJUSTMENT REASON` | Lookup | Lookup for the possible reasons for an adjustment on a customer's or on a partner's bill. For example: Service Activation Error Billing Error Goodwill VIP, Loyalty Program, Customer Promotion Event Service downgrade/fault compensation Customer complain
`INVOICE ADJUSTMENT TYPE` | Lookup | Lookup for available adjustment types that may be applied to customer invoices. For example: Direct Total Amount Adjustment Discount Total Bill Amount Adjustment Monthly Fee Adjustment Recharge Fee Adjustment (Prepaid) Activation Fee Adjustment Free-Unit Amount Adjustment Item Charge Adjustment Loyalty Points Adjustment Others
`INVOICE CUSTOMER TYPE AGGR` | Aggregate | Monthly aggregation of all INVOICEs to post paid customers at customer type level.
`INVOICE DELIVERY FORMAT` | Reference | The format specification, including header, font, and so on, of each invoice delivered to the customer.
`INVOICE DELIVERY TYPE` | Lookup | Lookup for available delivery types of INVOICE to customer. For example: Printed letter Email Duplicate printed letter on request
`INVOICE DISCOUNT` | Base | Discount applied to INVOICE.
`INVOICE DISCOUNT REASON` | Lookup | Lookup for available discount reasons.
`INVOICE DISCOUNT TYPE` | Lookup | Lookup for available discount types that may be applied to customer invoice.
`INVOICE DRVD` | 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.
`INVOICE ITEM` | 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: Wireless Call Ringtone Downloading Monthly Fixed Rate
`INVOICE ITEM DETAIL` | Base | Additional details regarding INVOICE ITEM including Product Usage Level.
`INVOICE ITEM DETAIL TYPE` | 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: Call Date Duration Dialed Digits Units Direction Zone Charge Net VAT Total Charge
`INVOICE ITEM RELATIONSHIP` | Base | Define the relationship between INVOICE ITEMs.
`INVOICE ITEM TYPE` | Lookup | Lookup for invoice item types. For example: 1 = Long Distance Minutes of Usage 2 = Access Charge 3 = Monthly Fee 4 = Equipment Charge 5 = Roaming Minutes of Usage 6 = Equipment Rental 7 = Installation Charge 8 = Adjustment or Discount 9 = Call Record Detail
`INVOICE PAYMENT ASSIGNMENT` | Base | Matches the payment to an INVOICE.
`INVOICE PAYMENT TERM` | Reference | Payment terms of each INVOICE. For example: Payment days
`INVOICE PAYMENT TERM TYPE` | Lookup | Lookup for available types of payment terms.
`INVOICE TAX ITEM` | Base | The Tax item applied to the INVOICE.
`INVOICE TYPE` | Lookup | Lookup for type of INVOICE according to invoice generation process. For example: Summary Invoice for hierarchical account Standard Invoice Trial Billing Invoice
`IP ADDRESS` | 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.
`IP ADDRESS POOL` | Reference | Subtype of ACCESS METHOD POOL, which lists all IP addresses available to customers.
`IP SUBNET` | 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.
`IPV4 ADDRESS` | Reference | Refines the generic IP ADDRESS to add formatting capabilities that are specific to IPv4.
`ISP` | Reference | Internet Service Provider (ISP).
`ISP BUSINESS` | Reference | The business that the ISP may provide. For example: Company | Services A $ 45.00 Broadband DSL Access 20Mbps Down, 896Kps Up A $ 25.00 Broadband DSL Access 7Mbps, 896Kps Up A $ 19.99 Broadband DSL Access 1.5Mbps, 896Kps Up A $ x.xx Wireless Broadband or cable modem Access This only covers ISP specific business (not Application Provider business).
`ISP BUSINESS ASSIGNMENT` | 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.
`ISP BUSINESS TYPE` | 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: Virtual private server Dedicated hosting Colocation center Web hosting Free hosting Shared hosting Clustered hosting Reseller hosting Application-specific Blog hosting Image hosting Video hosting Wiki farms File hosting Remote backup service Game server hosting DNS hosting E-mail hosting
`ISP TYPE` | Lookup | Lookup for types of ISPs.
`ISP USAGE EVENT` | 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.
`ISP USER` | Reference | Identifies the user names associated with the Internet Service Provider (ISP) subscription.
`ITEM` | Reference | Details describing the item or PRODUCT.
`ITEM TYPE` | Lookup | Lookup for type of item (PRODUCT).
`JOB` | Reference | The occupation of the customer, which is the principal activity the customer performs to earn money.
`JOB ROLE` | Reference | Job Roles defined in the company that may be assigned to employees. For example: Sales representative Support Product manager Customer representative Call center agent

Table 2-26 K to N Entity Descriptions

Entity Name | Type | Description
--- | --- | ---
`KEY PERFORMANCE INDICATOR SLS PARM` | 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.
`KEY QUALITY INDICATOR SLS PARM` | 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.
`LAN` | 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.
`LAN PROTOCOL` | 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.
`LANGUAGE` | Lookup | Languages spoken or written within the company or in interactions with CUSTOMERs.
`LANGUAGE DIALECT` | Reference | A special type of speaking or written language dialect.
`LAYER NETWORK` | 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.
`LEGAL PROCESS STATUS TYPE` | 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).
`LETTER TYPE` | Lookup | Lookup for available types of letters that may be sent to CUSTOMERs. For example: Direct marketing Legal letter Contract confirmation letter (Welcome)
`LINE ACTIVATION TERMINATION DAY DRVD` | Derived | Statistics for the number of lines activated and terminated every day for each ORGANIZATION BUSINESS UNIT.
`LINE ACTIVATION TERMINATION MONTH AGGR` | Aggregate | Monthly aggregation of numbers of lines activated and terminated for each ORGANIZATION BUSINESS UNIT.
`LOCAL ADDRESS LOCATION` | Reference | The local place within a given geographical address location to locate a specific object, such as a NETWORK ELEMENT.
`LOGICAL CAPACITY` | Reference | This entity represents the minimum and maximum requirements, limits, or other variable features of different types of Managed Entities.
`LOGICAL DEVICE` | 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.
`LOGICAL DEVICE ATOMIC` | 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).
`LOGICAL DEVICE COMPOSITE` | 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).
`LOGICAL DEVICE OS ASSIGNMENT` | 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.
`LOGICAL DEVICE ROLE` | Reference | Defines required logical features to implement the different roles played by different LOGICAL DEVICEs that are used in a PRODUCT or SERVICE.
`LOGICAL DEVICE ROLE SPEC` | 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.
`LOGICAL ELEMENT` | Reference | This entity describes different logical aspects of devices (For example, DEVICE INTERFACEs) that constitute a PRODUCT. The Logical Element has two main purposes. To collect common attributes and relationships for all logical entities. To provide a convenient, single point where relationships with other managed objects can be defined.
`LOGICAL ELEMENT PHYSICAL SUPPORT` | Reference | This is an association entity defined in the LOGICAL ELEMENT model. The Logical Element Physical Support represents the semantics. For example, depends on, uses, and other relationships, that exist when one or more LOGICAL ELEMENTs are used to support a PHYSICAL ELEMENT. This entity should be extended to model the particular semantics involved. When extended, the type OfDependency attribute must be included, since it is a mandatory attribute. However, new values may be added to its enumerated list of values.
`LOGICAL ELEMENT ROLE` | Reference | This entity defines the concept of various types of roles that can be associated with LOGICAL ELEMENTs.
`LOGICAL ELEMENT ROLE ASSIGNMENT` | Reference | Implements the semantics of the Roles Describe Logical Element aggregation.
`LOGICAL ELEMENT ROLE SPEC` | Reference | Entity for all LOGICAL ELEMENT ROLE specification subclasses. The Logical Element Role Spec enables relationships to be defined between it and other classes. This helps prevent relationship explosion. The Logical Element Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with LOGICAL ELEMENTs.
`LOGICAL ELEMENT SPEC` | Lookup | This entity defines the invariant characteristics and behavior (attributes, methods, constraints, and relationships) of a LOGICAL ELEMENT.
`LOGICAL ELEMENT SPEC ATOMIC` | Lookup | This entity describes specific attributes, behavior, relationships, constraints, and semantics for building LOGICAL ELEMENT objects. The purpose of this entity is to track specifications of LOGICAL ELEMENTs separately from other types of Element Specifications. This entity inherits the Modifies Element Spec aggregation, and therefore can be used with the corresponding LOGICAL ELEMENT entity. The difference between this entity and the Logical Element Type Composite entity is that this entity represents standalone specifications of LOGICAL ELEMENT objects. The Logical Element Type Composite entity represents a hierarchy of specifications of LOGICAL ELEMENT objects.
`LOGICAL ELEMENT SPEC COMPOSITE` | Lookup | This entity describes specific attributes, behavior, relationships, constraints, and semantics for building LOGICAL ELEMENT objects. The purpose of this entity is to track specifications of LOGICAL ELEMENT separately from other types of Element Specifications. This entity inherits the Modifies Element Spec aggregation, and therefore can be used with the corresponding LOGICAL ELEMENT entity. The difference between this entity and the Logical Element Type Atomic entity is that this entity represents a hierarchy of specifications for LOGICAL ELEMENTs. The Logical Element Type Atomic entity represents a single standalone specification of a LOGICAL ELEMENT.
`LOGICAL ELEMENT SPEC PHYSICAL SUPPORT` | Reference | This defines the invariant attributes, methods, constraints, and relationships that exist between a particular Logical Element Type and the PHYSICAL ELEMENT SPEC that it depends on.
`LOGICAL ELEMENT TYPE VERSION` | Reference | The purpose of this entity is to track Logical Element Type specifications separately from other types of Element Specifications. This entity inherits the modifiesElementSpec aggregation, and therefore can be used with the corresponding Logical Element Type specification entity.
`LOGICAL INTERFACE` | Reference | An abstract entity that serves as the superclass for all virtual interfaces. Logical interfaces are also called virtual interfaces. This is because a logical interface has no hardware associated with it, and a logical interface is not physically connected to a network. A logical interface serves as a convenient aggregation point for running different relationships that affect its subclasses, thereby avoiding having to instantiate multiple relationships that are essentially the same.
`LOOKUP` | Lookup | Abstract ENTITY for all lookup entities.
`LOYALTY PROGRAM` | Reference | Loyalty programs available to which customers may be members of.
`LOYALTY PROGRAM CHANNEL` | Reference | Channel through which a customer can join, change, or redeem the loyalty program. For example: Online service Call center Shops
`LOYALTY PROGRAM DAY DRVD` | Derived | Daily aggregate of LOYALTY PROGRAM statistics by CUSTOMER, PRODUCT, SALES CHANNEL, LOYALTY PROGRAM CHANNEL, SALES CHANNEL REPRESENTATIVE, AGE ON NET BAND, CREDIT CATEGORY.
`LOYALTY PROGRAM EVENT CATEGORY` | Lookup | Lookup for the types of award updates that can be given to the PARTY. For example: E = Earnings R = Redemption
`LOYALTY PROGRAM EVENT TYPE` | Lookup | Lookup for types of LOYALTY PROGRAM events that could be used in a LOYALTY PROGRAM.
`LOYALTY PROGRAM MO AGGR` | Aggregate | Monthly summary of LOYALTY PROGRAM statistics by PRODUCT, SALES CHANNEL, LOYALTY PROGRAM CHANNEL.
`LOYALTY PROGRAM PARTY ROLE` | Lookup | Lookup for available roles or responsibilities that may be assigned to a PARTY participant of a LOYALTY PROGRAM. For example: Customer Member Internal Officer Manager
`LOYALTY PROGRAM POINTS BALANCE` | Base | Balance points awarded to a PARTY in a LOYALTY PROGRAM.
`LOYALTY PROGRAM TERMINATION REASON` | Lookup | Reasons why a customer terminated the participation of a given LOYALTY PROGRAM.
`MAILBOX` | Reference | Mailbox allocated to a CUSTOMER.
`MANAGE ACTION TYPE` | Lookup | Lookup for type of management action that can be performed on a product market plan. For example: Marketing Manager Creation Marketing Research
`MANAGED ENTITY` | Reference | This is an abstract entity that represents entities in a managed environment that have the following semantics in common: An ENTITY owns or is otherwise responsible for them. Management of the ENTITY is critical for providing a service and/or maintaining the environment. The ENTITY is important from a management point-of-view.
`MANAGED HARDWARE` | 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.
`MANAGED TRANSMISSION ENTITY` | 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.
`MANAGEMENT DOMAIN` | 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.
`MANAGEMENT PROTOCOL` | 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.
`MARITAL STATUS` | Lookup | Lookup for marital status that may be assigned to an individual.
`MARKET AREA` | Reference | A geographic area or region or other connotation for which demographic data are available.
`MARKET AREA LEVEL` | Reference | Hierarchical levels of market area.
`MARKET OPERATOR PORTING DERIVED` | Derived | Monthly porting count between operators. Provides summary information about succeeded Number Porting between operators.
`MARKET PLAN DOCUMENT REQUIREMENT` | Reference | Defines the customer document requirements of each PRODUCT MARKET PLAN.
`MARKET PLAN MANAGEMENT` | Base | The management history of market plan by the employee.
`MARKET PLAN SUBSTITUTE BY DOC` | Reference | Stores the document that allows the customer to access a market plan specific to a certain category of customers (such as Students, Seniors, or unemployed). These market plans usually require a document that proves the validity of the request (for example, income certification or identification documents) that this entity stores.
`MARKET PLAN TERM VALUE` | Reference | The detail term value according to each term for the market plan, including monthly charge.
`MARKET SEGMENT` | Reference | A grouping of Parties, Geographic Areas, Sales Channels, and so forth. MARKET SEGMENTs are the target of Marketing Campaigns, PRODUCT MARKET PLAN, Product Promotions, Product Placements, and Product Programs from both internal and external, COMPETITORs, and other Providers, perspective.
`MARKET SEGMENT CHARACTERISTIC` | 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).
`MARKET SEGMENT CHARACTERISTIC VALUE` | Reference | A number or text that can be assigned to a MARKET SEGMENT CHARACTERISTIC.
`MARKET SEGMENT INCLUSION` | Reference | The inclusion relationship between two MARKET SEGMENTs.
`MARKET SHARE AGGR` | Aggregate | Defines the market information. Monthly summation of Geographic Market Share for a PRODUCT MARKET PLAN.
`MARKET SHARE DRVD` | Derived | Defines the market information. Sales Revenue by Month, Address, and Business Unit.
`MARKET STATISTICS` | Reference | A categorization of performance measures by MARKET SEGMENT. PERFORMANCE is measured for the Service Provider and a Service Provider's COMPETITORs in the market place.
`MARKET STATISTIC INCLUSION` | Reference | Relationship between two market statistics.
`MEDIA INTERFACE` | 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.
`MEDIA OBJECT` | Reference | Any form of media in which a CAMPAIGN MESSAGE may appear. For example: Newspaper page Television time slot
`MEDIA OBJECT ASSIGNMENT` | Reference | Relation of one MEDIA OBJECT to another MEDIA OBJECT.
`MEDIA OBJECT COST` | 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).
`MEDIA OBJECT TYPE` | Lookup | Lookup for available types of MEDIA OBJECTs. For example: Newspaper Television
`MEDIATED CALL EVENT` | 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.
`MEDIATION STATUS CATEGORY` | Lookup | Lookup for category of mediation status, such as successfully mediated or failed.
`MEDIATION STATUS REASON` | Lookup | Lookup for reasons why the network event is at certain mediation status. For example: Corrupted File Missing record
`MEDIATION STATUS TYPE` | Lookup | Lookup of the mediation status of a given raw network event. For example: <Rejected> <Successful>
`MINUTE` | Reference | Defines minutes as part of time.
`MINUTE ALLOWANCE` | Base | Subtype of Account Balance describing the number of 'Free' or 'Prepaid' minutes allocated to Subscriber in a given month.
`MMS` | Reference | Subtype of VALUE ADDED SERVICE and PRODUCT, which contains the information relative to the Multimedia Messaging Service (MMS). Do not confuse with the MMS EVENT itself.
`MMS EVENT` | Base | Subtype of NETWORK EVENT, which collects all information of calls of type Multimedia Messaging Service (MMS).
`MOBILE SWITCHING CENTER` | 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.
`MODEL TYPE` | 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.
`MONTH TODATE TRANSFORMATION` | Reference | Defines related calendar elements for performing to-date time transformations.
`MONTH TRANSFORMATION` | Reference | Transformations with respect to a month. For example: This month last year This year last month
`MSC TRAFFIC DAY DRVD` | Derived | Parameters, configurations, and runtime statistics related to the MSC (Mobile Switch Center) functioning and performance.
`MSC TRAFFIC MONTH AGGR` | Aggregate | Monthly aggregation of parameters, configurations, and runtime statistics related to the MSC (Mobile Switch Center) functioning and performance.
`MUSIC DOWNLOAD` | Reference | Subtype of VALUE ADDED SERVICE and PRODUCT, which contains the information relative to the music downloading service.
`NAICS CLASSIFICATION` | Reference | Specifies classifications in the North American Classification System (NAICS).
`NAICS INDUSTRY` | Reference | Lowest level classification for Industry in the North American Industry Classification System (NAICS).
`NAICS INDUSTRY GROUP` | Reference | Lookup for Classification Groups in the North American Industry Classification System (NAICS).
`NAICS INDUSTRY SECTOR` | Reference | Lookup for Industry Sectors in the North American Industry Classification System (NAICS).
`NAICS INDUSTRY SUBSECTOR` | Reference | Lookup for Industry Sub-sectors in the North American Industry Classification System (NAICS).
`NATIONALITY` | Lookup | Lookup for available nationalities.
`NEGOTIATED SERVICE LEVEL SPEC` | Reference | The negotiated service level spec, compared to predefined SLA spec.
`NETWORK` | Reference | Names and Service Providers for relevant Networks. The full details of a service provider are found in the PARTY and Organizations entities. A Network is a managed object that represents an aggregation of interconnected telecommunications and management objects capable of exchanging information. The reason that a Network is subclassed from Element Collection is that it is important that a Network represents physical and logical characteristics and behavior of this collection of telecommunications and management objects. A Network has the additional semantics of having one or more common characteristics and/or behavior. For example, a network may be owned by a single customer or provider, or be associated with the delivery of a specific set of services. A network may be nested within another (larger) network, thereby forming a containment relationship. An example of a network that is contained in another network is a transmission sub-network. The Network is owned by a single Administration and can only perform transmission functions.
`NETWORK ADDRESS` | 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.
`NETWORK ADDRESS INTERFACE BINDING` | Reference | Defines the semantics of how this NETWORK ADDRESS is contained in this particular DEVICE INTERFACE.
`NETWORK ADDRESS TYPE` | 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.
`NETWORK ASSIGNMENT` | Reference | Defines the relationship between NETWORKs. For example: One network relies on another network to function. One network belongs to another network.
`NETWORK ASSIGNMENT TYPE` | Lookup | Lookup for type of network relationship. For example: Composition (one network include another one) RELY (one network relies on another one)
`NETWORK ATOMIC` | Reference | Represents a standalone Network. Network Atomics may be combined into larger Networks by aggregating them into an appropriate Network Composite object.
`NETWORK AVAILABILITY DAY DRVD` | Derived | Statistics of network availability measures and all outages that happened to the operator's network.
`NETWORK AVAILABILITY MONTH AGGR` | Aggregate | Monthly aggregation of network availability statistics and all outages that happened to the operator's network.
`NETWORK COMPOSITE` | Reference | Represents an aggregation of Network Atomic and possibly Network Composite objects. Each Network Atomic object represents a standalone Network; these can be combined to build larger Networks by choosing the appropriate type of Network Composite object to aggregate Network Atomic objects. Note that a Network Composite object can also aggregate Network Composite objects.
`NETWORK DOMAIN` | 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.
`NETWORK ELEMENT` | Reference | All elements belonging to the network (normally, only of the Communications Service Provider) to deliver the communication services.
`NETWORK ELEMENT BUSINESS INTERACTION ROLE` | Reference | The business interaction role which can be assigned by a NETWORK ELEMENT.
`NETWORK ELEMENT CATEGORY` | Lookup | Category of network elements to further classify NETWORK ELEMENT TYPEs.
`NETWORK ELEMENT COST` | Base | Subtype of the COST, which associate a specific cost to a given NETWORK ELEMENT (purchase, maintenance, recycling, and so on).
`NETWORK ELEMENT FAULT ASSIGNMENT` | Base | Assignment of a NETWORK FAULT to a SUBSCRIPTION.
`NETWORK ELEMENT PARTY ASSOCIATION` | Reference | Defines the semantics of the Owns Element association. In contrast with the Administers Element association, this can be any type of PARTY ROLE, because the issue is ownership, not administration. Administration involves a specific skill set, whereas ownership does not. The semantics of this association includes specifying the time period that this PARTY ROLE can own the Element, along with granting permission to a Value Network Role to administer the Element.
`NETWORK ELEMENT PARTY MANAGEMENT` | Reference | Defines the relationship between party and its managed NETWORK ELEMENT.
`NETWORK ELEMENT PARTY MANAGEMENT HISTORY` | Reference | Defines the semantics of the Administer Element association. This defines that a Value Network Role, and not just any type of PARTY ROLE, is allowed to Administer a Device. The semantics of this association includes specifying the time period that this Value Network Role can administer the Element, along with gaining permission from the Owner of the Element for being able to administer the Element.
`NETWORK ELEMENT RELATIONSHIP` | Reference | The relationship between two NETWORK ELEMENTs. For example, in GSM, multiple BTSs are connected to a BSC, in Broadband, several customer lines may be connected to a DSLAM.
`NETWORK ELEMENT RELATIONSHIP TYPE` | Lookup | The Type of NETWORK ELEMENT RELATIONSHIP. For example: Pair Connected Master-Subordinate Primary-Backup
`NETWORK ELEMENT ROLE` | Reference | This entity defines the concept of various types of roles associated with Resources (both physical and logical).
`NETWORK ELEMENT ROLE ASSIGNMENT` | Reference | Implements the semantics of the Network Element Takes On Roles relationship. The Network Element Role Assignment also serves as the parent entity for defining the classes that implement the Roles Describe Physical Element, Roles Describe LOGICAL ELEMENTs, and Roles Describe Compound Element relationships.
`NETWORK ELEMENT ROLE PARTY ASSIGNMENT` | Reference | Defines the semantics of the Element Roles Managed By Party Role association. The Element Roles Managed By Party Role association defines the set of Element Roles that are managed by a particular PARTY ROLE. Oftentimes, there are important functional differences between different types of Elements that require very different skill sets, methods, and so forth to be used by the PARTY ROLE that is managing that Element. For example, different management personnel may be assigned to manage core routers compared to edge routers. This applies not just to the router as a whole, but to its physical, for example, line cards, and logical. For example, DEVICE INTERFACEs, components. The Network Element Role Party Assignment entity captures these semantics.
`NETWORK ELEMENT ROLE SPEC` | Reference | This is the abstract base entity for all Element Role Specification subclasses. The Network Element Role Spec enables relationships to be defined between it and other network element roles. This helps prevent relationship explosion. The Network Element Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with Elements (both physical and logical).
`NETWORK ELEMENT STATE HISTORY` | Base | Network element State History tracks the state history of each NETWORK ELEMENT, for example, power off, in use, decommissioned, and so on.
`NETWORK ELEMENT TYPE` | Reference | This entity defines the invariant characteristics and behavior (attributes, methods, constraints, and relationships) of a Managed Element.
`NETWORK ELEMENT TYPE VERSION` | Reference | Represents the ability to distinguish between different instances of Element Specifications. The Network Element Type Version represents a particular form or variety of a Element Specification that is different from others or from the original. The form represents differences in attributes, methods, relationships, and/or constraints that characterize this particular Element Specification, but which are not enough to warrant creating a new Element Specification.
`NETWORK ELEMENT TYPE VERSION USAGE` | Reference | Defines the semantics of the modifiesElementSpec aggregation. Specifically, it enables an application to define which set of versions of this Element Specification are appropriate for a given task.
`NETWORK ELEMENT USAGE` | Reference | An occurrence of employing a Element for its intended purpose.
`NETWORK ELEMENT USAGE EVENT TYPE` | Lookup | A detailed description of a network element usage event (for example, a purchase or a lease of a resource).
`NETWORK EVENT` | Base | Abstracted event for all events that happened to the operator network because of customer usage; network events are usually the basis for customer billing.
`NETWORK EVENT ASSIGNMENT` | Base | Defines the relationship between one NETWORK EVENT and another NETWORK EVENT.
`NETWORK EVENT CHARACTERISTIC` | Reference | A detailed description of an attribute that defines a particular type of NETWORK EVENT, described by its name, category, type, presence, and a set of allowed values.
`NETWORK EVENT CHARACTERISTIC ASSIGNMENT` | Reference | How the NETWORK EVENT type utilize a characteristic.
`NETWORK EVENT CHARACTERISTIC RELATIONSHIP` | Reference | The relationship between NETWORK EVENT CHARACTERISTICs, such as aggregation, migration, substitution, dependency, or exclusivity.
`NETWORK EVENT CHARACTERISTIC TYPE` | Reference | A category representing a high-level aspect of the network event information described by the characteristic.
`NETWORK EVENT CHARACTERISTIC VALUE` | Reference | A value of a NETWORK EVENT CHARACTERISTIC that represents an attribute value for the event.
`NETWORK EVENT CHARACTERISTIC VALUE ASSIGNMENT` | Reference | A use of the Characteristic Value by a NETWORK EVENT to which additional properties, attributes, apply or override the properties of similar properties contained in NETWORK EVENT CHARACTERISTIC VALUE.
`NETWORK EVENT CHARACTERISTIC VALUE RELATIONSHIP` | Reference | The relationship between or among NETWORK EVENT CHARACTERISTIC VALUEs, such as aggregation, migration, substitution, dependency, or exclusivity.
`NETWORK EVENT STATUS` | Lookup | Lookup for possible status of NETWORK EVENTs. For example: Mediated Billed
`NETWORK EVENT TYPE` | Lookup | Lookup for available types of NETWORK EVENTs.
`NETWORK EVENT TYPE VERSION` | Reference | A particular form or variety of a NETWORK EVENT TYPE that is different from others or from the original. The form represents differences in properties that characterize a NETWORK EVENT TYPE, that are not enough to warrant creating a new NETWORK EVENT TYPE.
`NETWORK FAULT` | Base | Records each registered fault.
`NETWORK FAULT SUBSCRIPTION ASSIGNMENT` | Base | Links a network issue to all subscriptions impacted, which allows you to list the customer and service impacted by a network fault.
`NETWORK ROUTE` | Reference | Defines a series of locations a network route may pass.
`NETWORK ROUTE POINT` | Reference | The points a NETWORK ROUTE may pass through.
`NETWORK ROUTE POINT ASSIGNMENT` | Reference | Assignment of NETWORK ROUTE POINTs to their NETWORK ROUTE. Multiple NETWORK ROUTEs may share the same NETWORK ROUTE POINT.
`NETWORK SERVICE COVERAGE ASSIGNMENT` | Reference | Defines the relationship between NETWORK TOUCHPOINT and SERVICE COVERAGE AREA.
`NETWORK SITE` | Reference | Specifies a place where NETWORK ELEMENTs are located or installed.
`NETWORK TOUCHPOINT` | 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: BTS in GSM network Customer installation site in ADSL broadband
`NETWORK TOUCHPOINT CLASS` | Lookup | Lookup for available classes of NETWORK TOUCHPOINT. For example: Public Private
`NETWORK TOUCHPOINT MONTH AGGR` | Aggregate | Monthly summary of NETWORK TOUCHPOINTs by CUSTOMER, NETWORK, Address, and so on.
`NETWORK TOUCHPOINT DRVD` | Derived | Monthly summary of NETWORK TOUCHPOINTs by NETWORK, County, and so on.
`NETWORK TOUCHPOINT STATUS` | Lookup | Lookup for Available Status codes and descriptions of NETWORK TOUCHPOINT.
`NETWORK TOUCHPOINT TYPE` | Lookup | Lookup for the type of NETWORK TOUCHPOINT. For example: Cell Site (Wireless) International Switch (roaming partners) Ethernet Socket at Customer site (last mile included - wireline/broadband Switch (wireline - exclusive last mile - wireline/broadband)
`NETWORK TYPE` | Lookup | Lookup for the types of NETWORK. Will include: PSTN GSM CDMA
`NOTIFICATION TYPE` | 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: SMS Internet mail The UMS Notification Type dimension helps to organize the notifications data by notification type, along with other dimensions.
`NP MOBILE MSISDN` | Reference | The mobile MSISDN number of ported number.
`NP REQUEST HEADER` | Base | The Number Porting (NP) Request submitted by a customer (Porting In) or a recipient operator (Porting Out).
`NP REQUEST LINE ITEM` | Base | Request Line Item within a Number Porting (NP) request.
`NP REQUEST LINE ITEM STATE HISTORY` | Base | State history for Number Porting (NP) request line items.
`NP REQUEST LINE ITEM STATE TYPE` | Lookup | Lookup for type of Number Porting (NP) line item state. For example: Passed Pending
`NP REQUEST STATE HISTORY` | Base | State history for the Number Porting (NP) request.
`NP REQUEST STATE TYPE` | Lookup | Lookup for type of state for Number Porting (NP) request. For example: Pre-application Application Document check
`NP REQUEST TYPE` | Lookup | Lookup for type of Number Porting (NP) Request. For example: Porting In Porting Out
`NP STEP` | Lookup | Step involved in the Number Porting (NP) request. For example: Application Document check Notify NPAC
`NUMBER AREA` | Reference | Defines the codes associated to a given area; these codes are typically used for calls to a fixed line number. For example: 1 for Paris (in France) 89 for Munich (in Germany) A number area could also be associated to other operators, and not to a geographical area. For example, 9 in France.
`NUMBER COUNTRY` | Reference | Country number. For example: US-01 China-86
`NUMBER NETWORK TYPE` | Lookup | Lookup for available classifications for the network technology, used in relation to subscriptions. For example: in MICA-GCM: CDMA in Flexcab - NTWK, NNSA, WRBL, and so on
`NUMBER PORT DAY DRVD` | Derived | Aggregation of daily Porting Requests (in/out).
`NUMBER PORT MONTH AGGR` | Aggregate | Monthly summary of Porting Requests (in/out).

Table 2-27 O to R Entity Descriptions

Entity Name | Type | Description
--- | --- | ---
`ON OFF NET TYPE` | Lookup | Lookup of call classifications: On net Off net
`OPERATING SYSTEM` | Reference | An Operating System is a concrete entity that represents either software and/or firmware that runs the LOGICAL ELEMENT. This entity implements and/or manages the Elements, tasks, file systems, security, and data available on the LOGICAL ELEMENT. Note that an Operating System is distinct from software applications that are run on the Element. All applications and software must communicate with the Operating System for all operations that they need.
`OPERATOR GROUP` | Lookup | Classification group for operators. For example, the group can be classified as: Global Direct Competing Local Competitor Allied by Stock Share
`OPERATOR TYPE` | Lookup | Lookup for operator type to classify operators. For example: International Local International operators normally have multiple subsidiaries whose relationship is modeled in the party relationship.
`ORDER LINE ITEM STATE` | Reference | Lookup for the status that a given order line item, in a command, can be assigned. For example: Pending Waiting for Customer feedback Closed Started Error
`ORDER STATE` | Lookup | Lookup for the type of Order State. For example: Open / Processing Pending / Waiting for Customer Feedback Pending / Waiting for Internal Feedback Pending / Waiting for Third Party Feedback Error Closed Cancelled
`ORDER STATUS` | Lookup | Lookup for the type of Order Status. For example: Already Shipped Delivered / Processed Processing Partially Delivered Installed
`ORDER TYPE` | Lookup | Lookup for type of CUSTOMER ORDER. For example: Order for Pickup Order for Delivery Order for Activation
`ORGANIZATION AREA` | Reference | An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION CHAIN. The Organization Area entity is the parent of one or more ORGANIZATION REGIONs.
`ORGANIZATION BANNER` | 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.
`ORGANIZATION BUSINESS ENTITY` | 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.
`ORGANIZATION BUSINESS UNIT` | 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: SuperTelco Communications (Mobile) SuperData (Broadband)
`ORGANIZATION BUSINESS UNIT COST` | Base | Sub-table of COST. This entity associates a specific cost to an ORGANIZATION BUSINESS UNIT (for those costs not covered by EMPLOYEE COST).
`ORGANIZATION BUSINESS UNIT TYPE` | Lookup | Lookup for type of ORGANIZATION BUSINESS UNIT. For example: Call Center Branch Office Warehouse
`ORGANIZATION CHAIN` | Reference | An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION COMPANY. Organization Chain entity is the parent of one or more ORGANIZATION AREAs.
`ORGANIZATION COMPANY` | Reference | An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION CORPORATE. Organization Company entity is the parent of one or more ORGANIZATION CHAINs.
`ORGANIZATION CORPORATE` | Reference | Highest level of ORGANIZATION HIERARCHY. Organization Corporate entity is the parent of one or more ORGANIZATION COMPANYs.
`ORGANIZATION DISTRICT` | Reference | An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION REGION. Organization District entity is the parent of one or more ORGANIZATION BUSINESS UNITs.
`ORGANIZATION DIVISION` | Reference | An ORGANIZATION HIERARCHY LEVEL within ORGANIZATION CORPORATE.
`ORGANIZATION HIERARCHY` | Reference | User defined. Master list of all of the hierarchies in an organization.
`ORGANIZATION HIERARCHY LEVEL` | Reference | The association entity for the hierarchies and levels.
`ORGANIZATION HIERARCHY LEVEL ASSIGNMENT` | Reference | Assignment of Hierarchy Levels to ORGANIZATION HIERARCHY.
`ORGANIZATION HIERARCHY VERSION` | Reference | Version of ORGANIZATION HIERARCHY.
`ORGANIZATION ITEM SELLING PRICE` | Reference | Associate selling price to the item. Each organization might have different prices for the same item model.
`ORGANIZATION LEVEL` | Reference | List of all the business levels within an organization.
`ORGANIZATION LEVEL ATTRIBUTE VALUE` | Reference | Values for the user defined attributes associated with an ORGANIZATION HIERARCHY LEVEL.
`ORGANIZATION LEVEL ATTRIBUTES` | Reference | Attributes assigned to an ORGANIZATION LEVEL.
`ORGANIZATION MARKET DATA` | Reference | Publicly available and statistical information regarding the internal or external parties, such as DUNS number and number of employees.
`ORGANIZATION NAME` | Reference | Different types of organization names represent the associated business legal status of their organization.
`ORGANIZATION REGION` | Reference | An ORGANIZATION HIERARCHY LEVEL within an ORGANIZATION AREA. Organization Region entity is the parent of one or more ORGANIZATION DISTRICTs.
`ORGANIZATION SERVICE WEBSITE` | Reference | Subtype of the ORGANIZATION BUSINESS UNIT. This entity collects all information on Web sites managed by the operator. This normally includes only public information.
`ORGANIZATION WAREHOUSE` | 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: Chairs Telephone poles Network equipment Auto transmissions Handsets
`ORGANIZATIONAL DEMOGRAPHY VALUE` | Reference | User defined attribute definitions and corresponding values regarding demographic statistics as related to an ORGANIZATION BUSINESS UNIT.
`OS LICENSE ASSIGNMENT` | 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.
`OTHER INDIVIDUAL` | Reference | Individual associated with a PARTY organization, other than those defined such as CUSTOMER or EMPLOYEE.
`P LOGICAL DEVICE ROLE` | Reference | Defines required logical features to implement the specific role of a P (Provider Core) device, as used in a PRODUCT or SERVICE.
`PARTNER PAYMENT` | 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.
`PARTNER PROMOTION PROGRAM` | Reference | Assigns costs of a given PROMOTION to a Partner or PARTY participating in the promotion.
`PARTNER SETTLEMENT MONTH AGGR` | Aggregate | The monthly summary of financial settlement activities that have happened to partners at higher level.
`PARTNER SETTLEMENT DRVD` | Derived | Financial settlement activities that have happened to each partner within the month.
`PARTNER SETTLEMENT REASON` | Lookup | Lookup for valid reason codes for a partner settlement.
`PARTY` | 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.
`PARTY ACCOUNT ASSIGNMENT` | Reference | Assignment of a PARTY to an ACCOUNT. Depending on type of party, the relationship can be: Customer owns the ACCOUNT (typically for individual customers: there is one customer and one account) Multiple Customers may share the same account: This type of assignment is typical when several ORGANIZATION BUSINESS UNITs or individuals, association or employees, have, for example, a shared balance of free minutes to use on top of their own package (with their own ACCOUNT).
`PARTY ACCOUNT ASSIGNMENT TYPE` | Lookup | Lookup for type of relationship between PARTY and ACCOUNT. Depending on type of party, the relationship can be: Customer owns the account Multiple customers may share the same account
`PARTY ADDRESS LOCATION ASSIGNMENT` | Reference | Associates one or more Addresses with a PARTY.
`PARTY AM PMP ASSIGNMENT HISTORY` | Base | The assignment history among ACCESS METHOD, PRODUCT MARKET PLAN, and PARTY.
`PARTY AM PMP ASSIGNMENT STATUS` | Base | The status history of assignment among PARTY, ACCESS METHOD, and PRODUCT MARKET PLAN.
`PARTY ASSIGNMENT` | 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.
`PARTY ASSIGNMENT REASON` | Lookup | Lookup for valid reasons parties may be associated with each other. For example: Cooptation (customer brings in a new customer) Financial Responsibility Hierarchical relationship in the organization Contractual agreement
`PARTY ASSIGNMENT TYPE` | Lookup | Lookup for the type of the party relationship. For example: Father and son Organizational hierarchy, subsidiary Customer referral
`PARTY BUSINESS INTERACTION ROLE` | Reference | The business interaction role which can be assigned by a PARTY.
`PARTY CONTACT INFORMATION` | Reference | Contact information for a party.
`PARTY CONTACT INFORMATION TYPE` | Lookup | Lookup for the type of contact information. For example: Email Home telephone number Office telephone number Cell phone number Pager number
`PARTY CONTACT LIST PARTICIPATION` | Lookup | Relationship between PARTY and CONTACT LIST. For example, a party belongs to a contact list.
`PARTY CONTACT LIST ROLE` | Lookup | The Role of the PARTY in a CONTACT LIST.
`PARTY CONTRACT ASSIGNMENT` | Reference | Assignment of a PARTY to a CONTRACT.
`PARTY CONTRACT ASSIGNMENT ROLE` | Lookup | Lookup for valid Roles that Parties may be assigned in PARTY CONTRACT ASSIGNMENT.
`PARTY CONTRACT ASSIGNMENT TYPE` | Lookup | Lookup for type of the PARTY CONTRACT ASSIGNMENT. For example: Customer contract Managing employee
`PARTY COST ASSIGNMENT` | 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: Handset Network Device Gifts Cost might be assigned to multiple parties. For example, for operational cost several organizations may share the same expense on a PROMOTION or CAMPAIGN.
`PARTY DEMOGRAPHIC` | Reference | A demographic profile for a PARTY.
`PARTY DEMOGRAPHY VALUE` | Reference | Defines individual and organization demography value for a given party demographic profile.
`PARTY EVENT TYPE` | 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.
`PARTY GEOGRAPHY ENTITY ASSIGNMENT` | Reference | Assigns a PARTY to one or more GEOGRAPHY ENTITYs.
`PARTY IDENTIFICATION` | Reference | Identifying information unique to a PARTY.
`PARTY IDENTIFICATION TYPE` | Lookup | Lookup for valid types of PARTY IDENTIFICATION. For example: Driver's License DUNS Number
`PARTY INTERACTION THREAD` | Base | Grouping of related contact events with a PARTY into a single thread.
`PARTY INTERACTION THREAD TYPE` | Lookup | The type of PARTY INTERACTION THREAD. For example: Debt Collection Retention Program
`PARTY LANGUAGE CAPABILITY` | Reference | Keeps the language capability score for each party.
`PARTY LOCATION REASON` | Lookup | Lookup for available reason code and description for why a PARTY may be assigned to an address. For example: Billing address Shipping address
`PARTY LOCATION TYPE` | Lookup | The type of relationship between the PARTY and the address. For example: Office location Primary Living location Product Installation Address
`PARTY LOYALTY PROGRAM PARTICIPATION` | Reference | Identifies the LOYALTY PROGRAMs that each customer is enrolled in.
`PARTY MANAGEMENT ROLE` | Lookup | Defines all roles which a party plays in a CAMPAIGN, such as management or potential customer.
`PARTY MARKET SEGMENT ASSIGNMENT` | Reference | Assigns a PARTY to the market segment it belongs to.
`PARTY NAME` | Reference | Lists any other known names from the life history of a given party.
`PARTY ORDER ASSIGNMENT` | Base | Assignment of PARTY to a given Order. For example: Sales Agent gets a sales commission because of a customer order. A customer refers another customer to the operator network. The customer may receive incentives.
`PARTY ORDER ASSIGNMENT TYPE` | Lookup | Lookup for available assignment type codes and descriptions pertaining to PARTY ORDER ASSIGNMENT. For example: Customer of contract Sales agent for the order Vendor selling the order
`PARTY PROFILE CHARACTERISTIC` | Reference | The characteristic a party profile may take. For example, age, education, and so on.
`PARTY PROFILE CHARACTERISTIC VALUE` | Reference | The actual value for each PARTY PROFILE CHARACTERISTIC on the party profile.
`PARTY PROMOTION RESPONSE` | Base | Response of a PARTY to a PROMOTION. Records the customers response result to the initiative. For example, positive responses: The customer accepted the offer. The customer increased or modified their usage. The customer changed a specified behavior (for example moved from payment by check to an electronic payment option).
`PARTY ROLE` | Lookup | Lookup for Roles a PARTY may be assigned in an EVENT.
`PARTY ROLE ASSIGNMENT` | Reference | Assigns party roles for the party. PARTY and PARTY ROLE are an X-X relationship. This relationship may change due to a contract change, or for other reasons.
`PARTY ROLE OS PROCESS ASSIGNMENT` | 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.
`PARTY ROLE STATUS` | Reference | Status history of each role that a PARTY has taken.
`PARTY SEGMENTATION METHOD` | Lookup | Method used to create the segment, such as K-means clustering in Data Mining.
`PARTY SERVICE ASSIGNMENT` | Reference | Defines the relationship between PARTY and SERVICE.
`PARTY SERVICE ASSIGNMENT ROLE` | Lookup | Lookup for valid roles and descriptions a PARTY may be assigned for a SERVICE. For example: Service Creation role Service consumer by customer
`PARTY SERVICE ASSIGNMENT REASON` | Lookup | Lookup for available reasons for a PARTY and SERVICE relationship.
`PARTY SIM CARD ASSIGNMENT` | Reference | The relationship between SIM CARD and PARTY.
`PARTY SIM CARD ROLE` | Lookup | The role which PARTY add in regards to the SIM CARD.
`PARTY SKILL` | Reference | Defines skills with a score and skill level to each PARTY.
`PARTY STATUS CATEGORY` | Lookup | Higher level of Party Status. For example: Financial Status Credit Status Payment Status Personal Status Legal Status
`PARTY STATUS CHANGE REASON` | Lookup | Lookup for valid reasons that may be assigned for a Party Status change. For example: Hire Transfer New customer
`PARTY STATUS HISTORY` | 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.
`PARTY STATUS TYPE` | Lookup | Lookup for status type of the PARTY. For example: Active Inactive Defaulted New customer VIP, Loyalty Program, customer Black listed Credit Class is used to rank Customer Credit. For example, the entity value can be: Good Fair Bad Or the customer may be defined as: Gold Silver Bronze The party's credit is based on the underlying accounts held by the party.
`PARTY SUBSCRIPTION ASSIGNMENT` | Reference | Defines a PARTY's relationship to a SUBSCRIPTION. For example: a customer owns a subscription.
`PARTY SUBSCRIPTION ROLE` | Lookup | Lookup for valid Roles that may be assigned to PARTY in regards to the SUBSCRIPTION.
`PARTY TYPE` | Lookup | Lookup for party type that classifies involved parties according to their inherent characteristics and structure. For example: Person Organization Organization Unit
`PASSPORT` | Reference | The passport as a type of PARTY IDENTIFICATION.
`PAY CATEGORY` | Lookup | Lookup for type of pay category on a pay slip. For example: Salary Deductions Contributions Taxes
`PAY TV` | Reference | Subtype of PRODUCT. Pay TV is subscription-based product to deliver TV channels to a customer.
`PAY TYPE` | Lookup | Lookup for the type of payment made to the employee. For example: Bonus Basic wages
`PAYMENT AGING CLASS` | Lookup | The classification of accounts according to payment delay history. For example: 0-10 days 11-20 days
`PAYMENT AGING DAY DRVD` | Derived | Customer Debt aging results for a DAY. Customer Debt is assigned to a predefined AGE BAND.
`PAYMENT AGING MONTH AGGR` | Aggregate | Monthly summary of customer debt aging.
`PAYMENT CHANNEL` | Reference | Channel by which customer may pay for service. For example: Bank (automatic payment) Store (Check, cash) Call Center (Credit Card) Web (Credit Card)
`PAYMENT METHOD TYPE` | Lookup | Lookup for valid methods of payment. For example: Cash Check Credit Card Debit Card
`PAYMENT TRANSACTION TYPE` | Lookup | Lookup for type codes and descriptions for transaction types associated with the Account Payment. The payment may be, for example: Periodically Invoice Installation Fee Pre-deposit to the account Late Pay Penalty Payment Regular Monthly Refund / Void
`PCU OUTAGE REASON` | Lookup | Lookup for reasons for a Packet Control Unit (PCU) outage in GPRS technology. For example: Link Down Bit Error Rate
`PE LOGICAL DEVICE ROLE` | Reference | Defines required logical features to implement the specific role of a PE (Provider Edge) device, as used in a PRODUCT or SERVICE.
`PEAK OFFPEAK TIME` | 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: Normal Day Holiday Friday Sunday For the special days defined in the system.
`PERFORMANCE` | Reference | A measure of the manner in which a SERVICE and/or Element is functioning.
`PERFORMANCE APPLICABILITY` | Reference | The time of day or days during which a PERFORMANCE SPECIFICATION is measured or not measured.
`PERFORMANCE CAT CHARACTERISTIC VALUE` | Reference | A value of a Characteristic Specification provided for PERFORMANCE CATEGORY that further defines what the PERFORMANCE CATEGORY is.
`PERFORMANCE CAT SPEC RELATIONSHIP` | Reference | A specification for an association that can be established between two instances of PERFORMANCE CATEGORYs. For example, a relationship can be established between a Codec instance and Bearer Type instance.
`PERFORMANCE CAT SPECIFICATION` | Reference | The invariant characteristics that define a group or set of performance qualities that are classified together because of common characteristics.
`PERFORMANCE CATEGORY` | Reference | A group or set of performance qualities that are classified together because of common characteristics.
`PERFORMANCE CATEGORY RELATIONSHIP` | Reference | An association between two instances of PERFORMANCE CATEGORYs. For example, a relationship between a Codec instance and Bearer Type instance.
`PERFORMANCE CHARACTERISTIC VALUE` | Reference | A value of a Characteristic Specification provided for PERFORMANCE that further defines what the PERFORMANCE is.
`PERFORMANCE CONSEQUENCE` | Reference | An action taken if a PERFORMANCE OBJECTIVE is not met.
`PERFORMANCE INDICATOR` | Reference | A numeric value or text determined for a PERFORMANCE INDICATOR SPECIFICATION. For example, a value of .005 ms that represents average packet delay.
`PERFORMANCE INDICATOR DERIVATION PARAMETER` | Reference | A parameter used in the calculation of a PERFORMANCE INDICATOR. A Characteristic Specification can be used as a parameter or another PERFORMANCE INDICATOR SPECIFICATION can be used.
`PERFORMANCE INDICATOR RELATIONSHIP` | Reference | An association between two PERFORMANCE INDICATORs, such as one indicator derived from another.
`PERFORMANCE INDICATOR SPEC RELATIONSHIP` | Reference | An association between two PERFORMANCE INDICATOR SPECIFICATIONs, such as one indicator derived from another.
`PERFORMANCE INDICATOR SPECIFICATION` | 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.
`PERFORMANCE IP ADDRESS` | Reference | A Performance-related extension to an IP ADDRESS.
`PERFORMANCE IP ADDRESS SPECIFICATION` | Lookup | Type of IP ADDRESS related performance measures.
`PERFORMANCE MOBILE ADDRESS` | Reference | A network address that identifies mobile Element Elements, such as cell sites and base station controllers.
`PERFORMANCE NETWORK ADDRESS` | Reference | A Performance-related extension to a NETWORK ADDRESS. A NETWORK ADDRESS defines different ways to identify where an Element is, such as an IP ADDRESS, or an IPXAddress, or a Point Code.
`PERFORMANCE NETWORK ADDRESS SPECIFICATION` | Lookup | The invariant characteristics that define Performance-related extensions to Network Address Specification. Network Address Specifications define different types of addresses of different technologies, such as an IP ADDRESS or an IPXAddress. Each related PERFORMANCE NETWORK ADDRESS instance has the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE NETWORK ADDRESS entity are specific to each instance.
`PERFORMANCE NOTIFICATION` | Reference | A communication that occurs as part of measuring performance. A Notification is typically one-sided, that is, no Response is expected.
`PERFORMANCE NOTIFICATION SPECIFICATION` | 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.
`PERFORMANCE OBJECTIVE` | Reference | A goal for a PERFORMANCE INDICATOR defined in terms of metrics, thresholds, and tolerances.
`PERFORMANCE OBJECTIVE APPLICABILITY` | Reference | The time of day or days during which a PERFORMANCE OBJECTIVE is evaluated or not evaluated.
`PERFORMANCE OBJECTIVE APPLICABILITY CONSEQUENCE` | Reference | The time of day or days during which a Performance Objective Consequence applies or not to the violation of a PERFORMANCE OBJECTIVE.
`PERFORMANCE POINT CODE` | Reference | The performance gathered on a POINT CODE (subtype of NETWORK ADDRESS).
`PERFORMANCE SPEC INTERVAL CONVERSION` | Reference | The conversion factor that defines how many instances of one PERFORMANCE SPECIFICATION INTERVALs are contained in the related PERFORMANCE SPECIFICATION INTERVAL.
`PERFORMANCE SPECIFICATION` | Reference | The invariant characteristics that define a measure that determines how a SERVICE and/or Element is functioning. Each related PERFORMANCE instance will have the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE entity are specific to each instance.
`PERFORMANCE SPECIFICATION INTERVAL` | Reference | The interval of time for represented by the PERFORMANCE SPECIFICATION.
`PERIOD TO DATE TRANSFORMATION` | Reference | Cumulative time transformations at the period level.
`PERIOD TRANSFORMATION` | Reference | Time transformations at the period level.
`PHYSICAL CAPACITY` | Reference | This entity represents the minimum and maximum requirements, limits, or other variable features of a Managed Device or MANAGED HARDWARE object.
`PHYSICAL CAPACITY DETAIL` | 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.
`PHYSICAL COMPONENT` | 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.
`PHYSICAL CONNECTOR` | 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.
`PHYSICAL CONTAINER` | 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.
`PHYSICAL DEVICE` | 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.
`PHYSICAL DEVICE ATOMIC` | 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.
`PHYSICAL DEVICE COMPOSITE` | 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.
`PHYSICAL DEVICE ROLE SPEC` | 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.
`PHYSICAL DEVICE ROLE SPEC DETAIL` | Reference | Captures the semantics of the Specifies Physical Device Roles aggregation.
`PHYSICAL DEVICE SPEC` | Reference | This entity describes specific attributes, behavior, relationships, constraints, and semantics for building PHYSICAL DEVICE objects.
`PHYSICAL ELEMENT` | Reference | This entity describes different types of hardware that constitute a PRODUCT. The Physical Element has two main purposes: To collect common attributes and relationships for all hardware. To provide a convenient, single point where relationships with other managed objects can be defined.
`PHYSICAL ELEMENT CHARACTERISTIC` | Reference | Entity for defining the characteristic features and behavior of a PHYSICAL ELEMENT SPEC. Every PHYSICAL ELEMENT SPEC has a variety of important attributes, methods, constraints, and relationships which distinguish that PHYSICAL ELEMENT SPEC from other Physical Element Specifications. We call these Physical Element Spec Characteristics. Each of these characteristics is used at the business level to characterize a PHYSICAL ELEMENT SPEC.
`PHYSICAL ELEMENT ROLE` | Reference | This is a physical role that a device has. The Physical Element Role enables the correlation of physical components that route traffic with the logical capability of routing traffic.
`PHYSICAL ELEMENT ROLE ASSIGNMENT` | Reference | Implements the semantics of the Roles Describe Physical Element aggregation.
`PHYSICAL ELEMENT ROLE SPEC` | Reference | Entity for all Physical Element Role Specification subclasses. The Physical Element Role Spec enables relationships to be defined between it and other classes in the model. This helps prevent relationship explosion. The Physical Element Role Spec defines the invariant attributes, methods, relationships, and constraints of various types of roles associated with Physical Elements, whether they are subclasses of PHYSICAL DEVICE or Hardware, in the model.
`PHYSICAL ELEMENT SPEC` | Lookup | This entity defines the invariant characteristics and behavior, attributes, methods, constraints, and relationships, of a PHYSICAL ELEMENT.
`PHYSICAL ELEMENT SPEC ATOMIC` | Lookup | Describes specific attributes, behavior, relationships, constraints, and semantics for building PHYSICAL ELEMENT objects. The purpose of this entity is to track Physical Element Specifications separately from other types of Element Specifications. This entity inherits the Specifies Element aggregation, and therefore can be used with the corresponding PHYSICAL ELEMENT entity. The difference between this entity and the PHYSICAL ELEMENT SPEC COMPOSITE entity is that this entity represents standalone Physical Element Specifications. The PHYSICAL ELEMENT SPEC COMPOSITE entity represents a specification that is in reality made up of a set (usually a hierarchy) of Physical Element Specifications.
`PHYSICAL ELEMENT SPEC COMPOSITE` | Lookup | This entity describes specific attributes, behavior, relationships, constraints, and semantics for building Physical Element objects. The purpose of this entity is to track Physical Element Specifications separately from other types of Element Specifications. This entity inherits the modifiesElementSpec aggregation, and therefore can be used with the corresponding PHYSICAL ELEMENT SPEC entity. The difference between this entity and the PHYSICAL ELEMENT SPEC ATOMIC entity is that this entity represents a hierarchy of Physical Element Specifications. The PHYSICAL ELEMENT SPEC ATOMIC entity represents a single standalone Physical Element Specification.
`PHYSICAL EQUIPMENT` | 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.
`PHYSICAL LINK` | 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.
`PHYSICAL PORT` | 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.
`PHYSICAL PORT RESOURCE PORT ASSIGNMENT` | Reference | This entity is a concrete entity that defines the semantics of the PHYSICAL PORTs In Element Port aggregation. For example, it will describe characteristics and behavior of the PHYSICAL PORTs that comprise this particular Element Port in terms of dependencies and how a PHYSICAL PORT interacts with other PHYSICAL PORTs.
`PHYSICAL RESOURCE ROLE SPEC DETAIL` | Reference | Captures the semantics of the SpecifiesPHYSICAL ELEMENT ROLEs aggregation.
`PIPE` | Reference | Pipe is an abstracted Link between two network resources (which are also abstracted as TERMINATION POINTs).
`PLANNING PERIOD` | Reference | Period level in the planning calendar.
`PLANNING QUARTER` | Reference | Quarter level in the planning calendar.
`PLANNING SEASON` | Reference | Season level in the planning calendar.
`PLANNING WEEK` | Reference | Week level in the planning calendar.
`PLANNING YEAR` | Reference | Year level in the planning calendar.
`PMP AVAILABILITY` | Reference | Reference for Available Product Market Plan in different area or organization business unit.
`PMP LOYALTY PROGRAM AVAILABILITY` | Reference | Define the PRODUCT MARKET PLAN availability over Loyalty Program participants.
`PMP MARKET SEGMENT AVAILABILITY` | Reference | Defines the PRODUCT MARKET PLAN availability over certain Market Segments.
`PMP ORGANIZATION AVAILABILITY` | Reference | Reference for available PRODUCT MARKET PLAN subscriptions in an ORGANIZATION BUSINESS UNIT (store, outlet, and so on).
`PMP PRICE POLICY ACTION` | 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.
`PMP PRICE POLICY CONDITION` | 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.
`PMP PRICE POLICY VALUE` | 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.
`PMP PRICE POLICY VARIABLE` | Reference | A type of POLICY VARIABLE that represents a Product Offering, Product Offering Price, or Product Specification Type.
`PMP PRODUCT INSTANCE ASSIGNMENT` | Reference | The Relationship between PRODUCT MARKET PLAN and PRODUCT INSTANCE. Through this assignment, the product market plan can be designed based on Product Instance. For example, the movie Avatar can be promoted with Email service. In this example, the operator can run a promotion saying: Subscribing to the Email service in this month gives you the movie Avatar for free (from IPTV or by downloading).
`PMP RATING PLAN` | Reference | An altered rating plan, with allowance or premium charge, over the standard rating charge to the product inside a PRODUCT MARKET PLAN.
`PMP RATING PLAN DETAIL` | Reference | Details for an alternation, allowance or premium charge, over the standard rating charge to the product inside a product market plan.
`POINT CODE` | Reference | ISUP Signaling OPC and DPC attributes that map to Region, Subregion, Node Type, and Node Name.
`POLICY` | 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.
`POLICY ACTION` | Reference | This entity represents how to form the action clause of a POLICY RULE. This consists of a single occurrence of a POLICY STATEMENTt, 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.
`POLICY ACTION ASSIGNMENT` | Reference | This entity specifies the semantics needed for the contained Policy Actions aggregation.
`POLICY ACTION ATOMIC` | 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.
`POLICY ACTION COMPOSITE` | 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.
`POLICY ACTION RULE ASSIGNMENT` | 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.
`POLICY ACTION VENDOR` | 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.
`POLICY APPLICATION ASSIGNMENT` | Reference | This is an association class that explicitly defines which Managed Entities in a Policy Domain this Policy information applies to.
`POLICY CONDITION` | 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.
`POLICY CONDITION ASSIGNMENT` | Reference | This entity specifies the semantics needed for the Policy Condition In Policy Condition aggregation. This aggregation defines the set of POLICY CONDITIONs that are contained in this POLICY CONDITION. Note that the POLICY CONDITION Contained Policy Condition Details entity and the Policy Condition Rule Details entity have conceptually the same attributes. This is because they both provide semantics to form a condition expression. The difference lies in their placement relative to the POLICY RULE entity. That is, the Contained Policy Condition Details entity combines individual expressions within a condition clause, whereas the Policy Condition Rule Details entity describes how the completed condition clause appears to the POLICY RULE. These attributes are described in the Data Dictionary section of this Addendum.
`POLICY CONDITION ATOMIC` | 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.
`POLICY CONDITION COMPOSITE` | Reference | The POLICY CONDITION COMPOSITE entity is the base entity for all complex policy conditions. A complex policy condition consists of an aggregation of POLICY CONDITION ATOMIC and POLICY CONDITION COMPOSITE objects, which in turn form a complex Boolean statement. Note that such an object still evaluates to a single Boolean TRUE or FALSE value. Conceptually, this is a standalone object that consists of one POLICY CONDITION that provides an overall context for either a nested or a group of subordinate POLICY CONDITIONs to be evaluated.
`POLICY CONDITION RULE ASSIGNMENT` | Reference | This entity specifies the semantics needed for the Policy Condition In Policy Rule aggregation. This aggregation defines the set of Policy Conditions that are contained in this POLICY RULE. The Contained Policy Condition Details entity and the Policy Condition Rule Details entity have conceptually the same attributes. This is because they both provide semantics to form a condition expression. The difference lies in their placement relative to the POLICY RULE entity. That is, the Contained Policy Condition Details entity combines individual expressions within a condition clause, whereas the Policy Condition Rule Details entity describes how the completed condition clause appears to the POLICY RULE. These attributes are described in the Data Dictionary section of this Addendum.
`POLICY EVENT` | 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.
`POLICY EVENT ATOMIC` | Base | Represents the occurrence of a single atomic event, which triggers the evaluation of the condition clause of a POLICY RULE.
`POLICY EVENT COMPOSITE` | 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.
`POLICY GROUP` | 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.
`POLICY GROUP EXECUTION DETAIL` | 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.
`POLICY OPERATOR` | 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.
`POLICY OPERATOR VARIABLE ASSIGNMENT` | Reference | Defines the relationship between POLICY OPERATOR and POLICY VARIABLE.
`POLICY ROLE` | Reference | This entity defines the concept of various types of roles for different policies that are used.
`POLICY RULE` | 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).
`POLICY SET` | 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.
`POLICY SET ASSIGNMENT` | Reference | Defines relationship between POLICY SETs.
`POLICY STATEMENT` | 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.
`POLICY VALUE` | 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.
`POLICY VARIABLE` | 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.
`POLICY VARIABLE VALUE ASSIGNMENT` | 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.
`POSTAL SERVICE TYPE` | Lookup | Lookup for type of postal service type available to the carrier. For example: First-Class Mail Registered Mail Regular Mail Postal Card
`POSTCODE` | Reference | Postal Code, Zip Code, or similar geographical designation.
`POSTPAID WIRELESS` | Reference | Subtype of PRODUCT for postpaid wireless.
`PPA CATEGORY` | Lookup | Lookup for categorizations of prepaid allowances. For example: Local Call Allowance Long Distance Call Allowance Bonus Free Minutes Internal (Inside Operators network) Call Allowance
`PPA DEDUCTION TYPE` | Lookup | Lookup for valid deduction types as related to prepaid allowances (PPA).
`PREPAID ACCOUNT STATISTIC DRVD` | Derived | Monthly aggregation of prepaid account revenue, including: air time, recharge value and so on, by ACCOUNT, SALES CHANNEL, AGE ON NET BAND.
`PREPAID ACCOUNT STATISTIC SEGMENT AGGR` | Aggregate | Monthly summary of prepaid account revenue, including: air time, recharge value, and so on, by CUSTOMER SEGMENT, PRODUCT MARKET PLAN.
`PREPAID ALLOWANCE DAY DRVD` | Derived | Daily aggregate of free minutes allowance (PPA) for ACCOUNT and PRODUCT MARKET PLAN.
`PREPAID ALLOWANCE MONTH AGGR` | Aggregate | Monthly summary of free minutes allowance (PPA) in a PRODUCT MARKET PLAN.
`PREPAID CALL SUMMARY DAY DRVD` | Derived | Daily aggregate of prepaid calls by ACCOUNT, PRODUCT MARKET PLAN, and ACCESS METHOD.
`PREPAID CALL SUMMARY MONTH AGGR` | Aggregate | Monthly summary of prepaid call activity by PRODUCT MARKET PLAN, CUSTOMER TYPE.
`PREPAID MOBILE EVENT TYPE` | Lookup | Lookup for the prepaid mobile event types that may be actioned against a prepaid mobile subscription. The specific event types are implementation specific. For example: Initial activation Recharges Adjustments Deactivations
`PREPAID VOUCHER INSTANCE` | Reference | Represents each prepaid card. The cards are a means of recharging prepaid mobiles. The card can be physically a Plastic Card or a paper slip with account number and pin code.
`PREPAID RECHARGE` | Base | Type of ACCOUNT PAYMENT in which a PREPAID VOUCHER INSTANCE is recharged.
`PREPAID VOUCHER` | Reference | The voucher a customer can buy to refill their prepaid account, normally in the form of a paper or plastic card. For example: Prepaid Mobile Recharge Voucher Prepaid Calling Card
`PREPAID WIRELESS` | Reference | Type of Service Product. Subtype of SERVICE, for Prepaid Wireless service only.
`PRICE DERIVATION RULE` | 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.
`PRICE EVENT` | Reference | Type of event which may trigger a billing process, for example, event of customer using a product over its quota.
`PRODUCT` | Reference | The product provided by the carrier. Product includes PRODUCT PACKAGE information. The composition of a PRODUCT PACKAGE is tracked in the product relationship.
`PRODUCT ADDITIONAL TEXT` | 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.
`PRODUCT ASSIGNMENT` | Reference | Defines a relationship between a PRODUCT and a related product.
`PRODUCT ASSIGNMENT REASON` | Lookup | Lookup for valid reason codes and descriptions for PRODUCT ASSIGNMENT.
`PRODUCT CAPABILITY` | Reference | Various product capabilities, or features. For example: Number of lines for a phone Storage size for Email Number of "Friends&Family" numbers
`PRODUCT CAPABILITY TYPE` | Lookup | Lookup for type of PRODUCT CAPABILITY.
`PRODUCT CAPABILITY VALUE` | Reference | Detailed PRODUCT CAPABILITY information. The information would be quantitative by PRODUCT CAPABILITY TYPE.
`PRODUCT CATALOG` | Reference | A list of PRODUCT MARKET PLAN for sale, with prices and illustrations, for example in book form or on the web. Product Catalogs can be used by Customers during a self-care ordering process and may be used across one or more Distribution Channels.
`PRODUCT CATALOG CHARACTERISTIC` | Reference | A characteristic quality or distinctive feature of a Product Catalog Specification.
`PRODUCT CATALOG CHARACTERISTIC ASSIGNMENT` | 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.
`PRODUCT CATALOG CHARACTERISTIC RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Characteristic Specifications.
`PRODUCT CATALOG CHARACTERISTIC VALUE` | Reference | A value associated with a Product Catalog Characteristic.
`PRODUCT CATALOG CHARACTERISTIC VALUE ASSIGNMENT` | 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.
`PRODUCT CATALOG CHARACTERISTIC VALUE RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Characteristic Spec Values.
`PRODUCT CATALOG GEOGRAPHY ASSIGNMEN`T | Reference | Defines which PRODUCT CATALOG is available in which geographical area.
`PRODUCT CATALOG MARKET PLAN ASSIGNMENT` | Reference | Defines the relationship between a PRODUCT CATALOG and the product market plans that appeared on the PRODUCT CATALOG.
`PRODUCT CATALOG PRESENTATION TYPE` | Reference | The PRODUCT CATALOG presentation type. For example: Brochure Web pages Video
`PRODUCT CATALOG SALES CHANNEL ASSIGNMENT` | Reference | Defines where the PRODUCT CATALOGs are made available to the end user.
`PRODUCT CATALOG TYPE` | Lookup | Lookup for types that define the invariant characteristics of a PRODUCT CATALOG.
`PRODUCT CATEGORY` | Lookup | Lookup for classification of the PRODUCT according to certain common characteristics.
`PRODUCT CHARACTERISTIC` | 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.
`PRODUCT CHARACTERISTIC ASSIGNMENT` | Reference | A use of the Characteristic Specification by an Product Specification to which additional properties apply.
`PRODUCT CHARACTERISTIC RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Product Spec Characteristics.
`PRODUCT CHARACTERISTIC TYPE` | Lookup | Type of PRODUCT CHARACTERISTIC.
`PRODUCT CHARACTERISTIC VALUE` | Reference | A value of a Product Spec Characteristic chosen for a PRODUCT that further defines what the PRODUCT is.
`PRODUCT CHARACTERISTIC VALUE ASSIGNMENT` | 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.
`PRODUCT CHARACTERISTIC VALUE RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Product Spec Characteristics.
`PRODUCT CHARGE TYPE` | Lookup | Lookup for type codes and descriptions for PRODUCT PACKAGE charge on a PRODUCT. For example: One time charge Usage duration charge Usage per call charge Usage amount charge (data transfer) Monthly cycle forward fee Monthly cycle arrear fee Free unit charge Free charge Factorization (call charge* a factor)
`PRODUCT CHARGE TYPE RELATIONSHIP` | Reference | Assignment of related PRODUCT CHARGE TYPEs.
`PRODUCT CHARGE TYPE RLTN REASON` | Lookup | Lookup for available reasons for PRODUCT CHARGE TYPEs to be related to each other.
`PRODUCT CHARGING REASON` | Lookup | Lookup for available reasons for Product Charge in the PRODUCT RATING PLAN. For example: Charge for Roaming Charge for Long-Distance Charge or For Local Call Regular Fee
`PRODUCT COST` | Base | Sub-table of the COST TYPE table, used to associate a specific cost to a given product.
`PRODUCT COVERAGE AREA` | Reference | Coverage of a product over geographical area.
`PRODUCT COVERAGE GEO DETAIL` | Reference | Links detailed geographical locations to a certain PRODUCT COVERAGE AREA.
`PRODUCT FEATURE` | Reference | Available features that may be associated with one or more PRODUCTs. For example, for a handset there are features such as: MP3 indicator MIDIindicator 3G indicator JAVA indicator GSM 1800 indicator
`PRODUCT FEATURE ASSIGNMENT` | Reference | Assigns one or more PRODUCT FEATUREs to a PRODUCT. Multiple products may have the same PRODUCT FEATUREs.
`PRODUCT FUNCTIONALITY DEPENDENCY` | Reference | Assignment of valid EQUIPMENT FUNCTIONALITY and PRODUCT VERSIONs to a PRODUCT.
`PRODUCT GEOGRAPHY ASSIGNMENT` | Reference | Assigns a PRODUCT to a GEOGRAPHY ENTITY. This is particularly used for products offered only locally or in a limited region. For example: "Broadband Service" in specific cities and ZIP code areas (typically used for City carriers).
`PRODUCT GROUP` | Lookup | Categorizations or Groups into which PRODUCTs may be assigned, usually based on similar functionality. Note: this is different and should not be confused with the PRODUCT MARKET PLAN GROUP entity. For example, the customer may group product in categories such as: Postpaid Wireless Prepaid Wireless Fixed Line Subscription Calling Card Pay TV Broadband
`PRODUCT GROUP ASSIGNMENT` | Reference | Defines relationship of PRODUCT and one or more PRODUCT GROUPs.
`PRODUCT GROUP TYPE` | Lookup | Lookup for codes and descriptions of types of PRODUCT GROUPs.
`PRODUCT INSTANCE` | Reference | The real instance of a given PRODUCT which a customer can purchase or rent (or eventually gets for free as part of a PRODUCT MARKET PLAN). The product instance is linked to the Customer Order Line Item and relates a product to a customer. For example: Song specified as "You are not alone": Corresponding to Product MUSIC DOWNLOAD TV channel specified as "Discovery" - Corresponding to Product PAY TV
`PRODUCT LINE` | Lookup | Lookup for the ways to classify products according business organization. For example: Wireless, Fixed Line, and so on.
`PRODUCT MANAGEMENT HISTORY` | Base | Defines relationship between EMPLOYEE, PRODUCT MANAGEMENT ROLE, and PRODUCT.
`PRODUCT MANAGEMENT REASON` | Lookup | Lookup for available reasons for a PRODUCT MANAGEMENT HISTORY relationship.
`PRODUCT MANAGEMENT ROLE` | Lookup | Lookup for valid role codes and descriptions an employee may be assigned in PRODUCT MANAGEMENT HISTORY. For example: Product Creation role Publication to the market (in/out) role Product Version Update role Product Testing role
`PRODUCT MARKET PLAN` | Reference | Defines how a product is brought to the market, including: positioning, pricing, and bundling details. For example: Tariff Liberty 60, with 60 Free National Minutes, 3 Friends & Family Network Intern Numbers DSL 32Mbit/s + VoIP Phone + TV Entertainment + Pay TV Soccer Championship one year promotion
`PRODUCT MARKET PLAN ASSIGNMENT` | Reference | Assigns Products to PRODUCT MARKET PLANs.
`PRODUCT MARKET PLAN ASSIGNMENT TYPE` | Lookup | Lookup for type of product participation (inclusion) in the market plan. For example: Use as gift Main product Revenue generation service Base on
`PRODUCT MARKET PLAN COST` | Base | Sub-table of the COST TYPE table. This entity associates a specific cost to a given PRODUCT MARKET PLAN. The cost should not be related to the CAMPAIGN or to the PROMOTION, but just to the PRODUCT MARKET PLAN.
`PRODUCT MARKET PLAN GEOGRAPHY ASSIGNMENT` | Reference | Relationship between PRODUCT MARKET PLAN and Geography. Some PRODUCTs may only be sold in a particular area.
`PRODUCT MARKET PLAN GROUP` | Reference | Hierarchy level to group the various PRODUCT MARKET PLANs. For example: Postpaid "Family" Broadband "Business Unlimited" Prepaid "Freedom"
`PRODUCT MARKET PLAN GROUP ASSIGNMENT` | Reference | Defines relationship of PRODUCT MARKET PLANs to one or more PRODUCT MARKET PLAN GROUPs.
`PRODUCT MARKET PLAN GROUP TYPE` | Lookup | Lookup for the type code and description for a PRODUCT MARKET PLAN GROUP.
`PRODUCT MARKET PLAN RELATIONSHIP` | Reference | Defines the relationship between two PRODUCT MARKET PLANs. For example: One product market plan replaced another one. One product market plan is an alternation of another one.
`PRODUCT MARKET PLAN RELATIONSHIP TYPE` | Lookup | Lookup for the types of PRODUCT MARKET PLAN relationships.
`PRODUCT MARKET PLAN TYPE` | Lookup | Type of the PRODUCT MARKET PLAN. For example: Prepaid Wireless Postpaid Wireless VAS Special Package
`PRODUCT NETWORK ASSIGNMENT` | Reference | Assigns a PRODUCT to one or more NETWORKs.
`PRODUCT PACKAGE` | Reference | Groups of PRODUCTs bundled to serve as basis of a PRODUCT MARKET PLAN. The product package is not customer facing and a customer should subscribe to a product package through the PRODUCT MARKET PLAN. For example: Tariff Liberty 60, Wireless phone, 3 Friends & Family Network Intern Numbers DSL 32Mbit/s + VoIP Phone + TV Entertainment + Pay TV Soccer Championship
`PRODUCT PACKAGE ASSIGNMENT` | Reference | Assigns PRODUCT(s) to a PRODUCT PACKAGE.
`PRODUCT PACKAGE CHARGE TYPE` | Lookup | Lookup for type codes and descriptions for PRODUCT PACKAGE charge on a PRODUCT. For example: One time charge Usage Duration charge Usage per Call charge Usage amount charge (Data transfer) Monthly Cycle Forward Fee Monthly Cycle Arrear Fee Free Unit Charge Free Charge
`PRODUCT RATING PLAN` | Reference | Grouping mechanism for prices and usage limits associated with a PRODUCT.
`PRODUCT RATING PLAN DETAIL` | Reference | Detail of PRODUCT RATING PLAN, defines prices and usage limits for each PRODUCT CHARGE TYPE.
`PRODUCT RATING PLAN TYPE` | Lookup | Lookup for the type of PRODUCT RATING PLAN.
`PRODUCT STATUS HISTORY` | Base | Status history of PRODUCT.
`PRODUCT STATUS TYPE` | Lookup | Lookup for the type of the product status.
`PRODUCT TYPE` | Lookup | Lookup for the type of the PRODUCT. For example: Item Service
`PRODUCT USERNAME` | Reference | The usernames assigned to customer for given products. For example: Instant Messenger Web Meeting Remoted (online) Storage Web Self Service Account
`PRODUCT VERSION` | Reference | Iteration of a PRODUCT created when a minor change is made to the PRODUCT setting that does not require creating a new PRODUCT.
`PROMOTION` | 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.
`PROMOTION CLUSTER USAGE` | 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.
`PROMOTION CONTACT LIST UTILIZATION` | 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.
`PROMOTION COST` | 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.
`PROMOTION MANAGEMENT HISTORY` | Base | A history of campaign party role about management of a campaign EPISODE.
`PROMOTION MARKET PLAN ASSIGNMENT` | Reference | Associates a market plan to a PROMOTION. Typically, this applies when a given market plan is offered with an additional discount (PROMOTION) during a certain period.
`PROMOTION MESSAGE RENDERING` | Reference | Details regarding each CAMPAIGN MESSAGE broadcast through a MEDIA OBJECT.
`PROMOTION PRODUCT ASSIGNMENT` | Reference | The relationship between a PRODUCT and a PROMOTION.
`PROMOTION PRODUCT CATALOG ASSIGNMENT` | Reference | Associates PRODUCT CATALOGs to a PROMOTION.
`PROMOTION RELATIONSHIP` | Reference | Defines the relationship between two PROMOTIONs.
`PROMOTION RESULT TYPE` | Lookup | Lookup for the prospect reaction to a specific PROMOTION during a sales campaign. For example: Accepted Not interested Interested but not accepted Not Interested but other product sold
`PROMOTION SALES CHANNEL ASSIGNMENT` | Reference | The allocation of PROMOTION resources or actions onto each SALES CHANNEL.
`PROMOTION TERM TYPE` | Lookup | Lookup for valid type codes and descriptions of Promotion Term associated with a PROMOTION TERM VALUE. For example: Number of customers Period Planning Selling amount Planning contracts number
`PROMOTION TERM VALUE` | Base | Assigns PROMOTION TERM TYPE to a PROMOTION with a value corresponding to the Term Type. For example: Maximum Number of customers Period Planning selling amount Planning contracts number
`PROMOTION TYPE` | Lookup | Lookup for the type of PROMOTION (each for either a limited time or for the contract duration). For example: Monthly Fee Discount Additional Free Service Free Installation Cost Give-away Equipment Free Equipment Rental Limited Extra Usage for Free
`PROPERTY` | Reference | A parcel of land with defined legal boundaries. This is a concrete Geographic Location entity.
`PROPERTY ADDRESS LOCATION ASSIGNMENT` | Reference | Defines the relationship of which property is using which address location to identify the property.
`PROPOSAL` | Reference | The proposals made available to prospects in the promotion. It could be a upsell offer like selling a new product, or a retention program (Free Minutes for Longer contract period).
`PROPOSAL RELATIONSHIP` | Reference | The relationship between two PROPOSALs.
`PROSPECT` | Reference | An individual, collection of individuals, company, or public institution that does not currently purchase merchandise or services, but who may in the future. A prospect may also be a CUSTOMER of one PRODUCT (already purchased) that does not currently purchase another PRODUCT (may purchase). A prospect has no recorded relationship with the provider.
`PROSPECT INDIVIDUAL` | Reference | Attributes of an individual PROSPECT, one who is not an organization.
`PROSPECT ORGANIZATION` | Reference | Attributes of a prospect organization.
`PROSPECT PRIORITY TYPE` | Lookup | The different priorities which can be assigned to the prospect and prospect interests.
`PROSPECT QUALITY SCORE TYPE` | Reference | Lookup for type of quality scores which can be applied to PROSPECT. For example: Income Buying Probability
`PROSPECT QUALITY SCORE VALUE` | Reference | The quality score value assigned to each prospect under different type of criterias.
`PROSPECT REJECT REASON` | Lookup | The reason to explain why an offer or PROPOSAL is rejected by the prospect.
`PROTOCOL` | 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.
`PTV FULL CHANNEL ACTIVATION` | Base | Pay TV full channel activation event.
`PTV QPI SERVICE EVENT` | Base | The detail of QPI service.
`PTV USAGE EVENT` | Base | Customer usage of PAY TV service.
`PUBLICATION` | Reference | Publication to which the MEDIA OBJECT used in CAMPAIGN belongs.
`PUBLICATION TYPE` | Lookup | Lookup for code and description describing the type of publication.
`PV BIT STRING VALUE` | 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.
`PV BOOLEAN VALUE` | Reference | Represents a Boolean value (TRUE or FALSE).
`PV INTEGER VALUE` | Reference | Provides a list of integer or integer range values. Each integer can be of an arbitrary size.
`PV IP ADDRESS VALUE` | 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.
`PV STRING VALUE` | Reference | Represents a single string value, or a set of string values. Each value can have wildcards.
`PVAR BIT STRING VARIABLE` | 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.
`PVAR STRING VARIABLE` | Reference | Represents a single or set of string variable. Each can have wildcards. Thus, only String Value classes can be used in the value portion of the condition expression with this POLICY VARIABLE.
`QOS SERVICE` | Reference | Represents a generic specification for defining the different types of Sub-Services that are required to implement a specific type of QoS. This enables business rules to be mapped to the network, and define services that the network provides. A QoS Service can be thought of as an aggregation of sub-services needed to realize the functionality specified by, for example, a SERVICE BUNDLE. This enables the network administrator to map business rules, as specified in a more abstract object or set of objects, to the network, and the network designer to engineer the network such that the network provides different functions for different types of applications. QoS Services are a type of RESOURCE FACING SERVICE and are bundled together using SERVICE BUNDLEs. QoS Services can be turned into templates using SERVICE BUNDLE SPECs. The QoS Service itself is a means to coordinate different technology-specific approaches to implementing QoS, such as DiffServ, ToS, and IEEE 802.x. As such, the QOS Service entity is an abstract entity.
`QOS SERVICE SPEC TYPE` | Lookup | The QOS SERVICE spec type.
`QUARTER HOUR` | Reference | Quarter Hour as defined in Time Hierarchy.
`QUARTER TO DATE TRANSFORMATION` | Reference | Cumulative time transformations at the quarter level.
`QUARTER TRANSFORMATION` | Reference | Transformation with respect to a quarter. For example: This quarter last year This year last quarter
`RACK` | Reference | A Rack is a type of Secure Holder that represents an enclosure in which Equipment Holders, such as CHASSIS, are placed. Typically a Rack is nothing more than the enclosure, and all the functioning componentry is packaged in the CHASSIS. The logical identifier of a Rack is not typically associated with the Device (that is, the Network Element). Compare this to either a Bay or a Shelf, whose logical identifier IS associated with the Device. Thus, the Rack is explicitly not a part of the logical model of a network. The Rack typically serves as the "master enclosure" for CHASSIS, Shelves and Bays. In addition, Racks can have multiple instances of multiple Devices mounted in them.
`RATED NETWORK EVENT` | Base | Contains rating information attached to raw or mediated network event.
`RATING METHOD TYPE` | Lookup | Lookup for Rating Method Type code and description. For example: Flat Rate Tier Rating Threshold Rating
`RAW MMS EVENT` | Base | The raw MMS EVENTas acquired on network element.
`RAW WIRELESS CALL EVENT` | Base | The raw WIRELESS CALL EVENT.
`RESOURCE FACING SERVICE SPEC ROLE` | Reference | This class defines a SERVICE SPEC, in terms of a set of ServiceSpecificationRoles, for a ElementFacingService. This is the base class for defining ServiceSpecificationRoles that are used to represent the invariant characteristics of a ElementFacingService. This enables the ElementFacingService to be managed abstractly using ServiceSpecificationRoles. It also helps define the SERVICE SPEC in terms of the functions that it has or provides.
`RECHARGE REVENUE SLAB` | 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.
`RECURRING PMP RATING PLAN DETAIL` | Reference | A type of PRODUCT MARKET PLAN (PMP) rating plan with a recurring charge.
`REDEMPTION DAY DRVD` | Derived | The daily aggregate of loyalty point redemption by CREDIT CATEGORY, LOYALTY PROGRAM CHANNEL, AGE ON NET BAND, and EMPLOYEE. Daily aggregation of LOYALTY PROGRAM redemption statistics by LOYALTY PROGRAM CHANNEL, SALES CHANNEL, AGE ON NET BAND, CREDIT CATEGORY, and EMPLOYEE.
`REDEMPTION MO AGGR` | Aggregate | Monthly summary of LOYALTY PROGRAM redemption statistics by LOYALTY PROGRAM CHANNEL
`REDEMPTION TYPE` | Lookup | Lookup for redemption type that maintains all possible point redemption types and organizes redemption data by redemption type for analysis purposes.
`RESOURCE FACING SERVICE` | 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.
`RESOURCE FACING SERVICE ROLE` | 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.
`RESOURCE FACING SERVICE SPEC` | Lookup | This is the base entity for defining Resource Facing Service Specs. A Resource Facing Service Spec is an abstraction that defines the invariant characteristics and behavior of a particular RESOURCE FACING SERVICE. This is not seen by the Customer. However, it is required by one or moreCUSTOMER FACING SERVICE SPECs in order for them to function correctly. The invariant portion serves as a single common basis to build a set of variable RESOURCE FACING SERVICEs that all use this common Resource Facing Service Spec.
`RESOURCE FACING SERVICE SPEC ATOMIC` | Lookup | This entity defines a standalone RESOURCE FACING SERVICE that meets the needs of a particular CUSTOMER FACING SERVICE. Standalone RESOURCE FACING SERVICEs may be linked directly to a CUSTOMER FACING SERVICE or aggregated by a Resource Facing Service Composite.
`RESOURCE FACING SERVICE SPEC COMPOSITE` | Lookup | This entity defines an integrated set of RESOURCE FACING SERVICE that collectively meets the needs of a CUSTOMER FACING SERVICE. For example, the Customer may have requested "GoldService", which is a SERVICE PACKAGE that defines a set of SERVICE BUNDLEs, each of which has its own QoS. A set of Resource Facing Service Products can then be defined, one for each different SERVICE BUNDLE instance, that provides the required QoS for each SERVICE BUNDLE instance.
`RESOURCE FACING SERVICE SPECROLE` | Reference | Defines a Service Specification, in terms of a set of Service Specification Roles, for aRESOURCE FACING SERVICE. This is the base entity for defining Service Specification Roles that represent the invariant characteristics of aRESOURCE FACING SERVICE. This entity enables theRESOURCE FACING SERVICE to be managed abstractly using Service Specification Roles. The Resource Facing Servicesrole also helps define the Service Specification in terms of the functions that it has or provides.
`RESOURCE FACING SERVICE SPEC VERSION` | Reference | Keeps the historical versions of RESOURCE FACING SERVICE SPEC.
`RESOURCE ORDER` | Base | A type of Request that represents a Service Order's services decomposed into the Elements on which the services will be provisioned.
`RESOURCE ORDER ITEM` | Base | The purpose for the RESOURCE ORDER expressed in terms of a NETWORK ELEMENT TYPE or a NETWORK ELEMENT.
`RESOURCE PERFORMANCE` | Reference | A measure of the manner in which a Element is functioning.
`RESOURCE PERFORMANCE SPEC` | Lookup | The invariant characteristics of a measure of the manner in which a Element is functioning. Each related PERFORMANCE instance will have the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE entity are specific to each instance.
`RESOURCE SPEC PERF ROLE` | Reference | A role that a Element Specification plays in defining a PERFORMANCE SPECIFICATION.
`RESOURCE PORT` | Reference | The Resource Port covers both logical and physical port together and manage as a single entity.
`RETAIL STORE` | 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.
`RF CARRIER` | Reference | Reference list of all wireless or Radio Frequency (RF) carriers.
`RF NETWORK CAPACITY DAY DRVD` | Derived | Daily aggregate of Radio Frequency (RF) Network Capacity utilization statistics. Radio Frequency (RF) interfaces are present at two levels in the network: RF Interface between CELL and the Mobile Station RF interface between MSC and the BSS
`RF NETWORK CAPACITY MONTH AGGR` | Aggregate | Monthly summary of Radio Frequency (RF) Network Capacity utilization statistics.
`RFS SPEC VERSION DETAIL` | 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.
`RINGTONE` | Reference | Sub-table of SUPPLEMENTARY SERVICE, by which a customer can download music as a ringtone for the phone.
`ROAMING TYPE` | Lookup | Lookup for the various roaming types to classify the calls. For example: (Standard) Outgoing Roaming (Standard) Incoming Roaming Inland Outgoing Roaming Inland Incoming Roaming
`ROLE` | Reference | This is an abstract base entity that defines the concept of various types of roles.
`ROLES HIERARCHY` | Reference | Hierarchy among the job roles within an organization.
`ROOT ENTITY` | 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.
`ROUTED PROTOCOL` | 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.
`ROUTER` | Reference | A type of physical device which performs routing function in IP-based network.
`ROUTING DEVICE` | 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.
`ROUTING PROTOCOL` | 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.
`ROUTING ROLE` | Reference | An abstracts entity showing the different routing capabilities necessary for a LOGICAL DEVICE to have. This entity helps to simplify the modeling of network devices, which have many different sets of capabilities. For example, most routers can do routing, forwarding, and firewalling of traffic. By modeling these capabilities as three roles, router functionality is both abstracted as well as categorized, so that the differences between routing done by a router and routing done by an L3 switch can be differentiated.

Table 2-28 S to V Entity Description

Entity Name | Type | Description
--- | --- | ---
`SALES CAMPAIGN SUMMARY DAY DRVD` | Derived | Daily aggregate of campaign results by PROMOTION RESULT TYPE and Sales Campaign Client Code.
`SALES CAMPAIGN SUMMARY MONTH AGGR` | Aggregate | Monthly summary of Sales Campaign results by PRODUCT MARKET PLAN, CAMPAIGN CHANNEL, PROMOTION RESULT TYPE.
`SALES CHANNEL` | Reference | Channel used to communicate with parties for sales purposes. For example: Representatives Partner-Dealers Direct Dealers Sales channels are represented by the channel level, which also becomes the lowest level for the channel dimension.
`SALES CHANNEL REPRESENTATIVE` | Reference | The sales representative who sells the product to the customer. For example: Sales Representative in the operator owned shops. Direct sales representatives in the call center. Dealer for a partner.
`SALES COMMISSION DETAIL` | Base | The sales commission earned by sales agent because of the contract.
`SALES COMMISSION PAYROLL` | Base | The sales commission issued to the sales agent.
`SALES COMMISSION PLAN` | Reference | The sales commission plan for particular PRODUCT PACKAGE and sales agent level.
`SALES COMMISSION PLAN DETAIL` | Reference | Details about the SALES COMMISSION PLAN per PRODUCT MARKET PLAN and PROMOTIONs, including sales quota and commission rate.
`SALES DAY DRVD` | Derived | Daily aggregate of sales by SALES CHANNEL, PRODUCT MARKET PLAN, business unit, sales representative, CUSTOMER.
`SALES MONTH AGGR` | Aggregate | Monthly summary of sales by SALES CHANNEL, PRODUCT MARKET PLAN, business unit, sales representative.
`SALES REPRESENTATIVE STATISTICS DRVD` | Derived | Monthly summary of sales representative performance measured by sales, commission, and so on.
`SALES REPRESENTATIVE STATISTICS MO AGGR` | Aggregate | Monthly summary of sales representatives performance measured by sales, commission, and so on at SALES CHANNEL level.
`SCD2 MULTILANGUAGE` | Lookup | Super entity to provide SCD2 and LANGUAGE support for all its children.
`SCRIPT` | Reference | A list of specific groupings of questions or statements presented to individuals during a survey.
`SCRIPT QUESTION` | Reference | Initiative questions documents the questions asked of the customer as part of the initiative.
`SCRIPT QUESTION TYPE` | Lookup | The domain of values used to group script items. For example: 1 = Yes or No answers 2 = Provide a Value 3 = Give a Range 4 = Free form answer
`SEASON` | 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.
`SECOND` | Reference | Second hierarchy level as defined in Time Hierarchy.
`SECURE HOLDER` | 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.
`SECURITY REQUIRED TYPE` | Lookup | Lookup for type and description of security requirements that may be associated with an ITEM.
`SEGMENT CRITERIA` | Reference | Minimum and Maximum scores for each segment associated with an ACCOUNT SEGMENT or CUSTOMER SEGMENT.
`SEGMENT TYPE` | Lookup | Lookup for type codes and descriptions used to define ACCOUNT SEGMENTATION MODEL or CUSTOMER SEGMENTATION MODEL.
`SELLING LOCATION` | Reference | Physical location in a RETAIL STORE specifically dedicated to selling or displaying merchandise.
`SELLING LOCATION TYPE` | Lookup | Lookup for type code and description used to define a SELLING LOCATION: For example: Store Floor Aisle Shelf
`SERVICE` | Reference | Service is an internal technical presentation of available PRODUCTs to the end user. Different customers may subscribe to different services under the same product name. For example, for a service of 4MB Broadband, the service may be implemented by ADSL service or by FTTH (Optical Fiber).
`SERVICE BUNDLE` | Reference | Conceptually, a Service Bundle is thought of as a collection of Element Facing Service Specifications. This entity enables the needs of different sets of Element Facing Service Specifications to be grouped together - hence, the name "bundle". Since these are Resource Facing Specifications, they define reusable templates for implementing the Element Facing Services that are required by a particular CUSTOMER FACING SERVICE (as represented by a SERVICE PACKAGE). Service Bundles were designed to define a set of Class of Service specifications that were required by a CUSTOMER FACING SERVICE to work together. A SERVICE PACKAGE is the entity that models the requirements of the CUSTOMER FACING SERVICE. Thus, SERVICE PACKAGEs can specify different packaging of CUSTOMER FACING SERVICE that are sold to the Customer, and Service Bundles specify the set of Element Facing Services that each CUSTOMER FACING SERVICE requires. Service Bundles are a natural way to implement the requirements of a SERVICE PACKAGE, and are related to a SERVICE PACKAGE through the Service Package Uses Service Bundles aggregation.
`SERVICE BUNDLE SPEC` | Reference | A Service Bundle Spec is the base entity for defining the different classes of bundled Element Facing Service Specs that a Customer (or some other appropriate PARTY ROLE) can subscribe to. The preferred way to represent a Customer subscription of this nature is by defining a Service Bundle Spec that defines the set of Element Facing Service Specs that are being used. Conceptually, a Service Bundle Spec is thought of as a collection to enable the needs of different sets of Element Facing Service Specs to be grouped together. The "bundle" conveys the concept of grouped Service Specs that are related. Since these are Resource Facing Specifications, they define reusable templates for implementing the Element Facing Services that are required by a particular CUSTOMER FACING SERVICE (as represented by a SERVICE PACKAGE).
`SERVICE BUNDLE SPEC ATOMIC` | Reference | A Service Bundle Spec Atomic object models different SERVICE BUNDLE SPECs as a set of different instances of individual, independent Element Facing Service Specs. This is fundamentally different than the SERVICE BUNDLE SPEC COMPOSITE entity, which models one SERVICE BUNDLE SPEC COMPOSITE as the combination of other existing SERVICE PACKAGE SPECs (as well as providing its own extensions). For example, assume that the Gold Package service offering (which is a subclass of Service Package, not SERVICE PACKAGE SPEC), requires two different CoS Service instances. This may be because the Gold Package service offering has two different groups of applications that require two different types of traffic conditioning mechanisms. This is represented by a Service Bundle Spec Atomic object. Now, assume that the Platinum Package service offering includes the Gold Package service offering and a new service offering requiring a new set of traffic conditioning mechanisms. This requires a second Service Bundle Spec Atomic object, as users want to reuse the first Service Bundle Spec Atomic object. These could be aggregated to form an instance of a SERVICE BUNDLE SPEC COMPOSITE entity.
`SERVICE BUNDLE SPEC COMPOSITE` | Reference | A Service Bundle Spec Composite defines an integrated set of SERVICE BUNDLE SPECs that collectively meets the needs of a Element Facing Service Spec Composite entity. This is fundamentally different than the Service Bundle Spec Atomic object, which models one Service Bundle Spec as the combination of other existing SERVICE PACKAGE SPECs (as well as providing its own extensions). For example, assume that the Gold Package service offering (which is a subclass of SERVICE PACKAGE, not SERVICE PACKAGE SPEC), requires two different CoS Service instances. This may be because the Gold Package service offering has two different groups of applications that require two different types of traffic conditioning mechanisms. This is represented by a SERVICE BUNDLE SPEC ATOMIC entity. Now, assume that the Platinum Package service offering includes the Gold Package service offering and a new service offering requiring a new set of traffic conditioning mechanisms. This requires a second SERVICE BUNDLE SPEC ATOMIC entity, as you want to reuse the first SERVICE BUNDLE SPEC ATOMIC entity. These could be aggregated to form an instance of a Service Bundle Spec Composite object.
`SERVICE BUSINESS ACTOR` | Reference | This is an association entity. The entity represents the semantics, for example, owns, uses, and other relationships, of a Business Actor using a particular SERVICE.
`SERVICE CHARACTERISTIC` | 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.
`SERVICE CHARACTERISTIC ASSIGNMENT` | Reference | A use of the Service Spec Characteristic by an Service Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Service Spec Characteristic.
`SERVICE CHARACTERISTIC RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between or among Service Spec Characteristics.
`SERVICE CHARACTERISTIC VALUE` | Reference | A Service Spec Characteristic Value object defines a set of attributes, each of which can be assigned to a corresponding set of attributes in a Service Spec Characteristic object. The values of the attributes in the Service Spec Characteristic Value object describe the values of the attributes that a corresponding Service Spec Characteristic object can take on.
`SERVICE CHARACTERISTIC VALUE ASSIGNMENT` | Reference | A use of the Service Spec Characteristic Value by an Entity Specification to which additional properties (attributes) apply or override the properties of similar properties contained in Service Spec Characteristic Value.
`SERVICE CHARACTERISTIC VALUE RELATIONSHIP` | Reference | A aggregation, migration, substitution, dependency, or exclusivity relationship between/among Service Spec Characteristic Values.
`SERVICE CLASS` | 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.
`SERVICE CLASS TYPE` | Lookup | Lookup for the type or base to define the SERVICE CLASS.
`SERVICE COVERAGE AREA` | 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.
`SERVICE COVERAGE AREA TYPE` | Lookup | Lookup for type code and description for SERVICE COVERAGE AREA.
`SERVICE COVERAGE GEO DETAIL` | Reference | The detail about service coverage on lowest level. For example: Areas covered by a specific BTS Building covered by Broadband Copper line or Fiber line.
`SERVICE DEPENDENCY` | 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.
`SERVICE DEVICE INTERFACE ASSIGNMENT` | Reference | Captures the semantics involved in representing how a particular Element Facing Service is implemented on a specific DEVICE INTERFACE.
`SERVICE EQUIPMENT ASSIGNMENT` | Reference | Assignments between NETWORK TOUCHPOINT, EQUIPMENT, and SERVICE according to which SERVICE was tied to which NETWORK TOUCHPOINT through which EQUIPMENT INSTANCE.
`SERVICE LEVEL AGREEMENT` | Reference | A special type of contract which keeps the agreement between a customer and the service provider specifying the service quality, including availability, bandwidth, and so on. The detailed terms of the service level agreement are specified in CONTRACT TERM VALUE.
`SERVICE LEVEL AGREEMENT ITEM` | Reference | Detail line items for a SERVICE LEVEL AGREEMENT.
`SERVICE LEVEL AGREEMENT TYPE` | 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.
`SERVICE LEVEL OBJECTIVE` | Reference | Quality goal for a Service Level Specification defined in terms of parameters and metrics, thresholds, and tolerances associated with the parameters.
`SERVICE LEVEL SPEC APPLICABILITY` | 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.
`SERVICE LEVEL SPEC CONSEQUENCE` | Reference | An action that takes place when a SERVICE LEVEL OBJECTIVE is not met.
`SERVICE LEVEL SPEC PARAMETER` | Reference | Specifies a variable whose value determines compliance with a Service Level Objective.
`SERVICE LEVEL SPECIFICATION` | Reference | A pre-defined or negotiated set of service level objectives, and consequences that occur, if the objectives are not met.
`SERVICE LEVEL UNMET CONSEQUENCE TYPE` | Lookup | Lookup for the type of consequences if the service level requirement is not met.
`SERVICE LR DEPENDENCY` | Reference | This is an association entity. The Service LR Dependency represents the semantics (for example, exists, uses, and other relationships) that exist when a LOGICAL ELEMENT helps to supply or to support a particular Element Facing Service.
`SERVICE NETWORK ELEMENT ASSIGNMENT` | Reference | Defines how a network element supports a service.
`SERVICE ORDER` | Base | A type of Request that represents the products in a Customer Order decomposed into the services through which the products are realized.
`SERVICE ORDER LINE ITEM` | Base | The purpose for the SERVICE ORDER expressed in terms of a SERVICE SPEC or a Service.
`SERVICE PACKAGE` | Reference | A Service Package is derived from an associated SERVICE PACKAGE SPEC. The SERVICE PACKAGE SPEC defines the invariant attributes, methods, relationships, and constraints for all Service Package instances that are derived from it. This entity enables each individual Service Package to add its own application-specific changeable characteristics and behavior. There is no specific aggregation used to relate a particular Service Package to the SERVICE PACKAGE SPEC that it is derived from. This is because the SERVICE PACKAGE SPEC and Service Package both inherit the Specifies Service aggregation, and at this (the business level) view, there are no new semantics that are required to represent this relationship. Finally, while the composite pattern could be applied to Service Package, there is no perceived need to do so. Multiple Service Packages will simply be aggregated by a Product Bundle, and appear as separate Product Components.
`SERVICE PACKAGE BUNDLE ASSIGNMENT` | Reference | Defines how service bundle implements SERVICE PACKAGE.
`SERVICE PACKAGE BUNDLE DETAIL` | Reference | Defines how a type of service bundle can support other types of SERVICE PACKAGEs.
`SERVICE PACKAGE SPEC` | Lookup | A Service Package Spec defines the concept of bundling a set of different CUSTOMER FACING SERVICE SPECs to meet the functionality specified by one or more Product Specifications. This entity enables the specification of the invariant characteristics and behavior of these CUSTOMER FACING SERVICEs, so that multiple PRODUCTs can be built from their associated Product Specification. Treating this set of CUSTOMER FACING SERVICE SPECs as a single object is important for building complex Services, such as a VPN. This entity enables a single Product Item, derived ultimately from a Product Specification, to be offered to the Customer, even though in reality the Product Item consists of a set of different CUSTOMER FACING SERVICEs that must work to provide the functionality that the Customer needs.
`SERVICE PACKAGE SPEC ATOMIC` | Lookup | A Service Package Spec Atomic object models different SERVICE PACKAGE SPECs as a set of different instances of individual, independent CUSTOMER FACING SERVICE SPECs. This is fundamentally different than the Service Package Spec Composite object, which models one SERVICE PACKAGE SPEC as the combination of other existing SERVICE PACKAGE SPECs (as well as providing its own extensions). For example, Gold Package Spec is an individual packaging of services, and is therefore an instance of the Service Package Spec Atomic entity. If there was a service offering that combined the services defined by the Gold Package Spec with those defined by another Service Package Spec Atomic entity, such as the Platinum Package Spec, then that combination could be aggregated, forming an instance of the Service Package Spec Composite entity.
`SERVICE PACKAGE SPEC COMPOSITE` | Lookup | This models different packages as the combination of other existing SERVICE PACKAGEs (as well as providing its own extensions). This is fundamentally different than Service Package Atomic, which models different SERVICE PACKAGEs as a set of different instances.
`SERVICE PERFORMANCE` | Reference | A measure of the manner in which a SERVICE is functioning.
`SERVICE PERFORMANCE SPEC` | Lookup | The invariant characteristics of a measure of the manner in which a SERVICE is functioning. Each related PERFORMANCE instance will have the same invariant characteristics. However, the values associated with other characteristics of the instantiated PERFORMANCE entity are specific to each instance.
`SERVICE PR DEPENDENCY` | Reference | This is an association entity. The Service PR Dependency represents the semantics (for example, exists, uses, and other relationships) that exist when a PHYSICAL ELEMENT helps to supply or to support a particular RESOURCE FACING SERVICE.
`SERVICE REQUEST` | Base | Subtype of PARTY INTERACTION THREAD, specifically dedicated to a service request that may trigger a customer field service support order.
`SERVICE ROLE` | Reference | This entity defines a SERVICE in terms of a set of roles. The roles are then used to characterize the functionality of the Service, regardless of whether it is a Element- or a customer-facing service. Service Roles represent the functionality of a Service, and as such are a mix of the invariant and changeable characteristics and behavior of a Service. Representing a SERVICE in terms of Service Roles enables the functionality of the SERVICE to be defined independently of Business Actor, PHYSICAL ELEMENT, LOGICAL ELEMENT, or other Services.
`SERVICE SPECIFICATION ROLE` | 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.
`SERVICE SPEC` | Reference | This entity defines the ServiceSpecification hierarchy. All Services are characterized as either being directly visible and usable by a Customer or not. This gives rise to the two subclasses of Service: CUSTOMER FACING SERVICE and ElementFacingService. However, each instance of a Service is made up of changeable as well as invariant attributes, methods, relationships and constraints. A ServiceSpecification defines the invariant characteristics of a Service. It can be conceptually thought of as a template that different Service instances can be instantiated from. Each of these Service instances will have the same invariant characteristics. However, the other characteristics of the instantiated Service will be specific to each instance. This entity can be thought of as a template, which represents a generic specification for implementing a particular type of Service. A ServiceSpecification may consist of other ServiceSpecifications supplied together as a collection. Members of the collection may be offered individually or collectively. ServiceSpecifications may also exist within groupings, such as within a Product.
`SERVICE SPEC ATOMIC` | Reference | This entity defines SERVICE SPECs that do not have any subordinate SERVICE SPECs. In other words, a ServiceSpecAtomic is a standalone SERVICE SPEC, and does not require any supporting SERVICE SPECs to define the invariant characteristics of Services that it serves as a template for.
`SERVICE SPEC COMPOSITE` | Reference | This entity defines SERVICE SPECs that are formed by aggregating other SERVICE SPECs. The types of SERVICE SPECs that are aggregated may be ServiceSpecAtomic or ServiceSpecComposite instances. A ServiceSpecComposite collectively defines all of the invariant characteristics of Services that it serves as a template for.
`SERVICE SPEC NETWORK ELEMENT TYPE RELATIONSHIP` | Reference | Defines the relationship between Service Spec and Network Element. For example, to track which Network Element Type is required for a certain type of Service Spec to work.
`SERVICE SPEC PRODUCT RELATIONSHIP` | Reference | Defines the relationship between Service Spec and Product, for example, to track which Product requires which Service Spec.
`SERVICE SPEC VERSION` | Reference | This entity represents the ability to distinguish between different instances of SERVICE SPECs. It represents a particular form or variety of a SERVICE SPEC that is different from others or from the original. The form represents differences in attributes, methods, relationships, and/or constraints that characterize this particular SERVICE SPEC, but which are not enough to warrant creating a new SERVICE SPEC.
`SERVICE TYPE ATOMIC` | Lookup | This entity defines Service Specifications that do not have any subordinate Service Specifications. In other words, a Service Spec Atomic is a standalone Service Specification, and does not require any supporting Service Specifications to define the invariant characteristics of Services that it serves as a template for.
`SERVICE TYPE COMPOSITE` | Lookup | This entity defines Service Specifications that are formed by aggregating other Service Specifications. The types of Service Specifications that are aggregated may be Service Spec Atomic and/or Service Spec Composite instances. A Service Spec Composite collectively defines all of the invariant characteristics of Services that it serves as a template for.
`SERVICE TYPE VERSION` | Lookup | Represents the ability to distinguish between different instances of Service Specifications. The Service Type Version represents a particular form or variety of a Service Specification that is different from others or from the original. The form represents differences in attributes, methods, relationships, and/or constraints that characterize this particular Service Specification, but which are not enough to warrant creating a new Service Specification.
`SERVICE USAGE TYPE` | Lookup | A detailed description of a service usage event (for example, a purchase or a usage of a service).
`SET TOP BOX` | Reference | Set-top box for Television service.
`SET TOP BOX MODEL` | Reference | Set-top box model specification.
`SHARED PACKAGE USAGE STATISTICS DAY DRVD` | Derived | Daily aggregate of Lines Count by PRODUCT MARKET PLAN. For example: Family 1+1 Corporate Package
`SHARED PACKAGE USAGE STATISTICS MO AGGR` | Aggregate | Monthly summary of Lines Count by PRODUCT MARKET PLAN. The usage and profitability is analyzed in this entity. For example: Family 1+1 Corporate Package
`SHELF` | Reference | A Shelf is a type of Equipment Holder that is designed to hold various types of Equipment. The Shelf has a logical identifier that is often relative to the Bay that contains the Shelf (that is, the unique identifier for a Shelf is often a concatenation of the network element identifier, the Bay identifier, and the Shelf identifier). The logical identifier of a Shelf is typically associated with the Device (that is, the Network Element). Compare this to a RACK, whose logical identifier is not associated with the Device. Thus, the Shelf is explicitly a part of the logical model of a network. Often, a Shelf contains not just pluggable components (for example, CARDs, Power Supplies, and so on) but also cabling (for example, both fiber and wire), with optional connections to external fuse, alarm, and other types of panels.
`SHOP EFFICIENCY DAY DRVD` | Derived | Daily aggregate of shop efficiency details including customer and transaction counts, wait times, and so on, by ORGANIZATION BUSINESS UNIT and GEOGRAPHY REGION.
`SHOP EFFICIENCY MONTH AGGR` | Aggregate | Monthly summary of shop efficiency details including customer and transaction counts, wait times, and so on, by ORGANIZATION BUSINESS UNIT and GEOGRAPHY REGION.
`SIC ASSIGNMENT` | Reference | Assigns one industry to another industry in Standard Industrial Classification (SIC).
`SIC ASSIGNMENT REASON` | Lookup | Lookup for reason codes and descriptions that describe why two industries are assigned in the Standard Industrial Classification (SIC).
`SIC CLASSIFICATION` | Lookup | A classification group for Standard Industrial Classification (SIC). For example: A. Division A: Agriculture, Forestry, And Fishing: Major Group 01: Agricultural Production Crops Major Group 02: Agriculture Production Livestock and Animal Specialties Major Group 07: Agricultural Services Major Group 08: Forestry Major Group 09: Fishing, Hunting, and Trapping
`SIC DIVISION` | Reference | The base level of SIC classification. For more information see SIC CLASSIFICATION.
`SIC INDUSTRY GROUP` | Lookup | The middle level of the industry classification hierarchy.
`SIGNALING PROTOCOL` | 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.
`SIM CARD` | 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.
`SIM CARD ACCESS METHOD ASSIGNMENT` | 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.
`SIM CARD ACCESS METHOD REASON` | Lookup | Lookup for valid reason codes and descriptions to describe relationship between SIM CARD and ACCESS METHOD.
`SIM CARD ACTIVATION REASON` | Lookup | Lookup for valid reason codes and descriptions describing why a SIM CARD has been activated.
`SIM CARD ACTIVATION TYPE` | Lookup | Usage states that a SIM CARD may be in. For example: PP: Pre-Provisioned BU: Barred from Usage
`SIM CARD HANDSET ASSIGNMENT` | Reference | A history of relationship between a HANDSET INSTANCE and a SIM CARD. SIM Cards can be swapped between handsets.
`SIM CARD SUBSCRIPTION ASSIGNMENT` | Reference | A history of relationship between the SIM CARD and a SUBSCRIPTION.
`SIM CARD SUBSCRIPTION REASON` | Lookup | A reason why a SIM CARD is associated with a SUBSCRIPTION.
`SIM CARD TYPE` | Lookup | Lookup for the types of SIM CARD. For example: 16k 32k 64k 128k
`SITE` | Reference | Site is any geographical location of interest to the telecom operator.
`SITE INTERFACE ROLE` | 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.
`SITE TYPE` | Lookup | Lookup of all possible types of sites of interest to the service provider.
`SKILL TYPE` | Lookup | Lookup of available skill types for an individual party.
`SLOT` | 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.
`SLOT RELATIONSHIP` | 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.
`SMS` | Reference | Subtype of VALUE ADDED SERVICE. This entity defines the information relative to the Short Message Service (SMS). Do not confuse this entity with SMS EVENT.
`SMS EVENT` | Base | Subtype of NETWORK EVENT, which collects all information of product usage of Short Message Service (SMS).
`SMS RATING PLAN` | Reference | Subtype of PRODUCT RATING PLAN, reserved for Short Message Service (SMS), and also Multimedia Messaging Service (MMS), service.
`SOC JOB` | Reference | Entity holds the most detailed level of Standard Occupational Classification (SOC) job classification. For example: 15-0000 Computer and Mathematical Occupations 15-1000 Computer Specialists 15-1010 Computer and Information Scientists, Research 15-1011 Computer and Information Scientists, Research 15-1020 Computer Programmers 15-1021 Computer Programmers 15-1030 Computer Software Engineers 15-1031 Computer Software Engineers, Applications 15-1032 Computer Software Engineers, Systems Software 15-1040 Computer Support Specialists 15-1041 Computer Support Specialists
`SOC JOB CATEGORY` | 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: 13-2010 Accountants and Auditors 13-2020 Appraisers and Assessors of Real Estate 13-2030 Budget Analysts 13-2040 Credit Analysts 13-2050 Financial Analysts and Advisors 13-2060 Financial Examiners
`SOC JOB GROUP` | 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: 13-1000 Business Operations Specialists 13-2000 Financial Specialists
`SOC JOB MAJOR GROUP` | 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: 11-0000 Management Occupations 13-0000 Business and Financial Operations Occupations 15-0000 Computer and Mathematical Occupations 17-0000 Architecture and Engineering Occupations 19-0000 Life, Physical, and Social Science Occupations 21-0000 Community and Social Services Occupations 23-0000 Legal Occupations
`SOFTWARE` | 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.
`SOFTWARE ATOMIC` | 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.
`SOFTWARE COMMAND` | Reference | Software Commands describe the sets of features that are programmable by a particular PARTY ROLE. For example, a Developer, or Network Operator, and in rare cases, an End User. This should not be confused with Capabilities. Capabilities define what features and functions are available at a given moment for the Element. Thus, Software Commands represent the specific commands that are available in a device, whereas Capabilities represent higher-level generic functions available in a Element. For example, the ability to perform BGP routing is a Capability, whereas the actual commands used to implement BGP routing are Software Commands.
`SOFTWARE COMPOSITE` | 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.
`SOFTWARE FEATURE SETS` | Reference | Software Feature Sets describe the groups of Software Commands that distinguish a particular release of Software. The Software Commands contained in the Software Feature Sets are programmable by a particular PARTY ROLE (for example, a Developer, or Network Operator, and in rare cases and End User). Often, Software Feature Sets are used by the manufacturer to define a custom or semi-custom build of software, or are provided as a set of options that are orderable by the Customer. This should not be confused with Capabilities. Capabilities define what features and functions are available at a given moment for the Element. Thus, Software Feature Sets represent groups of commands that are available in a device, whereas Capabilities represent higher-level generic functions available in a Element. For example, the ability to perform BGP routing is a Capability, whereas the actual commands used to implement BGP routing are Software Commands that reside in one or more Software Feature Sets. Hence, Software Feature Sets may or may not offer BGP as a programmable feature.
`SOFTWARE OS RELATIONSHIP` | 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.
`SOURCE SYSTEM` | Reference | System of record from which information was loaded.
`SOURCE SYSTEM KEY MAPPING` | 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.
`SOURCE SYSTEM TYPE` | Lookup | Lookup for type code and description used to describe SOURCE SYSTEM. For example: Competitor Customer Listing Third-Party Purchased Mailing List CRM List Billing System List
`SPECIFICATION` | Reference | This is an entity that defines the invariant characteristics, attributes, methods, and relationships, of a managed entity.
`SPECIFICATION ROLE` | Reference | This is the entity for all Role Specification subclasses.
`SPECTRUM COVERAGE AREA` | Reference | The geographic coverage area of a given wireless spectrum.
`STATISTICAL ENTITY` | Reference | To be defined
`SUB NETWORK` | 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.
`SUBSCRIBER ACTIVATION REASON` | Lookup | Lookup for valid Subscriber activation code and reasons used to describe Subscriber Activation. For example: Reactivate because of paying Deactivate by non-paid
`SUBSCRIBER CHURN STATISTIC DRVD` | Derived | Monthly aggregate of subscriber Churn information by ACCOUNT, PRODUCT MARKET PLAN, SALES CHANNEL, AGE BAND, AGE ON NET BAND, CREDIT CATEGORY, DEBT AGING BAND, CUSTOMER REVENUE BAND, ARPU BAND, CUSTOMER.
`SUBSCRIBER CHURN STATISTIC MONTH AGGR` | Aggregate | Monthly summary of Subscriber Churn by PRODUCT, PRODUCT MARKET PLAN, CUSTOMER TYPE, GEOGRAPHY ENTITY, ORGANIZATION BUSINESS UNIT.
`SUBSCRIPTION` | Reference | The record of customer using a product or service which may be based on a contract. Customer's subscription to services is the basis of billing and network usage authorization.
`SUBSCRIPTION ASSIGNMENT` | Reference | Relational assignment of one SUBSCRIPTION to another SUBSCRIPTION. This is optional.
`SUBSCRIPTION ASSIGNMENT TYPE` | Lookup | Lookup for type codes and descriptions pertaining to SUBSCRIPTION ASSIGNMENT.
`SUBSCRIPTION EVENT TYPE` | Lookup | Lookup for available type codes and descriptions for Subscription Events.
`SUBSCRIPTION NETWORK ELEMENT ROLE ASSIGNMENT` | Reference | Defines the relationship between SUBSCRIPTION and the NETWORK ELEMENT ROLE.
`SUBSCRIPTION PMP ASSIGNMENT` | Reference | The relationship between SUBSCRIPTION and PRODUCT MARKET PLANs. A SUBSCRIPTION may be reassigned to different PRODUCT MARKET PLANs during its lifetime.
`SUBSCRIPTION PRICE` | Reference | Charge information over a specific subscription.
`SUBSCRIPTION PRICE ALTERATION` | Reference | Price alteration applied to the given subscription.
`SUBSCRIPTION PRICE CHARGE` | Reference | The monetary charge applied to an individual subscription, as a subtype of SUBSCRIPTION PRICE.
`SUBSCRIPTION PRICE PARTY ROLE ASSIGNMENT` | Reference | The relationship between the Party Role and SUBSCRIPTION PRICE to track who managed the SUBSCRIPTION PRICE.
`SUBSCRIPTION SERVICE CLASS ASSIGNMENT` | Reference | Defines the class of service for a SUBSCRIPTION.
`SUBSCRIPTION STATUS` | Lookup | Lookup for available code and description for the status of a SUBSCRIPTION. For example: Active Inactive
`SUBSCRIPTION STATUS CATEGORY` | Lookup | Lookup for category codes and descriptions used to group or categorize SUBSCRIPTION STATUS.
`SUBSCRIPTION STATUS HISTORY` | Base | A history of the status of a SUBSCRIPTION. For example: Active Inactive Defaulted Terminated The subscription can simultaneously contain multiple status. For example, the subscription could be Active and In_Debt, or amount below threshold.
`SUBSCRIPTION STATUS REASON` | Lookup | Lookup for available reason codes and descriptions for defining why a SUBSCRIPTION may be assigned a status.
`SUBSCRIPTION TERM TYPE` | Lookup | Lookup for available type codes and descriptions pertaining to SUBSCRIPTIONs and PRODUCTs to which Values may be assigned. For example: Monetary Amount Period Premium Initial Points Cancellation Policy
`SUBSCRIPTION TERM VALUE` | Base | Value assignments for Subscription Terms as pertains to a SUBSCRIPTION and PRODUCT. For example: Monetary amount Period Premium Initial points The value can vary at different time periods. For example, the monthly fee might be 100 for first six months, and 80 for last six months. A penalty calculation can also be assigned based on the months left in a contract.
`SUBSCRIPTION TYPE` | Lookup | Lookup for available type codes and descriptions for SUBSCRIPTIONs. For example: Prepaid Wireless Fixed Line Broadband
`SUBSIDY AMOUNT MONTH AGGR` | Aggregate | Monthly summation of the amount budgeted for the items to be given on subsidy by PRODUCT MARKET PLAN, and CUSTOMER TYPE, excluding the NVP scheme items and give-away items.
`SUBSIDY AMOUNT DRVD` | Derived | Monthly aggregation of the amount budgeted for the items to be given on subsidy by PRODUCT MARKET PLAN and CUSTOMER TYPE, excluding the NVP scheme items and give-away items.
`SUBSIDY TYPE` | Lookup | Lookup for type code and description of a Subsidy.
`SUPPLEMENTARY SERVICE` | Reference | Subtype of PRODUCT that may include supplementary services to complement and support existing services such as telephone and data services. For example: Call forwarding Barring of Outgoing Calls Barring of Incoming Calls Advice of Charge (AoC) Call Hold Call Waiting Multi-party service Calling Line Identification presentation/restriction Closed User Groups (CUGs) Explicit Call Transfer (ECT)
`SUPPLEMENTARY SERVICE USAGE DRVD` | Derived | Keep the aggregation information for usage of supplementary service. Analyze SUPPLEMENTARY SERVICE for the Core Network Planning.
`SUPPLEMENTARY SERVICE USAGE MONTH AGGR` | Aggregate | Monthly summation of Charge and Billing details for SUPPLEMENTARY SERVICE usage by Business Unit, PRODUCT MARKET PLAN, and PRODUCT.
`SURVEY` | Reference | A survey is a subtype to the PROMOTION.
`SWITCH` | Reference | Network switches or exchanges. A switch may be a PSTN (wireline) digital or analog, or a GSM Mobile Station controller (wireless).
`SWITCH CAPABILITY` | 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).
`SWITCH CAPABILITY TYPE` | Lookup | Lookup for type codes and descriptions used to categorize SWITCH CAPABILITY.
`SWITCH COMMAND` | Reference | Command which is sent to the switch, telling it to take an action. For example, activate a port with specified parameters.
`SWITCH ROUTING DEVICE ASSIGNMENT` | Reference | Assigns a routing device to a switch in any type of network.
`SWITCH TYPE` | Lookup | Classification of Switch Type and Manufacturer.
`SWITCHING PROTOCOL` | Reference | This entity represents different types of switching protocols that can be managed. Switching protocols are those protocols that enable routing to take into account layer 2 information, such as bandwidth and QoS. (Remember that traditional routing protocols are designed to evaluate each frame's layer 3 header only). Several methods are available for accomplishing the task of looking at layer 2 information and defining a next hop. Most now use the concept of a label, which is a means to define the next hop without evaluating all of the information of a traditional header.
`SWITCHING ROLE` | 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.
`SWOT TYPE` | 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.
`TAP IN WIRELESS ROAMING EVENT` | Base | Network events invoked by our customer on partners network. Those events should be attached to the account for billing purposes.
`TAP OUT WIRELESS ROAMING EVENT` | Base | Network events by partner customer on the operator network.
`TARGET ACCESS METHOD` | Reference | The ACCESS METHODs associated with a PROMOTION.
`TARGET ACCOUNT` | Reference | ACCOUNTs targeted by a PROMOTION.
`TARGET CONTRACT` | Reference | CONTRACTs targeted by a PROMOTION.
`TARGET GEOGRAPHY AREA` | Reference | GEOGRAPHY ENTITYs targeted by a PROMOTION.
`TARGET MARKET SEGMENT` | Reference | The MARKET SEGMENTs included in a specific CAMPAIGN.
`TARGET TYPE` | Lookup | Lookup for valid Type codes and descriptions as pertain to a PROMOTION. For example: CUSTOMER ACCOUNTs ACCESS METHOD Geography area
`TAX AUTHORITY` | Reference | A government authority that levies sales taxes and on whose behalf the store collects these sales taxes. For Example: National State Province City County Other
`TAX CATEGORY` | Lookup | The tax categories which may be applied to invoices items.
`TAX EXEMPT` | Lookup | Lookup for valid tax exempt codes and descriptions as pertains to an ITEM.
`TCH TYPE` | Lookup | Lookup for the types of Traffic Channel. For example: Voice Channel Data Channel
`TECHNOLOGY` | Lookup | Technology names and descriptions that can define a NETWORK ELEMENT. For example: CDMA GSM ADSL Ethernet
`TECHNOLOGY TYPE` | Lookup | Lookup for available type codes and descriptions that can classify or categorize a TECHNOLOGY. For example: Wireless Copper line Optical Fiber
`TELEPHONE NUMBER` | Reference | The phone number as a subtype of access method.
`TELEPHONE NUMBER POOL` | Reference | The telephone number pool allocated to the TELCO operator.
`TEMPLATE SERVICE LEVEL SPEC` | Reference | The template for SERVICE LEVEL AGREEMENT spec.
`TERMINATION POINT` | 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.
`TIME BAND` | Lookup | Band of call duration. For example: 0-5 minutes 5-30 minutes 30-120 minutes >120 minutes
`TIME SLOT` | 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.
`TIME STANDARD BY DAY` | 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.
`TIME STANDARD BY WEEK` | 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.
`TIME ZONE` | Lookup | Lookup for the Geographic time zone as related to the Greenwich Mean Time (GMT +0.00).
`TRAIL` | 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.
`TRAIL TERMINATION POINT` | 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.
`TV CHANNEL` | Reference | Type of PRODUCT INSTANCE associating a Television Channel with a PTV USAGE EVENT.
`UMS ACCESS 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.
`UMS EVENT` | Base | Subtype of NETWORK EVENT. In the UMS notification type dimension, Unified Messaging Service (UMS) is an advanced version of Voice Message Service (VMS). As it is possible to notify the subscriber using UMS by either SMS or by internet mail, similarly a subscriber can access a mailbox in different ways, including by calling a standard access number or through the internet. The information related to UMS access is to be analyzed by the type of access. UMS access type dimension will be used to fulfill this requirement.
`UMS EVENT TYPE` | Lookup | Lookup for the type of UMS events. For example: E-mail SMS Fax Voicemail Video Messaging
`UNIT OF MEASURE` | Lookup | Lookup for possible measurement units valid for the data within the system. For example: Inch Kilowatt-hour Days Cubic centimeters
`URBAN PROPERTY ADDRESS` | Reference | The property address in the format of an urban area.
`USER` | 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.
`VALUE ADDED SERVICE` | Reference | Type of product consisting of supplementary or value added services such as Call Forward, Call barring, CLI, CLIR, UMS, or VMS.
`VALUE CUSTOM` | 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.
`VALUE MEASURE` | Lookup | Lookup for unit of measure for the value. For example a customer or a profile can be valued in terms of monetary value or time (a customer for next three years).
`VALUE STANDARD` | 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.
`VALUE TYPE` | Lookup | Lookup for available type codes and descriptions pertaining to defining the derived value of a CUSTOMER or PROSPECT.
`VARIABLE CUSTOM` | 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.
`VARIABLE STANDARD` | Reference | This entity defines a standard set of POLICY VARIABLE objects that are common to most PBNM applications.
`VAS SUBSCRIPTION` | Reference | Type of Subscription that includes VALUE ADDED SERVICE.
`VAS SUBSCRIPTION QUICK SUMMARY MO AGGR` | Aggregate | Monthly Summary of VALUE ADDED SERVICE Details by CUSTOMER TYPE.
`VAS SUBSCRIPTION QUICK SUMMARY DRVD` | Derived | Monthly Aggregation of VALUE ADDED SERVICE Details by CUSTOMER and ACCESS METHOD.
`VAS USAGE DAY DRVD` | 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.
`VAS USAGE MONTH AGGR` | Aggregate | Monthly aggregation of VAS usage statistics, from VAS USAGE DAY DRVD.
`VENDOR` | Reference | Supplier or source of equipment or supplies.
`VENDOR APPOINTMENT` | Base | Single or recurring appointment times allocated for VENDOR representative to visit the Provider or Retail Site.
`VENDOR CLASS` | Lookup | Lookup for the classification of Vendors. For example: Primary Associate Direct Supply
`VENDOR CONTRACT` | Reference | Time bound agreement with VENDOR.
`VENDOR FACTOR COMPANY ASSIGNMENT` | Reference | Defines the relationship between VENDOR and FACTOR COMPANY.
`VENDOR RATING` | Reference | Score assigned to VENDOR based on performance criteria.
`VENDOR RATING TYPE` | Lookup | Lookup for type codes and descriptions of VENDOR RATING performance criteria.
`VENDOR SITE` | 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.
`VENDOR SITE COURIER ASSIGNMENT` | Reference | Association of VENDOR SITE with COURIER code (from the goods transportation perspective).
`VENDOR SITE TYPE` | Lookup | Lookup for valid type codes and descriptions pertaining to VENDOR SITE. For example: Call center Branch Office Warehouse
`VIRTUAL TEAM` | Reference | Type of Business Unit formed for a specific purpose. For example: Sales Team A, B, C Customer Support Team A, B, C Project team Strategic Account management team including sales and support
`VOICE MESSAGE SERVICE` | Reference | Subtype of SERVICE.
`VOICE CALL DAY DRVD` | Derived | Daily aggregate of Voice Call statistics by TIME SLOT, Business Unit, County, PRODUCT, CUSTOMER TYPE, Call Source, Call Destination, CALL DIRECTION, Call Success/Failure, Roaming Service.
`VOIP CALL EVENT` | Base | The subtype of Network event, specialized for Voice Over IP (VOIP) Calls.
`VOICE CALL MONTH AGGR` | Aggregate | Monthly Summary of Voice Call statistics by Business Unit, County, PRODUCT, CUSTOMER TYPE, CALL CATEGORY, CALL DIRECTION, Call Success/Failure.
`VOLUME BAND` | Lookup | Characterizes network events by volume. The volume characteristic may be in units of bytes, minutes, packets, downloads. The entity is used as part of the rating of calls and other network events.
`VPN LOGICAL DEVICE ROLE` | 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.

Table 2-29 W to Z Entity Descriptions

Entity Name | Type | Description
--- | --- | ---
`WAN PROTOCOL` | 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.
`WEATHER CONDITION` | 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.
`WEB PAGE` | Reference | A web page on a service operator Web site. The Web page may present a product or handle a customer service request.
`WEB PAGE CONTENT` | Reference | Content of a WEB PAGE, links WEB PAGE to its relevant entity, including product, script, and so on.
`WEB PAGE TYPE` | Lookup | Web page type groups the web pages according to their content and purpose. For example: Service page Advertisement Tariff plan
`WEEK TODATE TRANSFORMATION` | Reference | Cumulative time transformations at the week level.
`WEEK TRANSFORMATION` | Reference | Time transformations at the week level.
`WEEKDAY` | Reference | Calendar weekdays.
`WIRELESS CALL EVENT` | Base | Defines occurrence of wireless call.
`WIRELESS CONTENT DOWNLOADING EVENT` | Base | Type of network event, to track wireless content downloading such as music, video clips, and so on.
`WIRELESS NETWORK ELEMENT` | Derived | Derived from NETWORK ELEMENT Hierarchy for analytical purposes.
`WIRELESS RATING PLAN` | Reference | Subtype of PRODUCT RATING PLAN, reserved for wireless voice and data services.
`WIRELESS ROAMING EVENT` | 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.
`WIRELESS ROAMING EVENT BATCH` | Base | The batch which includes roaming events as details. This batch normally appears in one TAP file.
`WIRELESS SPECTRUM` | Reference | The wireless spectrum used in service provider network.
`YEAR TRANSFORMATION` | Reference | Transformations at the year level.