5 Location Based Services - Design of a Service Architecture
5.3 Design
5.3.1 Requirements Definition
The goal of the first phase in the design process is to develop a high level description of the system. The requirements for the system can be extracted from this description. The first step in this phase is to identify the business actors and use cases. The second step is to look at possible subdivisions of the business actors into separate actors and use cases.
5.3.1.1 Business modelling
A business actor is any individual, group, organisation, company or machine that interacts with the business. In the SP's view, the business is delivering the requested route
description and billing the user for it. Therefore, the business actors are the Network Operator (NO), the Content Providers (CPs) and the users. The user requests a route to the specified destination. The SP will request the user profile, location information and billing from the NO and it will also requests all information regarding the route description and additional information, from the CPs. The SP's will then send the result to the user.
All the requests and actions described are use cases.
Third Party Location Based Services December 2000
leS/EB 751
For the design of the service architecture, the NO's view needs to be considered. The NO has no relationship with the user during in the service. This means that the user is no business actor. Billing the user for the SP's service affects the user, but the NO merely handles the request from the SP to bill the user. Therefore, the SP will bill the user, although the money transfer is handled by the NO. In this view, the same holds for the CP's. The NO merely handles the requests from the SP. The latter is therefore the sole business actor. Figu re 41 shows the business use cases.
C2> C2>
User Profile Current Location
C-..J:--2> ~I/ ~
Subscribe to service
!i
SeNice Provider
C2>
Bill User
C2>
Authenticate
Figure 41 Business Use Cases for NO
For each business use case, the activities need to be defined. The activities have to be organised according to time to get a better understanding of the entire use case. It is important to indicate which business actors are involved in the interaction belonging to the activities. The activities can be grouped based on their characteristics. Some activities are mandatory, others are optional, some can be performed more than once and some can run simultaneously to other activities. Finally, the requirements for the use case have to be specified. The business use cases will be summarised using the table shown below.
Table 8 Business use case description
Authenticate - The SP needs to authenticate itself with the NO to communicate with the NO and to be able to use the NO's services. The SP sends its own 10 to the NO and, the NO will check this ID and it will send its ID back to the SP. The SP will request access to the NO's framework. The NO will select an authentication method. If the SP is a trusted party, authentication will be minimal. The NO performs the authentication of the SP; the SP needs to provide all information needed for the authentication process. The SP will also authenticate the NO. The NO will provide the SP with the relevant information. Once authentication has been successfully performed, the SP will be granted access to the framework. If not, the request will be aborted. Since there is only one business actor, the interactions are all between the SP and the NO. Selecting the authentication method and performing the authentication are not interactions. The activities named so far are mandatory, the NO has the opportunity to request additional information from the SP for the authentication process. The SP needs to be known with the NO, before any
communication can take place. The authentication process requires a common
authentication method. The NO will determine which method will be used, therefore the SP needs to support this method.
leS/EB 751
Table 9 Business use case: Authenticate
Third Party Location Based Services December 2000
Subscribe to service - If the SP wants to use services from the NO, it needs to subscribe to each service separately. The SP requests a services list from the NO. This list contains the NO's services with a brief description. The SP can request additional information for each service. The SP selects a service and sends the subscription request to the NO. The NO will send an agreement to the SP. The SP can request optional information for clarification of this agreement. The SP needs to (digitally) sign the agreement and send it back to the NO. The agreement will be stored and this concludes the subscription. Selecting the service and signing the agreement are not interactions, the other activities are. There are two opportunities to request additional information. The entire process requires a secure connection, especially when sending the signed agreement.
Table 10 Business use case: Subscribe to service
User Profile - The SP needs to check the user profile in order to see if the user allows localisation. The request for the user profile is followed by an authentication of the SP based on the SP's 10. The NO will check to see if the SP is subscribed to the service if the authentication is successfully completed. The request will be rejected if the
authentication fails. The user's profile will be looked up and the information will be interpreted. If the user allows localisation in general or specifically for that SP, the (positive) result will be sent to the SP. If the user does not allow localisation, the request will be rejected. In case the user want to be asked for permission, the NO will send a request to the user's mobile phone containing the name of the SP and its service and the response of the user will be forwarded to the SP. The authentication is performed by the NO and therefore this is not an interaction. Checking the user profile and requesting the user for authorisation are in fact internal interactions, but not between the NO and the SP.
An important requirement for this use case is that the SP has to be subscribed to the user profile service.
Table 11 Business use case: User Profile
Third Party Location Based Services December 2000
NO NO => SP
leS/EB 751
Current Location - The SP needs the user's current location as input for the service.
The request for the location is followed by an authentication of the SP based on the SP's I D. The NO will check to see if the SP is subscribed to the service if the authentication is successfully completed. The request will be rejected if the authentication fails. The NO must be sure the SP is authorised for localising the user. If not, the request will be
rejected. The SP will specify a QoS level in its request, the NO needs to see if this can be provided. If not, the SP will be notified what the available QoS level is. The SP can then decide to change the location request by sending an updated request or to abort the request. Whenever the QoS level can be provided, the NO will perform the localisation and send the result to the SP. There are numerous interactions in this use case, the table shows how the interactions are organised. Important requirement are that the SP is subscribed to the service and the user authorisation needs to be checked.
Table 12 Business use case: Current location
Bill user - The SP asks the NO to bill the user for the usage of the service. The request for billing the user, is followed by an authentication of the SP based on the SP's ID. The NO will check to see if the SP is subscribed to the service if the authentication is
successfully completed. The request will be rejected if the authentication fails. In case of a pre-paid user, the user's credit needs to be checked. If the user does not have sufficient credit, the billing request will be rejected. For post-paid users this check is not necessary.
The SP sends the Service Detail Record (SOR) to the NO. This record contains the pricing information (Le. price, transaction ID, service ID, user 10, SP's 10 and timestamp).
The NO will use the information from the SDR to process the request. As with the user profile and current location use cases, an important requirement is that the SP needs to be subscribed to the service. A secure connection for sending the SOR is also required, since the SDR contains private information.
Table 13 Business use case: Bill user
ICS/EB 751 Third Party Location Based Services December 2000
5.3.1.2 Subtype modelling - Framework class
The business use cases described so far, give a good impression about the high level interaction between the business actors. New (sub) use cases can be derived from the activities described for each business use case. These are the so-called uses and extend relationships as defined by UML. The 5 business use cases can be split into two classes: the framework class and the service feature class. The framework class consists of the 'authentication' and 'subscribe to service' use cases. The authentication process can follow a number of authentication methods. The use case itself contains the default authentication, for additional or more extensive authentication other authentication methods are used. These methods are separate use cases that extend the authentication use case. The following use case diagram shows the activities for the 'authentication' use case.
Service ~
Provider
<~
CL2>
Authenticate «extends»
~
C~
Authentication Method AC~
Authentication Method BFigure 42 Use case diagram 'Authenticate'
The 'subscribe to service' use case uses the services database to retrieve a list of services. This database will also contain the agreement and description for each service.
The subscriptions are stored in the subscriptions database. This database contains the subscriptions for the service providers. The write subscription database and the view service database use cases are used to address the (physical) databases. Both relationships are 'uses' relationships, as shown in the following figure.
SeNice ~
Provider
«u .. s~C ~
~ View
C ~
ServicesSubscribe to service
~
DatabaseC~
WriteSubsc riptions Database Figure 43 Use case diagram 'Subscribe to service'
The services database is maintained by the framework manager. The framework manager is an internal actor that is responsible for managing and controlling the framework. It will register new services and add them to the services database and update the subscriptions database with this new service. The service providers will be informed about the new service and the framework manager. The use case diagram is shown below. The two use cases will be worked out below using use case tables.
Third Party Location Based SeNices December 2000
leSIEB 751
?
C ~ «uses»~ C ~
1: ~
Registerservice~
SerVIces Wr!te<<uses> Database
F~:~;~~ C ~ C ~
Inform SPs Write
Subscriptions Database Figure 44 Use case diagram for the framework manager
Register service - New services can be registered with the framework. The framework (FW) manager creates a new entry in the services database (SvcD) using the services database use case. It will store the service description and service agreement in the database. Optionally additional information can be stored, e.g. a more detailed description of the service. The FW manager will create and entry in the subscriptions database (SubD). The FM needs to be the only party that can register new services, to maintain the integrity of the system. Other parties can view the database entries, but can not alter the content; therefore these parties use a different use case.
Table 14 Use case: Register Service
Inform SPs - The service providers subscribed with the NO will be notified of new services once the services are registered with the NO's system. The FM will retrieve a list of all SPs from the subscription database. A service description will be sent to all
subscribed SPs.
Table 15 Use case: Inform SPs
5.3.1.3 Subtype modelling - Service feature class
The service feature class consists of all service features supported by the system.
Service features are non-framework related services that provide network specific service. The business use cases of Figure 41 show three service features; user profile, current location and bill user. The use cases explained in the following paragraphs provide a more specified view on the business cases described so far.
Generally all service features perform common tasks (e.g. authentication, check subscription) and specific tasks (e.g. get profile, get location, etc.). The business use cases can therefore be further split up into a service manager and several common or specific use cases. Figure 45 shows the general use case diagram for the service managers.
ICS/EB 751 Third Party Location Based Services December 2000
c ~ «U,..»~ c. ~
/
- / View Authenticate S P Subscriptions
«uses» Database
?
C ~ ~C ~
\ L
Check subscri.> .
~
<<uses>>-SeNlce
Additional Use case
Manager, ~
<<uses»C ~ C~
Ser",;ce specific Use case
Use Network element Figure 45 General use case diagram for the service managers
The service managers manage and control the services. The two use cases that all service have in common, are used by all service managers from all service features. Both use cases use the subscriptions database use case as a reference. The use cases are described below.
Authenticate SP - The service manager (SM) authenticates the SP to establish its identity. The subscription database contains all relevant information about the SP that can be used to perform the authentication. The view subscription database use case is used to address the (physical) database. Requesting information about the SP is done during authentication.
Table 16 Use case: Authenticate SP
Authenticate SP Request information
8M
I
Mandatory/Parallel SM => SubD
I
Optional/Parallel
Check subscription - The service manager needs to see if the SP is allowed to use the service by checking for its subscription in the subscription database. The service
manager will use the 10 received earlier in the authentication process. If the check fails, the request will be rejected.
Table 17 Use case: Check subscription
The service specific use cases for the process described in this document are the 'check user profile', 'get current location' and 'bill user'.
Check user profile - The service manager for this use case will perform the task based on the parameters specified by the service provider. The network element (NE) or elements involved in this process is/are the element(s) where the information resides regarding user location settings. The service manager uses the 'use network element' use case to address this information. As described before, the 8M needs to contact the
Third Party Location Based Services December 2000
ICSIEB 751
user for authorisation if the settings require this. The use case ends with sending the result to the service provider. An important requirement is that the SM must be able to interact with the user. This can be fulfilled by a 'query user' use case. This use case will ask the user for permission to use its location.
Table 18 Use case: Check user profile
Get current location - The current location can be retrieved using a number of location methods. The methods vary in the OoS level that can be provided. The OoS levels differ in positioning accuracy and the delay. The default location method is included in the NE;
the other methods extend the functionality by providing a higher OoS level. The SM starts by determining whether the SP is authorised to localise the user. If not, the request will be rejected. The eventual OoS level is set by the SM by comparing the requested OoS level and the available level. If the requested level can not be provided, the maximum OoS level will be sent to the service provider. When the OoS level is agreed upon, the SM performs the localisation. The result will be sent to the SP. An important requirement is that the SP is authorised to localise the user.
Table 19 Use case: Get current location
Bill user - Billing the user starts with determining the if the user is a pre-paid or post-paid user. If he is a pre-paid user, the credibility for this user needs to be established. If the user does not have enough credit, the request will fail. The SM will process the service detail record (SDR) by sending the information to the network. An important requirement is that the credibility check is mandatory for pre-paid users.
Table 20 Use case: Bill user
The last use case concludes the requirement phase in the design process. The reader should be able to form a high level understanding of the system based in the description of the (business) use cases. The use case tables are provided to briefly summarise the actions belonging to each (business) use case. The use case diagrams illustrate the relationships between the use cases an actors.