Service Catalog

Service Catalog in tSM is the design-time definition of services that can be ordered, provisioned, and managed. It uses the generic Catalog capability and specializes it for service domains.

In practice:

• Catalog is the business boundary (catalogType = SERVICE).
• Category organizes services (for example CFS/RFS/VAS domains).
• Specification becomes Service Specification.
• Relationship becomes Service Relationship.

This keeps the model uniform across modules while allowing service-specific behavior.

1. Main Concepts in tSM

Concept	Meaning in Service Catalog	Typical Owner
Service Specification (Specification)	Definition template of a service (attributes, lifecycle, structure, and dependencies).	Product/service architect
Service Relationship (Relationship)	Structural rule between service specifications (dependency, exclusivity, substitution, migration, etc.).	Service architect
CFS (Customer-Facing Service)	Service visible to customer and business processes (for example Internet Service).	BSS + product teams
RFS (Resource-Facing Service)	Technical service used to realize CFS (for example Access Fiber, Transport).	OSS + network teams
Resource	Logical/physical asset used by RFS (for example CPE, port, IP block).	Resource/network teams

2. How Generic Catalog Models Service Catalog

2.1 Structure

1. Create one or more service catalogs (catalogType = SERVICE).
2. Create categories to separate CFS, RFS, and VAS concerns.
3. Assign Category.entitySpecificationSpecId per category to control service forms and characteristics.
4. Create service specifications in categories.
5. Connect service specifications with service relationships and cardinality/socket rules.

2.2 Behavior

• Category profile drives which attributes are allowed on Service Specification (chars) and how UI forms are rendered.
• Lifecycle and validity (lifecycleStatus, validityFrom, validityTo) control publishability and operational usage.
• Relationship semantics (cardinalityFrom, cardinalityTo, socket, addWithParent) control decomposition and option rules.
• Category-to-category relationships can be used for reusable bulk patterns instead of many one-by-one links.

2.3 Service Candidate Handling

For standard catalogs, Service Candidate can stay simple:

• 1:1 with Service Specification,
• auto-placed in the same catalog/category.

Create a separate candidate design only if publication/approval structure must differ from specification structure.

3. CFS, RFS, and Resource Mapping

The recommended modeling pattern is:

• CFS captures customer intent and commercial/service-facing attributes.
• RFS captures technology and delivery attributes.
• Resource captures concrete logical/physical assets used by RFS.

Two implementation styles are both valid:

• Keep Resources in a separate RESOURCE catalog and link from RFS to Resource Specification.
• Keep resource-like building blocks inside service modeling if project governance requires a single domain.

For larger operators, a dedicated RESOURCE catalog is typically more maintainable.

4. Consistent Example: Business Internet

4.1 Example Service Specifications

Code	Role	Category	Key Characteristics (examples)
Internet.Service	CFS	Core Services	bandwidth, SLA profile, technical contacts
Access.Fiber	RFS	Access Services	accessTechnology, supplier, handoverType
Transport.IP	RFS	Transport Services	QoS class, redundancy mode
VAS.PublicIP	VAS	Value-Added Services	IPv4/IPv6 option, allocation mode
VAS.Monitoring	VAS	Value-Added Services	proactive monitoring level, reporting profile

4.2 Example Service Relationships

From	To	Relationship Type	Cardinality	Modeling Purpose
Internet.Service	Access.Fiber	dependency	1..1	Primary access is mandatory
Internet.Service	Transport.IP	dependency	1..1	Transport layer is mandatory
Internet.Service	VAS.PublicIP	dependency	0..N	Optional add-on
Internet.Service	VAS.Monitoring	dependency	0..1	Optional monitoring
Internet.Service	Access.5G.Backup	dependency + socket=access	0..1	Alternative access technology

This pattern gives a reusable top-down design:

• business keeps a stable CFS definition,
• technology teams evolve RFS per access/transport technology,
• resource model stays reusable for multiple services.

5. Recommended Modeling Workflow in tSM

1. Define category structure first (CFS, RFS Access, RFS Transport, VAS).
2. Configure category profiles (entitySpecificationSpecId) before adding services.
3. Model stable CFS first, then decompose into reusable RFS.
4. Add optional/alternative services with cardinality + socket rules.
5. Keep resource links close to RFS, not directly to CFS.
6. Activate with lifecycle + validity only after decomposition is complete.

6. TM Forum Alignment (Short Mapping)

tSM modeling is implementation-first, but maps cleanly to TM Forum patterns:

tSM	TM Forum Pattern
Catalog (catalogType=SERVICE)	ServiceCatalog (TMF633)
Category	ServiceCategory (TMF633)
Service Specification (Specification)	ServiceSpecification (TMF633)
Service Relationship (Relationship)	serviceSpecRelationship / entitySpecRelationship (TMF633)
Resource link from RFS	resourceSpecification reference (TMF633 to TMF634)

Notes:

• TMF633 explicitly supports composite CFS/RFS specifications and service-specification relationships.
• For RFSS-style definitions, linking to resource specifications is expected.

7. Source Notes

This page is based on:

• project document: T-Mobile Service Catalog & Inventory Q/A (provided file),
• TMF633 Service Catalog Management API v5 specification (provided file),
• TM Forum API directory and Open API references:
  • TMF633 Service Catalog Management
  • TMF634 Resource Catalog Management
  • TM Forum Open API table
  • TMF633 Swagger (reference repository)