in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

GPRS and 3G Wireless application - Anderson C.

Anderson C. GPRS and 3G Wireless application - Wiley publishing , 2001. - 356 p.
ISBN: 0-471-41405 -0
Download (direct link): gprsand3gwirelessapplica2001.pdf
Previous << 1 .. 73 74 75 76 77 78 < 79 > 80 81 82 83 84 85 .. 125 >> Next

Examples of SCS include:
gsmSCF. This node gives access to GSM-specific features.
WAP gateway. The WAP gateway, and WAP in whole, is actually a subpart of another service capability: MExE. MExE also includes Java, and it is described in more detail in Chapter 11, ‘‘Operating Systems and Application Environments. ”
HLR-GW. This gateway, which we mentioned previously, is an OSA gateway that provides access to HLR information, such as user location and status. The HLR is the node in the mobile network that keeps track of subscriber information.
Vendors of service networks are also likely to include some SCSs that have not yet been standardized and some that are standardized but are not included in OSA. One example is the SIM Application Toolkit (SAT) server.
Now we can see that all of these components offer services from the mobile network. All other service enablers are called application support servers.
Application Support Servers
The second half of the service enablers consists of applications support servers. The services that application support servers offer come from other service network components and external components (such as billing gateways). As with service capability servers, the application support servers can be implemented as part of a node that provides the service or as a gateway that interfaces one or several servers. We show the access of the services through APIs in Figure 9.9.
In the figure, there are two ASuS GWs that offer several services per gateway. The directory access support, on the other hand, is implemented as part of the common directory itself. The common directory holds subscriber information,
Page 194
Application Server
Open ASUS interfaces
? V, (U
-C 0 0
(J to to
— o o
3 Q. ?>
O CL c
0 3 0
to to to
= U> 0^0 o o o a.
- CL C 0 3 0
Z CO to
S, o
I Cl O > cl 0 (a 3 ? Z CO
» a
— a) Q. S? O Q-
~ O 3
Q < CO
ASUS GW ? 1 1 n [ ASUS GW "I I Common 1 [ Directory
Standardized or proprietary interfaces L
Service Network and other nodes
Billing GW I E-mail I I" | Server J j PKI Infrastructure
Figure 9.9 Application support servers with ASuS APIs.
and we describe it in more detail in the next section, “Personal Service Environment Management.” Although these are two ways of implementing ASuS, the interfaces towards the applications remain the same. All of the ASuS support CORBA in order to facilitate platform and language independence.
The best way to understand ASUS is to work with it and to look at the different components and their interfaces. We give a few examples of ASuS here.
Page 195
Charging support service. Mobile operators have great experience with charging customers for air time and services, but the advent of packet networks and IP applications creates some difficulties. Because the mobile system operates mostly on lower layers, it is hard to charge on a per-application basis with the built -in billing functionality. Some applications developers and operators are likely to use this feature in the future, however, because then they can charge users per game, per click, or per transaction. This functionality is now supported in the service network via the charging support service. This service provides a convenient API where an application can signal when and how the user should be charged. This information is then compiled into Charging Data Records CDRs (described in Chapter 3) that the billing system of the Mobile System understands. The operator can then chose whether this billing information will arrive to the subscriber on the same bill as the other 3G services or on a separate bill. He or she can also use the charging API to collect usage statistics and events.
Notification support service. Many applications are initiated by a notification from the server side of the application. This notification can be an e-mail alert that invites the user to start the e-mail client or an instant-messaging client indicating that a buddy has gone online. The actual method of the notification depends on either the user’s preferences, as stored in the User Profile (part of the common directory) or explicitly stated by the application via the API. The choices of notification method range from SMS and WAP PUSH to network-initiated, circuit-switched calls.
Security support service. As more advanced applications emerge, it is crucial to have a powerful security toolkit at hand and APIs to support it. The security support service offers this feature and provides access to interfaces via the Public -Key Infrastructure (PKI) and other security enablers. Typical functionalities that are offered include certificate handling, authentication, and data encryption. We describe security issues and measures for applications in more detail in Chapter 12, “Security.”
Geo-navigational support service. We already saw that positioning is a key component of future service networks in the form of service capability servers. Location -based services can involve much more than getting the position of a user, however (for example, finding the shortest route between two locations and finding things that are of interest in the proximity of a known location). The geo -navigational support service offers all of these services (which we predict will be some of the more popular ones). Location-based services is a large topic, and we will explore it further in Chapter 13, “Location-Based Services.”
Previous << 1 .. 73 74 75 76 77 78 < 79 > 80 81 82 83 84 85 .. 125 >> Next