7.1.3 Service Discovery Sequence Diagrams

29.198-033GPPOpen Service Access (OSA) Application Programming Interface (API)Part 3: FrameworkTS Service Discovery

The following figure shows how Applications discover a new Service Capability Feature in the network. Even applications that have already used the OSA API of a certain network know that the operator may upgrade it any time; this is why they use the Service Discovery interfaces.

Before the discovery process can start, the Application needs a reference to the Framework’s Service Discovery interface; this is done via an invocation the method obtainInterface on the Framework’s Access interface.

Discovery can be a three-step process. The first two steps have to be performed initially, but can subsequently be skipped (if the service type and its properties are already known, the application can invoke discoverService() without having to re-invoke the list/discoverServiceType methods).

2: Discovery: first step – list service types.

In this first step the application asks the Framework what service types that are available from this network. Service types are standardized or non-standardised SCF names, and thus this first step allows the Application to know what SCFs are supported by the network.

The following output is the result of this first discovery step:

· out listTypes.

This is a list of service type names, i.e., a list of strings, each of them the name of a SCF or a SCF specialization (e.g. "P_MPCC").

3: Discovery: second step – describe service type.

In this second step the application requests what are the properties that describe a certain service type that it is interested in, among those listed in the first step.

The following input is necessary:

· in name.

This is a service type name: a string that contains the name of the SCF whose description the Application is interested in (e.g. "P_MPCC") .

And the output is:

· out serviceTypeDescription.

The description of the specified SCF type. The description provides information about:

· the property names associated with the SCF;

· the corresponding property value types;

· the corresponding property mode (mandatory or read only) associated with each SCF property;

· the names of the super types of this type; and

· whether the type is currently enabled or disabled.

4: Discovery: third step – discover service

In this third step the application requests for a service that matches its needs by tuning the service properties (i.e. assigning values for certain properties).

The Framework then checks whether there is a match, in which case it sends the Application the serviceID that is the identifier this network operator has assigned to the SCF version described in terms of those service properties. This is the moment where the serviceID identifier is shared with the application that is interested on the corresponding service.

This is done for either one service or more (the application specifies the maximum number of responses it wishes to accept).

Input parameters are:

· in serviceTypeName.

This is a string that contains the name of the SCF whose description the Application is interested in (e.g. "P_MPCC").

· in desiredPropertyList.

This is again a list like the one used for service registration, but where the value of the service properties have been fine tuned by the Application to (they will be logically interpreted as "minimum", "maximum", etc. by the Framework).

The following parameter is necessary as input:

· in max.

This parameter states the maximum number of SCFs that are to be returned in the "ServiceList" result.

And the output is:

· out serviceList.

This is a list of duplets: (serviceID, servicePropertyList). It provides a list of SCFs matching the requirements from the Application, and about each: the identifier that has been assigned to it in this network (serviceID), and once again the service property list.