Wireless Future - Telenor

Figure 6 SCSs and network
functional entities implemented
in the same physical entities.
From [2]
Figure 7 Hybrid
implementation. From [2]
96
SCS SCS
SCS
HLR CSE ----
OSA API
SCS SCS “Gateway”
HLR CSE ----
OSA API
Nonstandardised
Interfaces
Different SCSs may be implemented on one or
more physical entities, separate from the physical
network entities. Figure 5 shows one SCS
connecting different non-standardised network
interfaces. Different SCSs can also use one
‘Gateway’ for each physical network entity.
The OSA SCSs can also be implemented in the
physical network entity itself, as shown in Figure
6.
The possibility to have more than one SCS naturally
renders the option of a hybrid solution with
some SCSs implemented in the physical network
entity and some SCSs in separate physical entities.
This is shown in Figure 7.
Network operators wanting to offer OSA SCSs
will probably implement the last solution shown.
The reason for this is the need to use existing
non-standardised interfaces already in the network
and the need to maintain old services
deployed in the network. They can then make or
buy an SCS that can use the old interface or buy
an upgrade from the infrastructure provider if or
when upgrades are available. When expanding
the network with new components network operators
will in the future be able to buy components
including SCSs. Some infrastructure
providers will provide network entities containing
SCSs, others will provide the SCSs as separate
entities which open the market for third part
SCSs. Third part SCSs will also be available
against today’s non-standardised interfaces.
2.4 Use of Open APIs
The provisioning of OSA, Parlay and possibly
other open APIs will help network operators to
rapidly develop and deploy new services that
integrate functionality from several network
resources, and this alone will motivate the introduction
of OSA. Once the network operator implements
OSA or equivalent APIs, the use of the
SCSs can be sold to third party operators.
Before an external service provider is allowed to
access a network operator’s SCSs some sort of
agreement is needed. The standard is a Service
Level Agreement (SLA), normally a comprehensive
contract. The SLA gives a detailed description
of all aspects of the deal, such as the extent
of the contract, the responsibilities of the network
operator and the service provider and
actions to be taken if one of the parties does not
keep their part of the deal. Once the SLA is
signed the service provider can start using the
SCSs agreed on. Although the SLA is signed,
both on-line authentication with digital signatures
and on-line authorisation for use of the
SCSs is needed.
There are predictions of rapid growth in the
number of applications once the 3G mobile networks
are available. Network operators will not
be able to provide all these applications themselves.
The applications provided may fall into
four groups:
• Applications the network operators provide
themselves. The reasons for providing some
applications themselves range from being the
most cost-efficient, to applications being so
critical they have to provide them themselves.
• Applications the network operator needs to
offer in their network, but chooses to let an
external service provider run. These applications
range from compulsory services the network
operators are required to provide, to
applications that are complementary to their
own and able to generate extra traffic.
• Applications that a third party wants to run,
with no other benefit for the network operator
than the generated traffic.
• Applications that use SCSs from more than
one network operator.
The largest growth will probably be in contextbased
services, and then especially in services
using location information.
Telektronikk 1.2001