An output from TMF Catalyst project "Channels and Markets" by Vodafone, CSG, Microsoft & Nokia. This document describes the context around proposed extensions to TMF open APIs. The complete contribution to the TMF is here https://projects.tmforum.org/jira/browse/AP-4150

1. Channels & Markets – Contribution Context Paper
CSG, Nokia, Microsoft & Vodafone Group
Intro
The API focus of the “Channels & Markets” catalyst is on the TM Forum Open APIs for Address Match,
Service Qualification, Ordering, Catalog, Inventory and on improving convenience and utility of these
APIs so that all types of connectivity and non-connectivity services may be easily supported by all
participants in a marketplace. We are seeing these Open APIs as a core set for partnering but
acknowledge that there are other APIs which can be added for more complete partnering experience.
Domain specialization and domain context specification
For common APIs to work well across many technology domains it needs to be specialized to service the
requirements of each domain and for this specialization through configurable elements. For example,
requirements for wholesale fiber ordering where a fiber lead-in is required include both the
characteristic (attribute) specification and for the buyer to have visibility of the actual status of build
activity and the network operator (supplier) will need the owner of actions to be clear throughout the
process. This gets specific and differs not just from non-connectivity services but also for other
connectivity services such as already connected fixed connectivity services or mobile connectivity
service. For non-connectivity examples, data center services may need commitments on patching power
provision to be communicated as status/state in orders and many SaaS services need a simplified model.
Example: complex order state model, NZ UFB Fibre
The status of inventory can also vary based on service type. Active inactive but still available, in failover
state etc. may or may not be relevant depending on the type of service. Edge compute where through
ACKNOWLEDGED
IN PROGRESS
HELD
START
END
CONSENT GAINED
CONSENT REQUESTED
RFS CONFIRMED
CONSENT DECLINED
SCOPE TO BE SCHEDULED
NETWORK DESIGN/
QUOTE
INSTALL TO BE
SCHEDULED
SCOPING SCHEDULED
RFS CHANGE
SCOPING COMPLETED
UFF TO RESOLVE
RSP TO ADVISE
END USER TO ADVISE
COMPLETED
PROVISIONING
INSTALL COMPLETED
SERVICE GIVEN
CLOSED
CANCELLED
REJECTED
CEASE BILLING
BILLING
PENDING DISCONNECT
ACCEPTANCE
INTENT TO CANCEL
FULFILLED
COMPLETED
END

2. policy compute workloads are moved around geographically or networks which self-heal are likely to
need expose different state or sub-states in the inventory state model.
Domain context specifications is what we are calling additions, changes and configurable attributes
which are required for the APIs for partner integration to work for a specific product or service and our
point is that this domain context specification needs to be both convenient for all parties to use and
abstracted as configuration to allow CSP architectures and marketplaces to become more “dynamic”.
Diagram : APIs support process touchpoints and we need to abstract service specific specification to
support all services with the same set of APIs
If we can create a package of artifacts that completely specify the domain context and do this in a way
that suits the needs of both single purpose developers as well as catalog driven applications then we can
enable different products and services who wish to use the API's and participate in the marketplaces of
CSPs.
Parties and participants
Industry partnering APIs need to support the needs of all parties including single purpose developers as
well as catalog driven software applications or platforms.
There are many potential participants and we classify them in the following types;
TYPE 1 : Single Objective Developers
Single objective developers want quick wins
• Just the relevant attributes
• Fewer APIs & interactions
• All the attributes for their problem defined
TYPE 2 : Configurable software products and platforms
Software vendors & platforms want configurability
• Use a catalog to define and combine services
• Minimize or eliminate the need for users of their software to code.
TYPE 3 : Technology domain focused organizations
A standard and straightforward way of specifying the domain specific parts of an API payload is really
useful for technology domain suppliers and partners who work with CSPs. This allows them to

3. understand what the CSP already has covered and focus on the parts that then enable the CSP to take
their technology to market. If the specifications required for the technology domain can be provided by
the supplier or partner this makes it much easier for CSP's to utilize their technology. Examples of
technology domain suppliers or partners are as follows;
1. Standards Defining Organizations like MEF, Broadband Forum, GSMA.
2. A network equipment vendor with an SD WAN solution in the current market is likely to be
aligned but not be strictly conformant to any standard. if they can create and publish
product/service specifications and lifecycle specifications to use with their technology then this
will make it far simpler for CSPs to utilize their technology.
3. A unified communications vendor will typically have a soft switch at the core. The soft switch
will be highly configurable, some of this configuration allows the CSP to configure the product
they offer their customer, some with some commercial impacts to manage. Some of this
configuration allows the customer to control the product behavior.
4. Edge compute vendors mostly have different innovative approaches at present to typically
optimize workload distribution between core and edge compute and to simplify the way edge
compute is consumed. If an edge compute vendor can define product service specification in
CSP consumable programmatic form, then it will enable CSP “go-to market”.
When you consider all the SaaS services, cloud infrastructure services, IoT services, Managed IT services
and connectivity services that the modern CSP wishes to have in their portfolio then the above becomes
a very long list.
Interestingly some of the technology products that have been in the market for much longer have
normalized over time, often through pressure in wholesale markets for partners to standardize.
Standards defining organizations can define standards that the industry will accept and follow, allowing
these technology domains to then use specifications provided by the SDO rather than a vendor or the
CSP.
It is also worth noting that a technology domain supplier might not have TM Forum Open APIs
supported by their technology, but it is still very useful to the CSP to create domain context
specifications. Creating these specifications at a product level provides a CSP with a starting point to
take the technology to market and at the service level informs partner integration even if TMF Open
APIs are not used for the integration.
API functionality
Core API functions
Core API functionality is the set of features which the APIs can provide to any and all services. The
objective here is to have the same APIs work for any services.
Domain Context Specifications
We are proposing that this includes specifications of characteristics (attributes), structured
characteristic types and lifecycle state specifications adding the configurable elements to the core APIs
so that they can adequately support the domain.
Balancing the priorities of parties and participants

4. Providers of focused technology solutions such as a network equipment vendor often do not have a
diverse enough business to justify investment in a catalog to manage their service schemas. This can also
be particularly true for innovative OTT offerings which may be targeting a global vertical market and
working with CSPs for connectivity and go to market channel.
The way this project uses JSON schemas as an alternative to sharing product/service specification
through a catalog API gives these providers a simple way to offer their services to a catalog driven
marketplace without making an additional system investment.
This project shows products & services in a JSON schema format and also includes ingesting them into
the CSP catalog used by the BUYER so that the catalog visual modelling can then build relationships and
rules over the schema service building blocks to take combinations of in house and partner sourced
services to market. The outcome for the buyer as if the service provider supplier had a catalog and
exposed the TMF catalog APIs and the supplier avoids the need to implement a catalog.
A technology focused domain organization can assist the CSP community by creating product or service
specifications for their technology. They do not need any specific IT systems and can publish product
and service specifications from their website.
Made suitable for all the types of products and services a CSP is likely to take to market.
A global, vertically focused provider of non-connectivity services may pull together CSP partners each
with customer relationships and network coverage for their respective geography and integrate with all
of them though the one set of APIs
An SDO can publish a ready to use service specification on-line in a machine-readable programmatic
format without needing to make any specific IT system investment. CSPs can just directly use the
specification and if they do this conformance is more assured. This would really help SDOs achieve
standardization of their service specifications.
Enhancements from this project allow providers of different service types, including non-connectivity
services and connectivity services with specific approval or build stages to reflect their actual lifecycle
states to Buyers or a marketplace and use TMF APIs
Conclusion
We need the domain context specification to be programmatically defined so that every service-
managed-buy CSP platforms can be reflected through all channels and shared with partners. This project
has come up with a set of recommended enhancements and then shown through the prototype how
these enhancements will work. Further to this we are proving the extensions through multiple parties in
multiple channels by including multiple parties and multiple channels in the prototype activity.
Contributions
Included in our contribution document.
1. JSON Schema extension method to represent product and service characteristics -
2. JSON object specifying product or service lifecycle states.

5. 3. ORDER Specification recommendation are a requirement to support order date fields,
contractor, customer contact and in the context of this project are required to which
configurable lifecycles state to use with the order.
4. Sample API messages where the APIs have been modified to support 1&2
Reference material
Structured approach to specify dynamic payloads.
https://www.dgitsystems.com/wp-content/uploads/2021/04/Project-Findings-Paper-TMForum-
Catalyst-2014-B2B-Service-Bundling-1.0.pdf
https://www.tmforum.org/resources/technical-report/tr254-dynamic-api-technical-recommendation-
r15-5-1/