Nokia M2M Platform: Software Developer'S Guide

NOKIA M2M PLATFORM
SOFTWARE DEVELOPER’S GUIDE

Copyright © 2003 Nokia. All rights reserved. Issue 1.0 9311036
Contents
ACRONYMS AND TERMS ...................................................................................................... 1

DEFINITIONS........................................................................................................................... 3
1 ABOUT THIS DOCUMENT ................................................................................................ 4
2 THE NOKIA M2M SOLUTION DESCRIPTION .................................................................. 5
2.1 THE NOKIA M2M PLATFORM OVERVIEW ................................................................ 5
2.2 THE NOKIA M2M PLATFORM SYSTEM ARCHITECTURE ........................................ 5
2.3 LOCAL CONNECTIVITY IN THE NOKIA M2M PLATFORM........................................ 8
2.3.1 Local connectivity between the Nokia GSM Connectivity Terminal and a remote
device .................................................................................................................... 8
2.3.2 Local connectivity between the Nokia 12 GSM module and a remote device..... 10
2.4 COMMUNICATION LINKS IN THE NOKIA M2M PLATFORM................................... 11
2.4.1 The Nokia GSM Connectivity Terminal ............................................................... 11
2.4.2 The Nokia 12 GSM module ................................................................................. 12
2.5 WIRELESS CONNECTIVITY IN THE NOKIA M2M PLATFORM ............................... 12
2.5.1 The Nokia M2M Gateway Trial Version............................................................... 13
2.5.2 The Nokia M2M Gateway Corporate Edition....................................................... 13
2.5.3 The Nokia M2M Gateway Service Provider Edition ............................................ 14
2.5.4 Wireless connectivity components and connections ........................................... 16
2.5.5 Authentication and access control....................................................................... 20
3 DEVELOPING APPLICATIONS ON TOP OF THE NOKIA M2M PLATFORM................. 23
3.1 APPLICATION DEVELOPMENT IN THE PLATFORM .............................................. 24
3.1.1 Making applications to Application Modules........................................................ 24
3.1.1.1 Creating a communication infrastructure for an Application Module...............24
3.1.1.2 M2M System Protocols 1 and 2 ......................................................................25
3.1.2 Making JavaTM IMlets to the Nokia 12 module .................................................... 26
3.1.2.1 IMlets and IMlet Suites....................................................................................28
3.1.3 Making customer server applications .................................................................. 28
3.2 APPLICATION DEVELOPMENT SERVICES IN THE PLATFORM ........................... 29
3.2.1 The Nokia terminal/Nokia 12 module CORBA services ...................................... 29
3.2.2 The Nokia 12 module Java APIs ......................................................................... 30
3.2.3 The Nokia M2M Gateway and Gateway Access Software services.................... 32
4 COMMUNICATION IN THE NOKIA M2M PLATFORM .................................................... 34
4.1 BEARERS AND THEIR USAGE................................................................................. 34
4.1.1 Bearers in the Nokia M2M Platform .................................................................... 34
4.1.1.1 Short Message Service ...................................................................................34
4.1.1.2 General Packet Radio Service ........................................................................35
4.1.1.3 Enhanced General Packet Radio Service.......................................................35
4.1.1.4 Circuit Switched Data......................................................................................35
4.1.1.5 High Speed Circuit Switched Data ..................................................................36
4.1.2 Bearer selection .................................................................................................. 36
4.1.3 Maximum message sizes .................................................................................... 37
4.1.4 CORBA fragmentation......................................................................................... 38
4.2 COMMUNICATION IN THE APPLICATION DEVELOPMENT ENVIRONMENT ....... 39
4.2.1 Communication with the Nokia GSM Connectivity Terminal in the application
development environment ................................................................................... 40
4.2.2 Communication with the Nokia 12 GSM module in the application development
environment......................................................................................................... 41
4.2.2.1 Nokia 12 test board .........................................................................................43
4.2.3 Communication with the Nokia 12 IMP 1.0 Concept Simulator........................... 44
4.3 CORBA COMMUNICATION IN THE PRODUCTION ENVIRONMENT ..................... 45
4.3.1 Clients and servers in the Nokia M2M Platform .................................................. 47
4.3.2 Using CORBA observers in the Nokia M2M Platform ......................................... 47
4.4 CORBA ADDRESSING IN THE NOKIA M2M PLATFORM........................................ 48
4.4.1 Obtaining IORs with the customer remote application -originated CORBA
requests............................................................................................................... 49
4.4.1.1 Obtaining IORs using named references ........................................................50
4.4.1.2 Obtaining IORs using the standard CORBA Naming Service.........................51
4.4.1.3 Obtaining IORs using object reference transfer ..............................................53
4.4.1.4 Generating IORs using IMlets .........................................................................53
4.4.1.5 Encapsulated addressing mechanism ............................................................53
4.4.2 Publishing IORs from the customer remote application ...................................... 54
4.4.2.1 Publishing IORs dynamically...........................................................................55
4.4.2.2 Publishing IORs using the standard CORBA Naming Service........................56
4.4.3 Obtaining IORs with the customer server application -originated CORBA
requests............................................................................................................... 58
4.4.3.1 Obtaining IORs using the Nokia Active Naming Context ................................58
4.4.3.2 Obtaining IORs dynamically............................................................................60
4.4.3.3 Obtaining IORs using the standard CORBA Naming Service.........................60
4.4.4 Publishing IORs with the customer server application ........................................ 60
4.4.4.1 Publishing IORs using named references.......................................................60
4.4.4.2 Publishing IORs using the standard CORBA Naming Service........................61
5 DEPLOYMENT AND CONFIGURATION OF THE PLATFORM SERVICES ................... 62
5.1 DEPLOYING AND CONFIGURING THE PLATFORM SERVICES............................ 62
5.1.1 The Terminal Management Component.............................................................. 63
5.1.2 The Device Information Storage.......................................................................... 64
5.2 REMOTE APPLICATION MODULE UPDATE............................................................ 64
5.3 THE JAVA IMLET LOADING COMPONENT ............................................................. 66
Legal Notice
Copyright © 2003 Nokia. All rights reserved.
Reproduction, transfer, distribution or storage of part or all of the contents in this document in any form without the
prior written permission of Nokia is prohibited.
Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Java and all Java-based
marks are trademarks or registered trademarks of Sun Microsystems, Inc. Other product and company names
mentioned herein may be trademarks or trade names of their respective owners.
Nokia operates a policy of continuous development. Nokia reserves the right to make changes and improvements
to any of the products described in this document without prior notice.
Under no circumstances shall Nokia be responsible for any loss of data or income or any special, incidental,
consequential or indirect damages howsoever caused.
The contents of this document are provided "as is". Except as required by applicable law, no warranties of any
kind, either express or implied, including, but not limited to, the implied warranties of merchantability and fitness
for a particular purpose, are made in relation to the accuracy, reliability or contents of this document. Nokia
reserves the right to revise this document or withdraw it at any time without prior notice.
ACRONYMS AND TERMS
Acronym/term Description
AM Application Module
ANC Nokia Active Naming Context
ANSI American National Standards Institute
API Application Programming Interface
APN Access Point Name
CLDC Connected Limited Device Configuration
CORBA Common Object Request Broker Architecture
CSD Circuit Switched Data
DIS Device Information Storage
DNS Domain Name Server
EGPRS Enhanced General Packet Radio Service
ERP Enterprise Resource Planning
GGSN Gateway GPRS Service Node
GIOP General Inter-ORB Protocol
GPRS General Packet Radio Service
GPS Global Positioning System
HLA Home Location Agent
HSCSD High Speed Circuit Switched Data
HTTP Hypertext Transfer Protocol
IDL Interface Definition Language
ILC Java™ IMlet Loading Component
I/O Input/Output
IMP Information Module Profile
IOR Interoperable Object Reference
ISDN Integrated Services Digital Network
J2ME™ Java 2 Micro Edition
J2SE™ Java 2 Standard Edition
J2RE™ Java 2 Runtime Environment
JAR Java Archive
JSSE™ Java Secure Socket Extension
1/67
Acronym/term Description
LAN Local Area Network
M2M Machine-to-Machine
MIDP Mobile Information Device Profile
MIOR Mobile Information Module Profile
MSISDN Mobile Subscriber International ISDN Number
NAT Network Address Translator
NMEA National Marine Electronics Association
OMG Object Management Group
ORB Object Request Broker
PDP Packet Data Protocol
PIN Personal Identification Number
RADIUS Remote Authentication Dial-in User Service
SDK Software Development Kit
SIM Subscriber Identity Module
SMS Short Message Service
SMSC Short Message Service Centre
SP1 M2M System Protocol 1
SP2 M2M System Protocol 2
SSL Secure Sockets Layer
TCP Transmission Control Protocol
TMC Terminal Management Component
UI User Interface
UDP User Datagram Protocol
VPN Virtual Private Network
WDP Wireless Datagram Protocol
WMA Wireless Messaging API
WTP Wireless Transaction Protocol
2/67
DEFINITIONS
Term Definition
Application Module A runtime environment for the customer
remote application that is connected to the
Nokia GSM Connectivity Terminal or Nokia
12 GSM module via local connectivity.
Typically it is a part of the remote device
(such as a vending machine) or a separate
bridging element (such as the Nokia Smart
Adapter).
Customer remote application An application in the remote end of the
M2M solution. It can be executed in the
Application Module, Java™ 2 Runtime
Environment (J2RE™) of the Nokia 12
GSM module, or in both.
Customer server application Can vary from a standalone application to a
larger enterprise solution in the server end
of the M2M solution. The customer server
application is typically located in the
customer intranet.
Remote device A remote element (such as a vending
machine) that is a part of the M2M solution.
3/67
1 ABOUT THIS DOCUMENT
This document provides an overview of software development in the Nokia
M2M Platform (hereon Platform). The document describes the basic software
development principles from the software developer’s point of view. That is,
software developers working within the Platform can use this guide to get a
system level view of programming before starting the actual programming
tasks.
The guidelines in this document are applicable to software development tasks

done in the Platform irrespective of whether it is Application Module (AM), IMlet,
or customer server application related programming that one is doing. However,
this document does not give detailed programming instructions or examples.
For detailed programming instructions, refer to the following programming
guides:
• Nokia M2M Platform Remote Application Programming Guide

• Nokia M2M Platform Nokia 12 GSM Module IMlet Programming Guide
• Nokia M2M Platform Server Application Programming Guide
For more detailed information about Nokia M2M products and for extensive
application development documentation, see the Forum Nokia pages at
http://www.forum.nokia.com/m2m.
4/67
2 THE NOKIA M2M SOLUTION DESCRIPTION
2.1 THE NOKIA M2M PLATFORM OVERVIEW

The Platform is an end-to-end communication solution, on top of which
corporations, software developers, or service providers can build their M2M
solutions and services.
The Platform provides a scalable communication platform for different solutions

and services and a flexible distributed architecture with support for multiple
programming languages. With the ready-made Platform the application
developers can focus on the applications instead of dealing with the
complexities of the wireless network. This makes the application development
faster and easier.
The Platform also makes it possible to run multiple applications concurrently.

This means that the same Platform infrastructure can be used efficiently when
new application needs emerge.
2.2 THE NOKIA M2M PLATFORM SYSTEM ARCHITECTURE

“How do I build M2M connectivity between the remote system and our
intranet?” Figure 1 illustrates this fundamental dilemma that has to be solved
when planning M2M system architecture.
M2M connectivity
Remote system Intranet
Figure 1. Planning M2M system architecture

Nokia has solved the dilemma by developing an M2M system architecture that
provides both wireless connectivity between the customer’s remote system and
intranet, and local connectivity for managing the components of the remote
system.
Depending on the customer case and the surrounding network, the

communication link between the customer’s remote system and intranet is
provided either by the Nokia GSM Connectivity Terminal (hereon Nokia
terminal) or Nokia 12 GSM module (hereon Nokia 12 module). Figure 2
illustrates the role of the Nokia terminal and Nokia 12 module in the Platform
system architecture. For more information on the Nokia terminal and Nokia 12
module, see Chapters 2.3 and 2.4.
5/67
GSM
network
Nokia GSM
Connectivity
Terminal
Wireless Intranet
Remote connectivity
Local connectivity
device(s)
Nokia 12
GSM
module
Figure 2. The Nokia terminal and Nokia 12 module in the Platform system
architecture
The local connectivity set-up in the Platform system architecture varies
depending on whether the Nokia terminal or Nokia 12 module is used. As
illustrated in Figure 3, the key difference is related to the possibility to execute
customer remote applications. The Nokia terminal and Nokia 12 module also
provide a different variety of connection types for local connectivity. For more
information on the local connectivity solutions available via the Nokia terminal
and Nokia 12 module, see Chapter 2.3
If Common Object Request Broker Architecture (CORBA) communication is

used, the wireless connectivity set-up is similar irrespective of whether the
Nokia terminal or Nokia 12 module is used as a communication link. As
illustrated in Figure 3, wireless connectivity in the Platform system architecture
is typically built using the Nokia M2M Gateway (hereon Gateway) and Gateway
Access Software, which provide a reliable communication backbone towards
the customer server application. For more information on the wireless
connectivity solutions available in the Platform, see Chapter 2.5.
6/67
Remote
device Intranet
Nokia M2M
Nokia GSM Gateway
Connectivity Service Provider
Terminal Edition Gateway Customer
Access server
Software application
Local
connectivity GSM
Internet
network
Nokia 12
GSM module
Remote
Customer
device
remote
application
Figure 3. Local and wireless connectivity in the Platform system

architecture
In addition to CORBA communication, the Platform system architecture also
supports IP traffic via Transmission Control Protocol (TCP) and User Datagram
Protocol (UDP) sockets when the Nokia 12 module is used. Figure 4 illustrates
the use of IP traffic in Platform communication.
Customer
server
GGSN NAT/Firewall application
Public
Nokia 12 APN
Remote GSM module
device
GSM
network Internet 1
Local
Private
connectivity APN
2
GGSN Customer
Customer server
remote application
application
Figure 4. IP traffic in the Platform system architecture
7/67
Although the Platform system architecture supports the use of IP traffic, its use
is limited due to the security solutions that the operators use in their network
infrastructure.
As Figure 4 illustrates, two-way IP traffic between the Nokia 12 module and the
customer server application is not possible without tunnelling. The Nokia 12
module is able to communicate towards the customer server application by
using an internal IP address generated dynamically in the operator’s network.
However, the customer server application cannot use the internal IP address to
communicate towards the Nokia 12 module because the firewall/Network
Address Translator (NAT) settings (1) used in the operator’s network do not
recognize the private IP addressing space to which the Nokia 12 module IP
address belongs to.
Thus two-way IP traffic between the Nokia 12 module and the customer server
application is possible only if the network operator provides tunnelling towards
the customer server application (2). If the Nokia 12 module and the customer
server application share the same Local Area Network (LAN), static IP
addresses can be used to route the traffic between the Nokia 12 module and
the customer server application via a leased line.
If there is a public IP network between the Nokia 12 module and the customer
server application, tunnelling is needed to hide the structure of the transit
network and to route the IP traffic between the specified endpoints. When
tunnelling is used, the configuration of the private access point specifies the
tunnelling method.
The Platform provides tools to overcome the problems related to using IP traffic
in M2M connections. The following chapters provide more information on the
Nokia implementation of local (Chapter 2.3) and wireless connectivity (Chapter
2.5), and the usage of the Nokia terminal and Nokia 12 module (Chapter 2.4).
2.3 LOCAL CONNECTIVITY IN THE NOKIA M2M PLATFORM

This chapter provides an overview of the connection types that are available for
connecting the Nokia terminal/Nokia 12 module to the remote device.
Note: The Nokia terminal and Nokia 12 module do not have separate physical
interfaces for each connection type. The way that data is routed via the physical
interfaces depends on the connection type and the Platform components that are
used.
2.3.1 Local connectivity between the Nokia GSM Connectivity Terminal

and a remote device
8/67
Local connectivity between the Nokia terminal and a remote device can be built
using CORBA, AT command or I/O control connections. Figure 5 illustrates the
local connectivity options that are available via the Nokia terminal.
Nokia GSM
Remote Connectivity Wireless
device Terminal connectivity
CORBA
AT
AM
I/O
Figure 5. The local connectivity options available via the Nokia terminal
CORBA is used to enable communication with the customer server application
over the Platform. In order to use CORBA, a communication infrastructure has
to be built within the Application Module (AM). For more information, see
Chapter 3.1.1.1.
Note: The AM runtime environment can be a part of the remote device (as
illustrated in Figure 5) or it can be a separate bridging element.
When AT commands are used, the Nokia terminal functions as a modem

enabling, for example, fax functionalities. AT commands can also be used to
test software and Platform components in the application development phase.
For more information, see the Nokia 30 GSM Connectivity Terminal AT
Command Guide and Nokia 31 GSM Connectivity Terminal AT Command
Guide.
The Nokia terminal has analog/digital input pins and digital output pins that can
be used to control simple I/O applications. The I/O pins of the Nokia terminal
can be controlled remotely from the customer server application or from a
mobile handset using short messages. For more information, see the Nokia
GSM Connectivity Terminal Guide for User Control Mode.
The Nokia Smart Adapter

One example of an AM that is used as a separate bridging element is the Nokia
Smart Adapter. It is a programmable AM running inside a data adapter to which
the Nokia terminal is mounted. The use of the Nokia Smart Adapter is illustrated
in Figure 6.
9/67
RS-232
GSM
network
Remote device Customer server

Nokia Smart Adapter +
Nokia 30/31 terminal application
Figure 6. The Nokia Smart Adapter in an M2M system

The Nokia Smart Adapter includes template software that the customers can
use as a base when making applications. For more information, see the Nokia
Smart Adapter Application Development Guide.
2.3.2 Local connectivity between the Nokia 12 GSM module and a remote
device
Local connectivity between the Nokia 12 module and a remote device can be
built using the Socket interface, asynchronous serial connection, AT
commands, I/O control connection, or National Marine Electronics Association
(NMEA) connection. Figure 7 illustrates the local connectivity options that are
available via the Nokia 12 module and its JavaTM 2 Runtime Environment
(J2RETM).
Remote Nokia 12 GSM Wireless

device module connectivity
Socket (CORBA, TCP/UDP...)
Serial (asynchronous)
AT J2RE
AM
I/O
NMEA
GPS
Figure 7. The local connectivity options available via the Nokia 12 module
The socket interface is used to enable communication with the customer server
application over the Platform. If CORBA is used, a communication infrastructure
has to be built within the AM. For more information, see Chapter 3.1.1.1 and the
Nokia M2M Platform, M2M System Protocol 2 Integrator’s Manual.
The socket interface also makes it possible to use IP traffic (via TCP/UDP
sockets) between the remote device and the Nokia 12 module. For more
information on using TCP/UDP sockets in the Platform, see Chapter 2.2, the
10/67
Nokia M2M Platform M2M System Protocol 2 Integrator’s Manual, and Nokia
M2M Platform Nokia 12 GSM Module IMlet Programming Guide.
The asynchronous serial connection enables communication between the IMlet

and a remote device. For more information on how to use the asynchronous
serial connection, see the Nokia M2M Platform Nokia 12 GSM Module IMlet
Programming Guide.
As with the Nokia terminal, the modem functionality of the Nokia 12 module
enables the use of AT commands. The AT commands can be used, for
example, for faxing. AT commands can also be used to test software and
Platform components in the application development phase. For more
information, see the Nokia 12 GSM Module AT Command Guide.
When compared to the Nokia terminal, the Nokia 12 module has more
analog/digital input pins and digital output pins available that can be used to
control simple I/O applications. The I/O pins of the Nokia 12 module can be
controlled remotely from the customer server application, IMlet or from a mobile
handset using short messages. For more information, see the Nokia 12 GSM
Module User Control Mode Guide.
In addition it is possible to connect the Nokia 12 module to an external Global

Positioning System (GPS) device that supports the NMEA standard. The Nokia
12 module includes an NMEA parser that is able to parse the location data
(such as location coordinates, altitude, date and time) form the output that it
receives from the GPS device. The location data gathered in the Nokia 12
module can be distributed to a mobile handset using short messages, and
CORBA communication can be used to distribute the same data to an IMlet as
well as to the customer remote and server applications. For more information
on using GPS with the Nokia 12 module, see the Nokia GSM Connectivity
Terminal and Nokia 12 GSM Module Interface Definition Reference Guide and
Nokia M2M Platform Nokia 12 GSM Module IMlet Programming Guide.
2.4 COMMUNICATION LINKS IN THE NOKIA M2M PLATFORM
2.4.1 The Nokia GSM Connectivity Terminal

The Nokia terminal is a GSM terminal, which provides local connectivity
towards the customer remote applications and wireless connectivity towards the
customer server applications. The Nokia terminal, located outside the remote
device, has two variants; the Nokia 30 GSM Connectivity Terminal has been
designed for EGSM 900/1800 networks and the Nokia 31 GSM Connectivity
Terminal for GSM 800/1900 networks.
In addition to the functionalities described in Chapter 2.3.1, the Nokia terminal

supports reliability features like AutoPIN, GSM encryption and security codes,
reset mechanism, Platform authentication, and GSM phase 2+ supplementary
services.
11/67
For more information on the Nokia terminal, see:
• Nokia GSM Connectivity Terminal Product Guide

• Nokia 30 GSM Connectivity Terminal Technical Specification
• Nokia 31 GSM Connectivity Terminal Technical Specification
2.4.2 The Nokia 12 GSM module

Like the Nokia terminal, the Nokia 12 GSM module provides local connectivity
towards the customer remote applications and wireless connectivity towards the
customer server applications. The Nokia 12 module, located inside the remote
device, has two variants; the RX-2 supports EGSM 900/GSM1800 networks
and the RX-9 supports GSM 800/1900 networks.
In addition to the functionalities described in Chapter 2.3.2, the Nokia 12

module also supports reliability features like AutoPIN, GSM encryption and
security codes, reset mechanism, Platform authentication, and GSM phase 2+
supplementary services.
Note: When compared to the Nokia terminal, the key difference is the possibility
to make Java applications, IMlets, to the Nokia 12 module. For more information
on making IMlets to the Nokia 12 module, see Chapter 3.1.2.
For more information on the Nokia 12 module, see
• Product Specification for Nokia 12 GSM Module

• Integrator’s Manual for Nokia 12 GSM Module
2.5 WIRELESS CONNECTIVITY IN THE NOKIA M2M PLATFORM

The Platform system architecture components that are used to build wireless
connectivity towards the customer server application depend on the Gateway
edition that is used. There are three Gateway editions available:
• The Nokia M2M Gateway Trial Version (hereon Trial Version)

• The Nokia M2M Gateway Corporate Edition (hereon Corporate Edition)
• The Nokia M2M Gateway Service Provider Edition (hereon Service Provider
Edition)
For more information on the Platform system architecture components and
connections that are used to build wireless connectivity, see Chapter 2.5.4. For
more information on the authentication and access control methods in the
Platform, see Chapter 2.5.5.
12/67
2.5.1 The Nokia M2M Gateway Trial Version
The Trial Version is intended for trying out the Platform technology and for
testing software in the development phase. Figure 8 illustrates the test systems
available for testing Platform functions and the customer’s own software.
GSM network Intranet

Remote
devices
Nokia
SMS RS-232 M2M Gateway
Trial Version
CSD RS-232 Customer

server
application
RS-232
SMS
TCP/IP
Nokia 12 IMP 1.0

Concept Simulator
Nokia GSM
Nokia GSM Nokia 12
Connectivity Nokia 12
Connectivity Terminal GSM module
GSM module (with test board)
Terminal (with RS-232
data adapter)
Figure 8. The Nokia M2M Gateway Trial Version

When the Trial Version is used, the communication between the remote
devices and the customer server application is established via the Nokia
terminals/Nokia 12 modules that function as modems. For more information on
how the Trial Version is used for communication in the application development
environment, see Chapter 4.2.
2.5.2 The Nokia M2M Gateway Corporate Edition

The Corporate Edition is intended for companies who wish to manage the
Gateway along with customer server applications so that it can be used for
connecting to remote devices. Wireless connectivity services, Short Message
Service Centre (SMSC) and General Packet Radio Service (GPRS) access
points, may be rented from a network operator, or the company may operate its
own modem pool to provide access to remote devices. The Corporate Edition is
illustrated in Figure 9.
13/67
GSM network Intranet
Remote
devices
SM
S
SMSC
S
SM
Customer
server
application
GP
R S
GGSN
RS
GP S
PR
EG
Nokia M2M
Gateway
Corporate
CS
Edition
D
HS
CS
D* Modem
D pool
CS
D*
CS
HS
Nokia GSM
Terminal GSM module
* The Nokia 31 terminal and Nokia 12 module (RX-9) do not support HSCSD.
Figure 9. The Nokia M2M Gateway Corporate Edition
2.5.3 The Nokia M2M Gateway Service Provider Edition

With the Service Provider Edition, a company can provide gateway services to
other companies. That is, the company can act as a service provider.
The service provider maintains the Gateway and offers M2M services to its
customers. The service provider also delivers Gateway Access Software to its
customers and establishes a connection between the Gateway Access
Software and the Gateway. In addition, the service provider provides the
customer company with necessary configuration details for the Gateway
Access Software.
14/67
The Gateway Access Software serves as an access point for customer
companies in the network. Each company creates a so-called domain in the
M2M system. The term domain is a logical entity containing all the terminals
and server applications that belong to a certain company or a certain
application. Each customer company has control over its own domain(s). Figure
10 illustrates the Service Provider Edition.
GSM network Service provider network Internet

Remote
devices
A SM
S
SMSC
S
A SM
VPN/SSL
B GP
R S
GGSN
RS
GP S
PR
B EG
Nokia M2M
Gateway
Service Provider
Edition
CS
A HS
D
CS
D* Modem
pool
D
CS
D*
B CS
HS
Domain A Domain B
intranet intranet
Customer Gateway Gateway Customer

server Access Access server
application Software Software application
Nokia GSM Nokia 12

Connectivity GSM module
Terminal
15/67
Figure 10. The Nokia M2M Gateway Service Provider Edition
Note: In this document the Service Provider Edition is used as the default
Platform solution (in figures and examples).
2.5.4 Wireless connectivity components and connections

To establish wireless connectivity towards the customer server application, a
communication bridge is required between the GSM network and customer’s
intranet. The components that Nokia provides for building the wireless
connectivity bridge are the Nokia M2M Gateway and the Gateway Access
Software. Other components (network devices and servers) need to be
acquired by the customer.
All the key components and connections required for wireless connectivity are
illustrated in Figure 11. The numbering in the figure is used in the following
descriptions to help the reader to locate each component and connection in the
Platform system architecture.
16/67
GSM network Service provider network Internet
Remote
devices
A SM
S
SMSC
S
A SM
1 3 VPN/SSL
B GP 2
RS
GGSN
RS
GP S
PR
B EG
Nokia M2M
Gateway
Service Provider
Edition
CS
A HS D
CS
D* Modem
D
pool
CS
*
C SD
B HS
Domain A Domain B
intranet intranet
5 4
Customer Gateway Gateway Customer

server Access Access server
application Software Software application
Nokia GSM
Terminal GSM module
Figure 11. Wireless connectivity components and connections in the

Platform system architecture
Wireless bearers
Both the Nokia terminal and Nokia 12 module utilize wireless bearers (1) to
communicate with the server application via the GSM network. Due to the vast
variety of possible customer cases, there are several bearers available. The
17/67
bearers supported by the different Platform components are listed in Chapter
4.1.
In the Platform the selection of the bearer does not have to be hard coded in
the application. Instead, bearers can be configured flexibly for each case.
For more information on bearers and their usage, see Chapter 4.1.
Network devices
When establishing wireless connectivity, the bearer that is used determines the
use of the network device (2):
• If Short Message Service (SMS) is used, a Short Message Service Centre

(SMSC) connection is required. The connection needs a secure TCP/IP link
since the protocols used with SMSCs do not offer security features.
Connections can be safely divided to customer domains because each SMS
message is authenticated and access rights are checked. The protocol that
is used with an SMSC must support the sending of binary short messages.
For more information on the supported SMSCs, see the Nokia M2M
Gateway 3.0 Service Provider Edition Requirement List.
• If General Packet Radio Service (GPRS) or Enhanced General Packet
Radio Service (EGPRS) is used, a Gateway GPRS Support Node (GGSN)
connection is required. For more information on the GGSN configuration,
see the Nokia M2M Gateway 3.0 Service Provider Edition Requirement List.
• If Circuit Switched Data (CSD) or High Speed Circuit Switched Data
(HSCSD) is used, a modem pool is required. The modem pool must be a
Cisco device that supports the large-scale dial-out feature (for example,
Cisco 3600-series). The device needs at least one network interface that is
used for communication between the modem pool and the Gateway. It also
needs a module that has interfaces for dialling to terminals. The dialling
module can be, for example, a serial network module that has external
serial ports where modems are attached to, a network module that has
internal analogue modems, or a module that has internal digital modems
that are used over the ISDN link. For more information on the modem pool
requirements, see the Nokia M2M Gateway 3.0 Service Provider Edition
Requirement List
Note: The tasks related to the network devices are handled by the Gateway
administrators.
The Nokia M2M Gateway

The Gateway (3) serves as a bridge between the GSM network and the
Internet/customer intranet. It is responsible for protocol translation, connection
establishment as well as authentication and authorization of traffic. The
18/67
Gateway can be seen as a transparent communication channel that hides the
details of the GSM network and the Internet from the application developer. The
Gateway administrator typically establishes the connections to different GSM
network devices, such as SMSCs or GGSNs, together with some GSM
operator.
For more information on the Gateway, see the Nokia M2M Gateway 3.0
Corporate Edition Administration Manual and Nokia M2M Gateway 3.0 Service
Provider Edition Administration Manual.
The Gateway Access Software

The functionality of the Gateway depends on the Gateway edition/version that
is used. In the Service Provider Edition the Gateway provides the M2M services
that can be accessed via the Gateway Access Software (4).
Through the Gateway Access Software, the client company can operate their
own set of Nokia terminals and/or Nokia 12 modules. The Nokia terminals
and/or Nokia 12 modules in the remote end and the servers of the company
intranet form a so-called domain. Each domain belongs to a certain client, and
the client can control the access to its domain.
Communication through the Nokia M2M Platform is possible only inside the
client’s own domain. For example, CORBA requests are routed from the
Gateway to the right Gateway Access Software according to domain names. In
addition, the client can check the authentication details provided by the Nokia
terminal or Nokia 12 module before allowing access.
The Gateway Access Software tunnels traffic to the Gateway, easing firewall
traversal between domains. Security can be enhanced by encrypting traffic
between the Gateway Access Software and Gateway. Encryption can be done
using a Secure Sockets Layer (SSL) mechanism, which delivered as part of an
encryption-enabled version of the Gateway Access Software, or an external
Virtual Private Network (VPN) connection. The Gateway Access Software also
handles access control from Nokia terminals and Nokia 12 modules to the
company intranet, so that the company can freely manage the access rights.
Note: Utilising SSL is possible if the used Java Virtual Machine (JVM) supports
the Java Secure Socket Extension (JSSE™). The service provider also has to
provide the client with SSL credentials.
For more information on the Gateway Access Software, see the Nokia M2M
Gateway, Gateway Access Software 3.0 Administration Manual.
Customer server application

From the software developer’s point of view the key component in the customer
intranet is the application that the customer designs for controlling the customer
19/67
remote applications. Typically the customer server application is located in the
intranet, and it functions as a server (5) that controls the remote customer
applications, updates their configuration (for instance pricing data in vending
machines), and gathers data from the remote devices. However, as the roles of
the client and server can change dynamically in the Platform, the customer
server application can also act as a client requesting services from other
Platform components. The communication in the Platform is always routed via
the Gateway, but any of the components involved can initiate the
communication.
Connections to different enterprise systems, such as databases and Enterprise

Resource Planning (ERP) systems, can also be established via the customer
intranet application.
For more information on developing customer server applications, see the

Nokia M2M Platform Server Application Programming Guide.
2.5.5 Authentication and access control

Access control in the Platform is based on authenticating connections and
differentiating domains. The data required to create connections is found via the
Gateway Access Software.
RADIUS authentication
EGPRS/GPRS and CSD/HSCSD communication is authenticated with a
Remote Authentication Dial-in User Service (RADIUS). The terminal ID and
password of the Nokia terminal/Nokia 12 module are authenticated by the
Gateway against the user information in the Device Information Storage (DIS).
Figure 12 illustrates the RADIUS authentication process for EGPRS/GPRS
communication.
20/67
Nokia M2M Gateway Gateway
Service Provider Access
Edition Software
Nokia 12 GSM 3
module
RADIUS
server
1 6
2 7 4
5
GGSN Device
Information
Storage
Figure 12. RADIUS authentication for EGPRS/GPRS communication

In Figure 12 the Nokia 12 module opens a Packet Data Protocol (PDP) context
to the GGSN (1). The GGSN generates a RADIUS authentication request and
sends it to the RADIUS server in the Gateway via a tunnel (2).
The RADIUS server in the Gateway forwards the request to the Gateway
Access Software (3), which requests the authentication information from the
DIS (4). When the DIS returns the authentication information (5), the Gateway
Access Software authenticates the terminal ID and password of the Nokia 12
module against the user information in the DIS.
The Gateway Access Software sends the authentication result

(acceptance/rejection) to the Gateway’s RADIUS server (6), and the RADIUS
server sends a RADIUS authentication response to the GGSN according to the
authentication result (7). Finally the GGSN forwards the authentication
acceptance/rejection to the Nokia 12 module (8).
Note: The RADIUS authentication process for CSD/HSCSD is similar as the

process for EGPRS/GPRS. With CSD/HSCSD a modem pool is used instead of
GGSN and the traffic between the modem pool and the Gateway RADIUS server
is typically not tunnelled.
MSISDN authentication
21/67
With SMS communication authentication is based on Mobile Subscriber
International ISDN Number (MSISDN). The MSISDN of the Nokia
terminal/Nokia 12 module is authenticated by the Gateway against the user
information in the DIS. Figure 13 illustrates the MSISDN authentication process.
Nokia M2M Gateway Gateway

Service Provider Access
Edition Software
Nokia GSM
Connectivity
Terminal/
Nokia 12 3
GSM module
SMSCP
6
1
2 4
5
SMSC Device
Information
Storage
Figure 13. MSISDN authentication for SMS communication

In Figure 13 the Nokia terminal/Nokia 12 module sends a short message to the
SMS connection point (SMSCP) of the Gateway via an SMSC (1) (2). The
SMSCP of the Gateway queries from the Gateway Access Software of the
corresponding domain whether the phone number of the Nokia terminal/Nokia
12 module in is allowed to access the domain (3). The Gateway Access
Software then queries whether the phone number exists in the DIS (4) (5).
If the phone number of the Nokia terminal/Nokia 12 module exists in the DIS,
the Gateway Access Software informs the SMSCP of the Gateway that the
Nokia terminal/Nokia 12 module in question is allowed to access the domain. If
the phone number does not exist in the DIS, the Gateway Access Software
informs the SMSCP of the Gateway that Nokia terminal/Nokia 12 module in
question is not allowed to access the domain (6).
Note: When the RADIUS or MSISDN authentication is used, the actual

authentication information (terminal ID, password or phone number) is never sent
over the GSM network.
22/67
3 DEVELOPING APPLICATIONS ON TOP OF THE NOKIA
M2M PLATFORM
Software developers can develop the following applications on top of the
Platform:
• Customer remote applications to an Application Module

• Customer remote applications (IMlets) to the Nokia 12 module
• Customer server applications
This chapter describes the basic requirements and options for developing the
Platform applications listed above. It also introduces the services that can be
used for developing the Platform applications. Figure 14 illustrates the elements
to which Platform applications can be made, and the elements via which
application development services/APIs can be used.
Nokia GSM
Connectivity GSM
Terminal network
Nokia M2M
Terminal Gateway Gateway
Application services Service Provider Access
Module Edition Software Server
Gateway
Java
services
APIs
Customer Customer
remote server
application application
Module
services
Java
APIs
IMlet
Nokia 12
GSM module
Figure 14. Applications and application development services in the

Platform
23/67
3.1 APPLICATION DEVELOPMENT IN THE PLATFORM
3.1.1 Making applications to Application Modules

The basic requirement for making an application to an AM is a suitable software
development environment (typically located on a PC). The type of the
application that is being made determines the specific PC tools that are
needed.
The latest version of the Nokia M2M Software Development Kit (SDK) is also
needed. It includes the required Platform software libraries (for M2M System
Protocols and CORBA), as well as additional documentation and example
applications. The Nokia M2M SDK can be downloaded from
Note: The Nokia M2M SDK includes a ready-made example application for
Windows (Win32) that can be used, for example, to test communication towards
the Nokia terminal/Nokia 12 module.
A software developer also needs access to application development services.

When applications are made to an Application Module using CORBA, a
software developer can utilize the Nokia-specific CORBA services form the
Nokia terminal/Nokia 12 module, or the CORBA services of the customer server
application. For more information on the Nokia–specific CORBA-services
available for making applications to an Application Module, see Chapter 3.2.1.
Note: The Platform system architecture also provides a possibility to use

TCP/UDP sockets for accessing other possible IP-based services that may have
been implemented either in the customer server application or in the Nokia 12
module. However, the possibility of using TCP/UDP sockets over the Platform
depends on the operator’s network infrastructure. For more information, see
Chapter 2.2.
3.1.1.1 Creating a communication infrastructure for an Application Module

Before applications can be made to an AM, a communication infrastructure has
to be built within the AM. Once the infrastructure is ready, the AM can be
integrated with the Nokia terminal or Nokia 12 module.
When the AM is integrated with the Nokia terminal, the communication within
the Application Module requires an Object Request Broker (ORB). A Nokia-
specific ORB is available for this purpose, but it is also possible to use a
custom-made ORB as long as it is Nokia M2M Platform compatible. The M2M
System Protocol 1 (SP1) provides the integration interface between the AM and
the Nokia terminal as illustrated in Figure 15.
24/67
Nokia GSM
Application Module
Connectivity
Terminal
Customer Serial
remote ORB SP1
application connection
Figure 15. Using the M2M System Protocol 1 to build Application Module
communication infrastructure
When the Nokia 12 module is used, the communication within the Application
Module is conveyed either via an ORB (Nokia ORB/custom-made ORB) or
directly between the customer remote application and the M2M System
Protocol 2 Socket API. Although the Nokia 12 module supports the M2M
System Protocol 1 as well, the integration interface between the AM and the
Nokia 12 module is typically built by using M2M System Protocol 2. Figure 16
illustrates the options that can be used to build a communication infrastructure
within the Application Module when the M2M System Protocol 2 is used.
Application Module Nokia 12

GSM module
S
Customer O
ORB C Serial
remote SP2
application K connection
E
T
Figure 16. Using the M2M System Protocol 2 to build Application Module
communication infrastructure
For more information on how to use the M2M System Protocol 2 to integrate the
AM with the Nokia 12 module, see the Nokia M2M Platform, M2M System
Protocol 2 Integrator’s Manual.
3.1.1.2 M2M System Protocols 1 and 2

The M2M System Protocol 1 can only be used for CORBA communication. It
makes it possible to send CORBA messages between the AM and the Nokia
terminal/Nokia 12 module.
25/67
Note: The M2M System Protocol 1 is used with Nokia 12 module only when there
is a need to replace the Nokia terminal with the Nokia 12 module without changing
the M2M System Protocol 1 integration interface.
For more information on the M2M System Protocol 1, see the Nokia M2M
System Protocol 1.0 Specification.
The M2M System Protocol 2 enables IP traffic between the AM and the Nokia
12 module. From the IP addressing point of view M2M System Protocol 2
functions as a tunnel that combines the AM and the Nokia 12 module. Because
the AM and the Nokia 12 module share the same IP address and TCP/UDP
stack (located in the Nokia 12 module), all other Platform components view
them as one entity. The actual communication between the AM and the Nokia
12 module is handled using local sockets.
For more information on the M2M System Protocol 2, see the Nokia M2M
Platform M2M System Protocol 2.0 Specification.
3.1.2 Making JavaTM IMlets to the Nokia 12 module

The basic requirement for making Java IMlets to the Nokia 12 module is a
suitable Java development environment on a PC. In addition a software
developer needs either the Nokia 12 IMP1.0 Concept Simulator or a Nokia 12
module that is attached to the Nokia 12 test board.
Nokia 12 IMP 1.0 Concept Simulator is a tool that simulates the real product
functions. It can be used to develop and test IMlets in a simulated environment
without the actual Platform hardware. For more information on how to use the
Nokia 12 IMP 1.0 Concept Simulator, see Chapter 4.2.3, the Nokia M2M
Platform Nokia 12 IMP 1.0 Concept Simulator Installation Guide, Nokia M2M
Platform Nokia 12 IMP 1.0 Concept Simulator User Guide and Nokia M2M
Platform Nokia 12 GSM Module IMlet Programming Guide. The Nokia 12 IMP
1.0 Concept Simulator can be downloaded from
It is also possible to develop and test IMlets by using an actual Nokia 12

module that is attached to the Nokia 12 test board. The Nokia 12 test board is
26/67
COM3 COM2 COM1
Nokia 12 test board
Nokia 12 GSM module

Power connector
Antenna adapter cable
Figure 17. Nokia 12 module attached to the Nokia 12 test board

When the Nokia 12 test board is used, IMlets are loaded to the Nokia 12
module via the COM2 port by using the Configurator software for the Nokia 12
module. The Configurator software for the Nokia 12 module can be downloaded
from http://www.forum.nokia.com/m2m . For more information on using the
Nokia 12 test board, see Chapter 4.2.2.1 and the Nokia M2M Platform Nokia 12
GSM Module IMlet Programming Guide.
Note: It is also possible to load IMlets to the Nokia 12 module over-the-air by

using the Java IMlet Loading Component (ILC) via the Gateway. For more
information on using the Java ILC, see Chapter 5.3 and the Nokia M2M Platform
JavaTM IMlet Loading Component User Guide.
Making IMlets also requires that a software developer has access to application
development services. The Nokia 12 module includes several Java APIs that
can be used for making IMlets. For more information on the Java APIs
available, see Chapter 3.2.2.
When IMlets are made to the Nokia 12 module using CORBA, a software
developer can utilize the Nokia-specific CORBA services form the Nokia 12
module, or the CORBA services of the customer remote and customer server
27/67
applications. For more information on the Nokia–specific CORBA-services
available for making IMlets, see Chapter 3.2.1.
3.1.2.1 IMlets and IMlet Suites

IMlet is a Java 2 Micro Edition (J2ME™) application that runs on the
Information Module Profile (IMP) environment. IMP is a subset of the Mobile
Information Device Profile (MIDP) commonly used in mobile phones.
IMlets are packed in IMlet Suites. An IMlet Suite is a package – typically a Java
Archive (JAR) file – that contains one or more IMlet applications and a manifest
file that contains information about the IMlet Suite. For more information on
IMlets and IMlet Suites, refer to the Nokia M2M Platform Nokia 12 GSM Module
IMlet Programming Guide and Nokia M2M Platform JavaTM IMlet Loading
Component User Guide.
3.1.3 Making customer server applications

The basic requirement for making customer server applications is a connection
to a Gateway (Trial Version, Corporate Edition or Service Provider Edition). It is
also beneficial (though not mandatory) to have the Nokia M2M SDK, as it
includes application examples and Platform software libraries that can be
utilized. The Nokia M2M SDK can be downloaded from
Note: When applications are developed for testing purposes it is recommended

to use Java since the application examples in the Nokia M2M SDK have been
coded with Java. The recommended Java environment is the Java 2 SDK version
1.4.2 that can be downloaded form Sun’s website.
The Nokia 12 IMP 1.0 Concept Simulator and the Trial Version are needed
when IMlets are tested form the customer server application. For more
information, see Chapter 4.2.3, the Nokia M2M Platform Nokia 12 IMP 1.0
Concept Simulator Installation Guide, Nokia M2M Platform Nokia 12 IMP 1.0
Concept Simulator User Guide, and Nokia M2M Platform Software
Development Kit and Nokia M2M Gateway Trial Version Installation Guide.
Making customer server applications also requires that a software developer

has access to application development services. When customer server
applications are made using CORBA, it is possible to utilize the Nokia–specific
CORBA services from the Nokia terminal/Nokia 12 module and the Gateway. It
is also possible to utilise the CORBA services of the customer remote
application. For more information on the CORBA services available via the
Nokia terminal/Nokia module, see Chapter 3.2.1. For more information on the
CORBA services available via the Gateway, see Chapter 3.2.3.
28/67
In addition to the CORBA services, the Gateway provides three Java APIs: the
Java IMlet Loading Component (ILC), Terminal Management Component
(TMC) and Remote AM Update. For more information on the Java APIs
available for developing customer server applications, see Chapter 3.2.3.
Note: The Platform system architecture also provides a possibility to use

TCP/UDP sockets for accessing other possible IP-based services that may have
been implemented either in the customer remote application or in the Nokia 12
module. However, the possibility of using TCP/UDP sockets over the Platform
depends on the operator’s network infrastructure. For more information, see
Chapter 2.2.
For more information on developing customer server applications, see the

Nokia M2M Platform Server Application Programming Guide.
3.2 APPLICATION DEVELOPMENT SERVICES IN THE PLATFORM
3.2.1 The Nokia terminal/Nokia 12 module CORBA services

The CORBA services described in this chapter are available for all Platform
applications regardless of their location (AM, IMlet, customer server
application). The Nokia terminal services can be accessed via the terminal
ORB, and in the Nokia 12 module services can be accessed via the module
ORB.
Note: It is not possible to make applications to the Nokia terminal. The Nokia-
specific CORBA services that can be accessed via the terminal ORB are there to
be used by other Platform applications. However, it is possible to make additional
CORBA services to the Nokia 12 module.
Wireless Device
This service is used for retrieving basic device information and for obtaining,
setting, and observing device properties. Both the Nokia terminal and the Nokia
12 module offer this service. For more information, see the Nokia GSM
Connectivity Terminal and Nokia 12 GSM Module Interface Definition
Reference Guide.
Properties
This service is used for defining the parameters and events that are used
through the Wireless Device interface. Both the Nokia terminal and the Nokia
12 module offer this service. For more information, see the Nokia GSM
Connectivity Terminal and Nokia 12 GSM Module Properties Reference Guide.
29/67
Embedded Terminal
This service is used for controlling the basic GSM functionalities (such as PIN
codes, SMS messages, Phonebook, and GSM connections). Both the Nokia
terminal and the Nokia 12 module offer this service. For more information, see
the Nokia GSM Connectivity Terminal and Nokia 12 GSM Module Interface
Definition Reference Guide.
I/O
This service is used for controlling and observing the I/O pins of a specified
device. Both the Nokia terminal and the Nokia 12 module offer this service. For
more information, see the Nokia GSM Connectivity Terminal and Nokia 12
GSM Module Interface Definition Reference Guide.
GPS
This service is used for reading the Global Positioning System (GPS) -specific
parameters from a GPS module that is physically attached to the Nokia 12
module. The service is available only via the Nokia 12 module. For more
information, see the Nokia GSM Connectivity Terminal and Nokia 12 GSM
Module Interface Definition Reference Guide.
IMlet Suite Manager

This service is used for controlling the life cycle of the IMlet suites inside the
Nokia 12 GSM module. The service can be used, for example, to load IMlets to
the Nokia 12 module, to start and stop them, or to remove them from the Nokia
12 module. For more information, see the Nokia GSM Connectivity Terminal
and Nokia 12 GSM Module Interface Definition Reference Guide and Nokia
M2M Platform Java™ IMlet Loading Component User Guide.
Remote AM Update
This service is used for updating the AM software over-the-air. The service is
available only via the Nokia 12 module. For more information, see the Nokia
GSM Connectivity Terminal and Nokia 12 GSM module Interface Definition
Reference Guide and Nokia M2M Platform Remote Application Module Update
User Guide. .
3.2.2 The Nokia 12 module Java APIs

The Nokia 12 module complies with the Information Module Profile (IMP) 1.0. In
addition to IMP 1.0 APIs, the Nokia 12 module includes the Java APIs listed
below.
Note: The Java APIs of the Nokia 12 module are available only for making IMlets.
30/67
Socket API
The javax.microedition.io.Connector class provides the connection to this Java
API. The Socket API is used for creating client and server TCP sockets and for
reading/writing data from/to them. The Socket API also supports Datagram
(UDP) sockets. For more information, see the Nokia M2M Platform Nokia 12
GSM Module IMlet Programming Guide.
Serial API
The javax.microedition.io.Connector class provides the connection to this Java
API. The Socket API is used for reading data from and writing data to the serial
port of the Nokia 12 module. For more information, see the Nokia M2M Platform
Nokia 12 GSM Module IMlet Programming Guide.
Watchdog API
This API makes it possible to set a reset timer from the IMlet. If the Watchdog
timer is set during the IMlet execution, it should be reset before the timer
reaches the limit, or otherwise the timer will reset the Nokia 12 module in
question. For more information, see the Nokia M2M Platform Nokia 12 GSM
Module IMlet Programming Guide.
I/O API
This Java API is used for retrieving and setting the I/O pin values of the Nokia
12 module. For more information, see the Nokia M2M Platform Nokia 12 GSM
Module IMlet Programming Guide.
Wireless Messaging API

The WMA provides a common API for sending and receiving text and binary
messages - typically of store-and-forward types, such as Short Messaging
Service (SMS) messages. For more information, see the Nokia M2M Platform
Nokia 12 GSM Module IMlet Programming Guide.
ORB API
This API provides the mapping of the OMG CORBA APIs to the Java
programming language, including the class ORB, which is implemented so that
a programmer can use it as a fully functional Object Request Broker (ORB).
Through this API an IMlet can access the Nokia-specific CORBA services via
the module ORB as well as the CORBA services implemented in the AM and
the customer server application.
Also, by using this API IMlets can offer their own services to customer remote
applications located in the AM and customer server applications. For more
information, see the Nokia M2M Platform Nokia 12 GSM Module IMlet
Programming Guide.
31/67
3.2.3 The Nokia M2M Gateway and Gateway Access Software services
It is not possible for the customer to make applications to the Gateway.
However, the following services that the Gateway and Gateway Access
Software provide can be used to make customer server applications.
The Terminal Management Component (TMC)

Java applications can use the TMC API to configure Nokia terminals and Nokia
12 modules to communicate with a specified Gateway. The TMC API can be
used, for example, to define the bearer that the Nokia terminal or Nokia 12
module uses. For more information, see the Nokia M2M Platform Terminal
Management Component User Guide.
The Java IMlet Loading Component (ILC)

Java applications can use the ILC API to download Java IMlet Suites to Nokia
12 modules. The ILC API uses the IMlet Suite Manager CORBA interface
internally to download IMlets that are packed into IMlet Suites. The download
process can be done over-the-air via the Gateway by using the ILC Reference
User Interface (UI). For more information, see the Nokia M2M Platform Java™
IMlet Loading Component User Guide.
Remote AM Update
The Remote AM Update Java API enables over-the-air update of AM firmware
via the GSM network. The Remote AM Update component has a Reference UI
that uses the Remote AM Update API. In addition to AM firmware update,
typical functions in which the Remote AM Update service can be used are
pricing data updates and configuration data changes. For more information, see
the Nokia M2M Platform Remote Application Module Update User Guide.
Smart Messaging
The Smart Messaging CORBA service can be used to configure Nokia
terminals and Nokia 12 modules to communicate with a specified Gateway. The
Gateway provides the Smart Messaging interface that offers methods to send
Smart Messaging data to a Nokia terminal or Nokia 12 module. The Smart
Messaging configuration can be done over-the-air by using a Reference UI.
Note: When Smart Messaging is used to configure Nokia terminals and/or Nokia
12 modules, the target terminals and/or modules must not have any connection
bearers configured and they must be switched on.
For more information, see the Nokia M2M Platform Smart Messaging
Programming Guide.
32/67
Text Messaging
The customer server application can send textual short messages via the text
messaging interface of the Gateway Access Software or Corporate Edition. The
Text Messaging functionality also makes it possible to send textual short
messages from a mobile handset to the customer server application via the
Gateway.
Note: The use of the Text Messaging service requires that the Gateway is
connected to a SMSC.
When the Text Messaging service is used, the Gateway processes all SMSC
communication. The customer server application needs only to send or receive
textual short messages through the Messager interface.
For more information, see the Nokia M2M Platform Text Messaging
Programming Guide.
The Device Information Storage (DIS)

The Gateway uses the DIS for handling information related to Nokia terminals
and Nokia 12 GSM modules. By using the User Information CORBA interface of
the DIS, the Gateway authenticates connections between the Gateway and
Nokia terminals/Nokia 12 modules. By using the Bearer Information CORBA
interface of the DIS, the Gateway handles bearer information (such as used
bearers, ports, and timeouts) related to the Nokia terminal or Nokia 12 module
connection. For more information on the DIS, see the Nokia M2M Platform
Device Information Storage Programming Guide.
Note: When the Service Provider Edition of the Gateway is used, the interfaces of
the DIS are used by the Gateway Access Software.
33/67
4 COMMUNICATION IN THE NOKIA M2M PLATFORM
4.1 BEARERS AND THEIR USAGE

The use of the bearers in the Nokia M2M solution depends on the available
network (which bearers are implemented in the GSM operator’s network),
Gateway edition and version, and the terminal/module that is used.
The bearers supported by the different Platform components are listed in Table
1.
Table 1. Bearers supported by the Platform components

Platform component SMS GPRS EGPRS CSD HSCSD
*
Nokia M2M Gateway 3.0 X X X X X
Nokia 30 terminal X X X X
Nokia 31 terminal X X X
Nokia 12 module (RX-2) X X X X X
Nokia 12 module (RX-9) X X X X
*
The bearers supported by the different Gateway editions are described in Chapter 2.5
The choice of the wireless bearer is an important factor in terms of the

communication costs. To enable the customer to react to changing tariffs, the
Platform enables flexible bearer configuration. The options available for bearer
configuration are described in Chapter 4.1.2.
The Platform uses all the GSM bearers listed above either on top of the
Wireless Application Protocol (WAP1) or TCP/IP.
4.1.1 Bearers in the Nokia M2M Platform
4.1.1.1 Short Message Service

SMS is suitable for passing messages with small amount of store-and-forward -
type of data. SMS communication is implemented using the WAP/WDP
protocols. To be able to use SMS, the Gateway needs a dedicated connection
to an SMSC.
1
Wireless Transaction Protocol (WTP) and Wireless Datagram Protocol (WDP) are used in the Nokia
M2M environment.
34/67
4.1.1.2 General Packet Radio Service
With GPRS data is transferred over the network in small, standardized packets.
Transferring data as packets makes the transfer more efficient. With GPRS a
mobile can send and receive data packets using several time slots at the same
time, and time slot usage is presented as the number of downlink and uplink
slots used.
To utilize GPRS, the Gateway needs a connection to a GSM operator’s GGSN,

where a dedicated Access Point has to be configured. In addition, the SIM card
in the Nokia terminal must be permitted to use GPRS and the dedicated Access
Point.
When the Nokia terminal is used, GPRS communication utilises WAP-

protocols. With the Nokia 12 module the default protocol for GPRS
communication is TCP/IP. However, it is possible to use WAP with the Nokia 12
module when the Nokia terminal is replaced with the Nokia 12 module.
Note: Replacing the Nokia terminal with the Nokia 12 module requires a hardware
update as well. Nokia does not provide the hardware update.
4.1.1.3 Enhanced General Packet Radio Service

EGPRS is a subset of the Enhanced Data Rates for GSM Evolution that
provides an upgrade to GPRS (data) and GSM (voice) networks, making
current networks capable of offering 3G services already within existing
frequencies. When compared to GPRS, EGPRS offers increased data
transmission rates (throughput).
For M2M applications EGPRS provides a platform for more efficient data
delivery and more robust services at higher data speeds. To utilize EGPRS, the
Gateway needs a connection to a GSM operator’s GGSN, where a dedicated
Access Point needs to be configured. In addition, the SIM card in the Nokia 12
module must be permitted to use EGPRS and the dedicated Access Point.
4.1.1.4 Circuit Switched Data

CSD is used as a bearer when large amounts of data need to be transferred.
To be able to utilize CSD, the SIM card used in the Nokia terminal/Nokia GSM
module must have CSD enabled. In addition, the Gateway requires a modem
pool to utilize CSD. The modem pool is typically connected to the GSM
operator’s network using some landline connection, such as ISDN or modems.
Depending on the model used, the modem pool can usually handle several
connections, thus making it possible to establish concurrent connections.
35/67
4.1.1.5 High Speed Circuit Switched Data
When High Speed Circuit Switched Data (HSCSD) is used, the Nokia
terminal/Nokia 12 module can send and receive data with several time slots at
the same time, which enables higher data transfer rates. The time slot usage is
presented as the number of downlink and uplink slots used. Like CSD, HSCSD
can be chosen as a bearer when large amounts of data needs to be
transferred. HSCSD offers higher data transfer rates than CSD, but an HSCSD
connection also costs more than a CSD connection.
Note: The network may adjust the speed of an HSCSD connection (depending on
the traffic load, for example). Thus HSCSD may correspond to a regular CSD
connection.
To utilize HSCSD, the SIM card used in the Nokia terminal/Nokia 12 module
must have HSCSD enabled. In addition, the Gateway requires a modem pool to
utilize HSCSD. The modem pool is typically connected to the GSM operator’s
network using some landline connection, such as ISDN or modems. Depending
on the model used, the modem pool can usually handle several connections,
thus making it possible to establish concurrent connections.
4.1.2 Bearer selection

In general the selection of the bearer depends on the application. If there are no
special bearer requirements, the selected bearer can simply be stored in a file
or a database.
In the Platform bearer settings can be configured locally using the Configurator
or remotely using the TMC. If bearer settings are configured locally to the Nokia
terminal/Nokia 12 module using the Configurator, the same settings must be
configured separately to the DIS. If bearer settings are configured remotely to
the Nokia terminal/Nokia 12 module using the TMC, the TMC updates the
settings to the DIS automatically. The bearer settings are stored in non-volatile
memory.
For more information, see the Nokia M2M Platform Configuration Manual and
Nokia M2M Platform Terminal Management Component User Guide.
Figure 18 illustrates the Platform components to which the bearer settings are
configured (C).
36/67
Remote
device Nokia M2M
Gateway
Nokia GSM
Service Provider
Connectivity Customer
Edition Gateway
Terminal server
Access
Software application
C
Local GSM
connectivity network Internet
C
Nokia 12
GSM module C
Device
Remote Information
device Storage
Figure 18. Bearer settings in the Platform

The Platform also enables dynamic bearer selection. The AM can select the
bearer dynamically when it establishes a connection to the customer server
application. The use of dynamic connections requires that the authentication
data has been preconfigured to the DIS. The dynamic connections are stored in
volatile memory.
Note: Dynamic connections can only be used for tasks that require temporary
connections (such as maintenance).
4.1.3 Maximum message sizes

The bearer-based maximum messages sizes for the Nokia terminal are
presented in Table 2. Note, that when fragmentation is used, the maximum
message length depends only on the Object Request Brokers (ORB) used in
both ends of the application. For more information on CORBA fragmentation,
see Chapter 4.1.4
Table 2. Bearer-specific message size limitations for the Nokia terminal

GSM bearer Maximum size of one Maximum data packet size
message (without fragmentation)
SMS 140 bytes** 1400 bytes
GPRS N/A* 1480 bytes
CSD N/A* 1480 bytes
HSCSD N/A* 1480 bytes
37/67
* Only applicable, when the bearer is a messaging bearer.
** This size applies to the binary messages used in the Platform.
The bearer-based maximum messages sizes for the Nokia 12 module are
presented in Table 3. Note, that when fragmentation is used, the maximum
message length depends only on the ORB used in both ends of the application.
Table 3. Bearer-specific message size limitations for the Nokia 12 module

when using WAP
GSM bearer Maximum size of one Maximum data packet size
message (without fragmentation)
SMS 140 bytes** 1400 bytes
GPRS N/A* 1480 bytes
EGPRS N/A* 1480 bytes
CSD N/A* 1480 bytes
HSCSD N/A* 1480 bytes
* Only applicable, when the bearer is a messaging bearer.
** This size applies to the binary messages used in the Platform.
Note: The bearer-specific message size limitations for GPRS, EGPRS, CSD, and
HSCSD presented in Table 3 apply only when WAP is used with the Nokia 12
module.
When TCP/IP is used with the Nokia 12 module, the GPRS, EGPRS, CSD, and
HSCSD message sizes are limited only by the memory capacity of the AM
and/or IMlet. The memory capacity available in the Java heap of the IMlet is
256 kbit, which is partly used by the internal functions of the IMlet. The
customer defines the memory capacity of the AM.
4.1.4 CORBA fragmentation

Note: Fragmentation has to be configured only when WAP is used. When TCP/IP
is used, the TCP layer handles fragmentation automatically.
If an application uses CORBA messages in which the data packets exceed the
size limitations specified in Chapter 4.1.3, CORBA fragmentation is needed. If
messages that exceed the size limitations are sent without fragmentation, they
are discarded due to memory limitations of the Nokia terminal/Nokia12 module
If CORBA ORB software with GIOP 1.2 fragmentation support is used, the
terminal and module ORBs fragment CORBA messages automatically without
modifications in the application. The ORBs need to be configured to use
38/67
fragmentation and the maximum message sizes must be set according to the
limitations specified in Chapter 4.1.3.
For more information on how to configure ORBs to use fragmentation, see the
Nokia M2M Platform Remote Application Programming Guide and Nokia M2M
Platform Server Application Programming Guide.
4.2 COMMUNICATION IN THE APPLICATION DEVELOPMENT

ENVIRONMENT
The Nokia M2M system architecture provides several options for
communicating in the application development environment. Applications can
be developed using actual Platform components or an environment, in which
one or more of the Platform components are simulated. Figure 19 illustrates the
communication options that are available in the application development
environment.
GSM network
Application
Module/PC
1 SMS/
CSD
Nokia M2M
Gateway
Trial Version
Customer
Application server
Module/PC application
2
SMS
Application
Module/PC Nokia 12 IMP 1.0
Concept Simulator
3 TCP/IP
Nokia GSM Nokia 12

Connectivity Terminal GSM module
(with RS-232 data adapter) (with test board)
Figure 19. Communication in the application development environment

The following chapters describe the communication characteristics for the
application development environments illustrated in Figure 19. Chapter 4.2.1
39/67
describes the communication when the Nokia terminal (1) is used, and Chapter
4.2.2 when the Nokia 12 module (2) is used. Chapter 4.2.3 describes the
communication of an entirely simulated environment (3) that is available for
developing and testing Java IMlets.
4.2.1 Communication with the Nokia GSM Connectivity Terminal in the

application development environment
When applications are developed with the Nokia terminal, the customer remote
application can be a simulating PC or a real embedded AM. When a simulating
PC is used, the Nokia terminal (mounted in the RS-232 data adapter) must be
configured to use the M2M System Protocol and the connection between the
Nokia terminal and the PC is established via the RS-232 serial bus. Figure 20
illustrates the application development environment in which the Nokia terminal
is used with a simulating PC.
Figure 20. Simulating PC connected to the Nokia terminal with an RS-232

cable
If a real embedded AM is used instead of a PC, the AM is connected to the
Nokia terminal with the M2M System Connector (either the terminal is mounted
to the AM, or the two components are connected with a flat cable).
When applications are developed with the Nokia terminal using wireless
connectivity, SMS and CSD bearers can be used to access the GSM network
as illustrated in Figure 19. The Nokia terminal that is connected to the Trial
Version with an RS-232 serial cable functions as a modem, and its connection
type must be set to use either HW detection (default) or AT commands.
40/67
When wireless connectivity is used for application development with the Nokia
terminal, it is also possible to create a partly simulated Platform in which the
application logic of the AM, Trial Version and the customer remote application is
located inside a PC. Although located on the same PC, the simulated
applications communicate with each other wirelessly through the Platform (not
through the computer’s TCP/IP stack or shared memory) as illustrated in Figure
21.
GSM
network
Application Nokia M2M

Module Gateway
Trial Version
Customer
PC server
application
Figure 21. Nokia terminal in a partly simulated application development

environment
4.2.2 Communication with the Nokia 12 GSM module in the application

development environment
When applications are developed with the Nokia 12 module, the customer
remote application can be a simulating PC or a real embedded AM. When a
simulating PC is used, the Nokia 12 module (mounted in the test board) must
be configured to use the M2M System Protocol (COM2 port) and the
connection between the Nokia 12 module and the PC is established via the RS-
232 serial bus. Figure 22 illustrates the application development environment in
which the Nokia 12 module is used with a simulating PC.
41/67
Figure 22. Simulating PC connected to the Nokia module (mounted in the
test board) with an RS-232 cable
If a real embedded AM is used instead of a PC, the AM is connected to the
Nokia 12 module with the M2M System Connector (the Nokia 12 module is
mounted to the AM).
When applications are developed with the Nokia 12 module using wireless
connectivity, SMS bearer can be used to access the GSM network as illustrated
in Figure 19. The Nokia 12 module (mounted in the test board) that is
connected to the Gateway (Trial Version) with an RS-232 serial cable functions
as a modem, and it communicates using AT commands via the COM1 port.
Note: When applications are developed with the Nokia 12 module using wireless
connectivity and Trial Version, the Java environment of the IMlets is not available.
When wireless connectivity is used for application development with the

Nokia12 module, it is also possible to create a partly simulated Platform in
which the application logic of the AM, Gateway (Trial Version) and the customer
remote application is located inside a PC. Although located on the same PC,
the simulated applications communicate with each other wirelessly through the
Platform (not through the computer’s TCP/IP stack or shared memory) as
42/67
GSM
network
Application Nokia M2M

Module Gateway
Trial Version
Customer
PC server
application
Figure 23. Nokia 12 module in a partly simulated application development

environment
4.2.2.1 Nokia 12 test board

The Nokia 12 test board is a custom-made hardware tool that can be used to
develop applications and to test the functionality of the Nokia 12 module. The
key components of the of the Nokia 12 test board are illustrated in Figure 24.
43/67
COM3 COM2 COM1
Nokia 12 test board
Nokia 12 GSM module

Power connector
Antenna adapter cable
Figure 24. Nokia 12 module attached to the Nokia 12 test board

The three serial ports used for communication are all equipped with RS-232 -
level translators. The COM1 port is used for AT commands and the COM2 port
is used for the M2M System Mode. The COM3 port can be used for Global
Positioning System (GPS), Java IMlet serial connections and general I/O pin
handling.
Note: Java IMlet serial data transfer to/from the Nokia 12 test board can only be
established via the COM3 port.
For more information on the Nokia 12 test board, see the Product Specification
for Nokia 12 GSM Module and Nokia M2M Platform Nokia 12 GSM Module
IMlet Programming Guide.
4.2.3 Communication with the Nokia 12 IMP 1.0 Concept Simulator

The Nokia 12 IMP1.0 Concept Simulator (hereon Simulator) can be used to
develop and test Java IMlets before they are loaded to the Nokia 12 module.
The Simulator is a fully simulated environment in which the application logic of
all the necessary Platform components has been incorporated within one PC.
Figure 25 illustrates the functionality of the Simulator.
44/67
PC
Nokia 12 Nokia M2M
Application C IMP 1.0 Gateway
Module O Concept Trial Version
M Simulator
Local
TCP/IP
stack
Customer
server
application
Figure 25. The Nokia 12 IMP 1.0 Concept Simulator

As illustrated in Figure 25, the communication between the simulated Platform
components is conveyed via a local TCP/IP stack. For more information on the
features of the Simulator, see the Nokia M2M Platform Nokia 12 IMP 1.0
Concept Simulator User Guide.
4.3 CORBA COMMUNICATION IN THE PRODUCTION ENVIRONMENT

The M2M applications are distributed applications by their nature. The Platform
utilizes CORBA technology to decrease the amount of difficulties in distributed
computing. Although an application developer does not need to have broad
knowledge of CORBA to be able to make software applications on top of the
Platform, it is nevertheless useful to know the basics of CORBA.
CORBA is an object-oriented distributed computing technology used mainly on

the Internet. A non-profit, open membership consortium called the Object
Management Group (OMG), in co-operation with its member companies
including Nokia, has developed it. When creating CORBA the OMG, together
with its member companies, has aimed for a network-transparent programming
architecture that is vendor, operating system and language independent.
In the Platform context network-transparent programming means that CORBA

is used to hide the complexities of a wireless network from the application
developer. When a customer server application makes a method call to an AM,
the syntax of the method call is the same irrespective of whether the AM shares
the same computer with the server application, or whether it is located on the
other corner of the world, connected to the server application through a wireless
network.
Note: Even though the Platform is based on object-oriented programming it is still

possible to make software applications for the Platform by using procedural
45/67
programming languages (such as ANSI C).
Through the CORBA interface definition, objects residing in different devices,

implemented in different languages, and running on different operating systems
can still interact with each other through method call interfaces. These
interfaces are given interface definitions with the Interface Definition Language
(IDL), which is used in CORBA to define an API.
An interface definition that defines the interface of a given application can be

compiled, either manually or automatically, with an IDL compiler to generate the
so-called stub and skeleton codes. The stub and skeleton codes, which are
included in the client and/or server applications at the time of implementation,
make it possible for applications that implement the same interface definition to
call each other’s methods even if they use different method call formats
internally.
The internal method invocation call of the client application is captured by the
stub, and it is converted into a general method call protocol called General
Inter-ORB Protocol (GIOP) before it is sent to the server application. After
receiving the GIOP message, the skeleton of the server application converts it
to the internal method call format that is used in the server application.
The use of CORBA requires middleware elements for routing method calls
between different applications. In CORBA the middleware elements used for
routing method calls are called Object Request Brokers (ORB). An ORB can
route the messages to a target object in the same device or to another device
through a data connection. ORBs and the generated stub and skeleton codes
hide the transmission technology complexities completely; the objects in the
client and server applications can only see each other’s method call interfaces.
The basic CORBA architecture is illustrated in Figure 26.
IDL
Client Server
methodCall() methodCall()
Stub Skeleton
Request
ORB ORB
Figure 26. CORBA overview
46/67
4.3.1 Clients and servers in the Nokia M2M Platform
As described in Chapter 4.3, the CORBA interface definitions are used in the
Platform to define the interfaces that are used for communication between
system entities like customer remote and server applications. An interface
definition can be used to generate a stub (client) or a skeleton (servant) code,
or both.
The Platform does not set restrictions on the use of clients and servants. An
application can include both the client and servant.
4.3.2 Using CORBA observers in the Nokia M2M Platform

In general CORBA observers can be used to replace constant information
exchange with information exchange in which only certain predefined and
significant events are reported.
For example, a customer server application controlling several Nokia 12

modules might want to know when there are I/O pins state changes in the
Nokia 12 modules that it controls. The customer server application could use
polling to get information on the I/O pin states. That is, it could send information
requests to each Nokia 12 module on regular intervals. However, the use of
polling in the Platform would generate a lot of traffic over the GSM network and
increase communication costs.
To avoid redundant traffic, the customer server application can set an ‘I/O pin’
observer to each Nokia 12 module, and let the observers inform whenever
there is an I/O pin state change in one of the Nokia 12 modules that is controls.
Figure 27 illustrates a case in which an ‘I/O pin’ observer is set to a Nokia 12
module.
Customer
Nokia 12 GSM Nokia M2M server
module Gateway application
2
ORB ORB
ORB 1
3
Observer Listener
Figure 27. Using an observer in the Nokia 12 module
47/67
First a listener object is created to the customer server application ORB (1).
Then the customer server application sets an observer that is designed to
observe I/O pin states to the Nokia 12 module ORB (2), and gives it an object
reference to the listener object located in the customer server application ORB.
When the observer in the Nokia 12 module ORB registers a change in an I/O
pin status, it sends an I/O event to the customer server application (3).
If there are other applications that are interested in the same event, it is
recommended that the event is distributed to them (4).
When the observer is no longer needed, it must be removed (5).
Guidelines for designing observers

The CORBA standard does not give strict rules as to how observers should be
used. However, there are certain factors that need to be noted when planning
their use.
First, if there are several applications that need to be informed about the same
event, only one of them should set the desired observer. Once the observer has
been set, the other applications can request for the observed events from the
application that is registered to listen to the specified events.
Note: To avoid redundant traffic over the wireless network, the other applications
should use TCP/IP over LAN when requesting for the observed events.
Second, if a particular application observes an event only temporarily, it is

recommended to unsubscribe the observer registration from the application
once the observer is no longer needed (to avoid redundant traffic).
Furthermore, if there are no applications listening to a particular observer, the
observer should be removed because the observer keeps sending events even
though there are no listeners anymore.
4.4 CORBA ADDRESSING IN THE NOKIA M2M PLATFORM

This chapter provides a short introduction to the CORBA addressing in general
and to the addressing solutions that are used in the Platform. It also includes a
description on the typical CORBA addressing cases used in the Platform.
In CORBA remote objects are located by using Interoperable Object

References (IOR). An IOR is an object reference that is used to locate objects
in different Platform applications. A CORBA service called the Naming Service
is used to retrieve IORs by using a name.
The CORBA Naming Service can be compared to the Domain Name System
(DNS) used in Internet addressing. Whereas the DNS translates host names
like www.nokia.com into numerical IP addresses, like 147.243.3.73, the
48/67
CORBA Naming Service translates object reference names (aliases) like
‘HelloWorldServer’ into IORs.
A typical M2M application has a large number of objects that implement the
same interface, but are located in separate Nokia terminals or Nokia 12
modules. Furthermore, the details of these Nokia terminals and Nokia 12
modules are stored in some application-specific data storage. Before the client
application can access objects located in remote Nokia terminals and/or Nokia
12 modules, it must receive an object reference to that object. Due to this, there
are two issues that need to be considered.
Firstly, the Interoperable Object References (IORs) in the Nokia M2M platform
must contain an Internet Inter-ORB Protocol (IIOP) profile with TCP/IP address
that points to the Nokia M2M Gateway. The real addressing details of a Nokia
terminal or Nokia 12 module must be stored in the object key field of the IIOP
profile.
Secondly, how to publish the IOR to the client software must be defined. In
CORBA applications, object references are typically published by binding IORs
to the Naming Service. In that case information is stored in two places: an
application-specific data storage and the Naming Service. This may introduce
some synchronisation problems.
Also, binding to the Naming Service tends to be rather static. This means that
the object reference cannot change dynamically, for example, to reflect the
preferred bearer.
The issues described above can be solved by using an application-specific

extension of the Naming Service called the Nokia Active Naming Context
(ANC). The Nokia ANC uses the application-specific data storage to retrieve
addressing details of Nokia terminals and/or Nokia 12 modules, thus eliminating
the need to duplicate data. The Nokia ANC can also construct IORs in a
dynamic fashion. This enables the Naming Service to control how the
application uses different bearers to access remote objects.
For more information on how the Nokia ANC is used, refer to Chapter 4.4.3.1.
4.4.1 Obtaining IORs with the customer remote application -originated

CORBA requests
In the Platform there are several options available for obtaining object
references when the CORBA requests are customer remote application -
originated. The options are
• Named references
• The standard CORBA Naming Service
• Object reference transfer
49/67
• Generating IORs using IMlets
Note: An encapsulated addressing mechanism is used when IORs are obtained

via object reference transfer or via the standard CORBA Naming Service. For
more information on the encapsulated addressing mechanism, see Chapter
4.4.1.5.
4.4.1.1 Obtaining IORs using named references

The first (and recommended) option for obtaining an IOR is to use named
references. Figure 28 illustrates the process of using named references in
customer remote application –originated CORBA requests.
Nokia GSM
Connectivity
Terminal/ Nokia M2M Gateway Customer
Application Nokia 12 GSM Gateway Service Access server
Module module Provider Edition Software application
2 3
6
4 5
CORBA
Naming
Service
Figure 28. Obtaining an IOR using named references

Before the customer remote application (in the Nokia terminal, Nokia 12 module
or Application Module) can request for a named reference, the server
application has to create a servant and register it (send an IOR) to the CORBA
Naming Service. The name of the servant can be, for example,
“HelloWorldServer” (1).
50/67
Once the servant has been registered, the customer remote application creates
a named reference by using its ORB, and makes a request using the named
reference it created (2).
The Gateway (Service Provider Edition) sends the request to the corresponding
Gateway Access Software (3). The Gateway Access Software requests for the
corresponding IOR from the Naming Service, and the Naming Service returns
the requested IOR (4) (5).
Note: The Gateway and the customer server application must share the same
Naming Service.
After the Gateway Access Software has received the requested IOR, it
regenerates the CORBA request and sends it to the customer server
application (6). Finally the customer server application sends a reply message
to the customer remote application via the Gateway (7).
4.4.1.2 Obtaining IORs using the standard CORBA Naming Service

The second option to obtain an IOR is to use the standard CORBA Naming
Service. The use of the standard CORBA Naming Service is based on binding
IORs to the Naming Service. Figure 29 illustrates the process of using the
standard CORBA Naming Service in Nokia 12 module (IMlet) –originated
CORBA requests.
51/67
Nokia M2M Gateway Customer
Nokia 12 GSM Gateway Service Access server
module Provider Edition Software application
6
IMlet
2 3
4 5
Port: 19760
1
CORBA
Naming
Service
Figure 29. Obtain an IOR using the standard CORBA Naming Service
In this case the customer server application has to bind the servant (server
application object reference) to the Naming Service (1) before the IMlet (in the
Nokia 12 module) can make a Naming Service look-up.
Once the servant has been bound to the Naming Service, the IMlet can make a
CORBA request for the servant (2). The Gateway (Service Provider Edition)
sends the request to the corresponding Gateway Access Software (3). The
Gateway Access Software requests for the corresponding IOR from the Naming
Service, and the Naming Service returns the requested IOR (4) (5).
Note: The use of the standard CORBA Naming Service requires that the IMlet
knows the IP address and the port number of the Naming Service.
The Gateway Access Software forwards the reply from the Naming Service to
the IMlet (6) via the Gateway. At this point the IMlet is able to open a
connection to the customer server application via the Gateway and Gateway
Access Software (7).
Note: If the standard CORBA Naming Service is used, it must be ensured that
the IOR of the customer server application remains unchanged.
52/67
4.4.1.3 Obtaining IORs using object reference transfer
It is possible to transfer CORBA object references in the Platform. That is, one
object can return a reference to another object. For example, object A can
request for an object reference to object C from object B, and object B can
return the object reference of object C to object A.
In CORBA object factories are typically used in object transfers. In terms of

CORBA, an object factory is an object that generates object references to other
objects. For an example on how an object factory can be used in the Platform,
see the Nokia M2M Platform Server Application Programming Guide.
4.4.1.4 Generating IORs using IMlets

When the Nokia 12 module is used, it is possible to use the IMlet ORB to obtain
an IOR. A createReference method can be used within the IMlet ORB to
generate an IOR.
Note: The use of the createReference method requires that the object key and
the location of the target object are known.
For more information on the createReference method, see the Nokia M2M
Platform Nokia 12 GSM Module IMlet Programming Guide.
4.4.1.5 Encapsulated addressing mechanism

An encapsulated addressing mechanism is used internally by the Platform
when IORs are obtained via object reference transfer or the standard CORBA
Naming Service.
The encapsulated addressing mechanism, which is performed automatically by

the Platform components, is illustrated in Figure 30.
53/67
Nokia GSM
Connectivity
Terminal/ Customer
Nokia 12 Nokia M2M server
GSM module Gateway application
1 3
2
Figure 30. Encapsulated addressing mechanism

In the example illustrated in Figure 30 the Nokia terminal/Nokia 12 module has
already obtained an IOR that contains the customer server application target
information.
The ORB of the Nokia terminal/Nokia 12 module encapsulates the customer

server application target address in the object key -field of the GIOP message,
and makes a CORBA request (1).
The Gateway recognizes that the CORBA request has an encapsulated target
address. It decapsulates the target address from the object key and
regenerates a new CORBA message (2).
On the basis of the target information the Gateway is able to send the new
CORBA request to the customer server application (3).
4.4.2 Publishing IORs from the customer remote application

In the Platform there are two options available for publishing object references
when the CORBA object of the customer remote application is located in the
Nokia 12 module or AM (connected to the Nokia 12 module with the M2M
System Protocol 2):
• Publishing IORs dynamically

Note: The following chapters provide a detailed description of how object

references are transferred when IORs are published from the customer remote
application. For the software developer the use of Mobile IORs is no different than
the use of ordinary IORs.
54/67
4.4.2.1 Publishing IORs dynamically
The customer remote application utilizes Mobile IORs (MIOR) for publishing
object references dynamically. A Mobile IOR is a special IOR that hides the
mobility of the customer remote application from clients that invoke operations
on target objects located in the Nokia 12 module/AM. Figure 31 illustrates the
process of using a MIOR.

Service Provider Gateway Access server
Application Nokia 12 GSM Edition Software application
Module module
1
4 3
Home Location Agent
6 5
Device
Information
Storage
Figure 31. Publishing an IOR dynamically with the Nokia 12 module/AM

In Figure 31 the customer server application must have an object reference to
the CORBA object of the customer remote application.
The server application invokes the process by sending a CORBA request to the
remote application. The remote application replies by sending a special MIOR
(2) that includes a mobile terminal profile, which refers to the requested object.
After receiving the MIOR the server application sends an object reference
request on the basis of the addressing information in the MIOR’s IIOP profile
(3). Instead of pointing to the target object in the remote application, the IP
address, and the port number in the IIOP Profile point to the Home Location
Agent (HLA) of the domain to which the remote application belongs to (3).
55/67
The HLA examines the mobile terminal profile of the MIOR to find out the
location of the target object (4). Once the HLA has identified the target object, it
requests the addressing details of the remote application from the Device
Information Storage (DIS) (5), which returns the requested addressing details
(6).
Finally the HLA sends a location_forward CORBA message (with the

addressing details) to the ORB in the customer server application (7). The ORB
examines the location_forward CORBA message, regenerates the request, and
sends it to the corresponding remote application (8).
Note: Dynamic object reference publishing is configuration dependent. That is,

the MIOR that the customer remote application publishes is routed according to
the terminal ID and the IP address and port number of the HLA.
If these configuration variables change during object reference publishing, the
dynamic connection will be broken.
4.4.2.2 Publishing IORs using the standard CORBA Naming Service

The other option available for publishing object references with the customer
remote application (located in the Nokia 12 module or AM) is to use the
standard CORBA Naming Service. The process of publishing an IOR with the
customer remote application using the standard CORBA Naming Service is
56/67
CORBA
Naming
Service
Nokia M2M
Gateway Service 3
Provider Edition
4
Application Nokia 12 2
Module GSM module
Customer
1 server
application
9
10
5
8
6
7
Device Home
Information Location
Storage Agent
Figure 32. Publishing an IOR with the Nokia 12 module/AM using the
standard CORBA Naming Service
In this case the customer remote application must publish its object reference
by binding it to the CORBA Naming Service before the customer server
application can make a reference request. The remote application binds its
object reference to the Naming Service via the Gateway (1) (2).
Once the remote application has bound its object reference (IOR that includes a
MIOR) to the Naming Service, the server application can make a reference
request for it. It requests for the corresponding IOR from the Naming Service
(3), and the Naming Service returns the requested IOR (4).
Note: The use of the standard CORBA Naming Service requires that the
Gateway and the customer server application know the IP address and the port
number of the Naming Service, and that they share the same Naming Service.
The server application makes an object reference request on the basis of the
addressing information in IOR (5).
57/67
The HLA examines the mobile terminal profile of the MIOR to find out the
remote application on which the target object is located. Once the HLA has
identified the target object, it requests the addressing details of the remote
application from the Device Information Storage (DIS) (6), which returns the
requested addressing details to the HLA (7).
After receiving the addressing details from the DIS, the HLA sends a
location_forward CORBA message to the ORB in the server application (8). The
ORB examines the location_forward message and sends it to the remote
application in question (9). Finally the remote application sends a reply to the
server application (10).
Note: If the standard CORBA Naming Service is used to with the Nokia 12
module to publish object references (for example to establish a connection
between two Nokia 12 modules), it must be ensured that the actual CORBA object
in the IMlet is always given the same persistent reference when it restarts.
Otherwise the original object reference in the CORBA Naming Service becomes
invalid when the IMlet restarts.
4.4.3 Obtaining IORs with the customer server application -originated

CORBA requests
In the Platform there are three options available for obtaining object references
when the CORBA requests are customer server application -originated:
• The Nokia Active Naming Context (ANC)

• Obtaining IORs dynamically
4.4.3.1 Obtaining IORs using the Nokia Active Naming Context

The Nokia ANC is a CORBA Naming Service extension that is written in Java
programming language. A Nokia ANC instance is bound to an existing Naming
Service. Typical object references to customer server objects and other static
objects are bound to the Naming Service as usual, and the Nokia ANC resolves
only those objects that are located in the Nokia terminal, Nokia 12 module or
AM. Figure 33 illustrates the process of using the Nokia ANC to obtain an IOR.
58/67
Nokia GSM
Connectivity
Terminal/ Nokia M2M Gateway Customer
Application Nokia 12 GSM Gateway Service Access server
Module module Provider Edition Software application
6
7 5
1
4
CORBA Naming Service
Nokia ANC
iorgen M2MDevices
2 3
Device
Information
Storage
Figure 33. Obtaining an IOR using the Nokia Active Naming Context
In this case the customer server application invokes the communication by
sending an object reference request to the CORBA Naming Service. In the
request the customer server application requests the Naming Service to resolve
the addressing details of a specific customer remote application by using the
Nokia ANC that the Gateway Access Software has registered to the Naming
Service (1).
Depending on the contents of the reference request, the Nokia ANC resolves
the addressing details using either the IOR generator (‘iorgen’) or ‘M2MDevices’
ANC instance. The use of the ‘iorgen’ requires that the original reference
request includes the bearer, object key, type identification, and port number
information in addition to the terminal ID. On the basis of that information set
59/67
the ’iorgen’ is able to generate the required IOR for the remote application in
question.
The use of the ‘M2MDevices’ instance is easier because it can generate the
required remote application IOR on the basis of the terminal ID and alias name.
As described in Figure 33, the ‘M2MDevices’ instance uses the DIS application
to obtain the required bearer and class information (object key, type
identification and port number) (2). After receiving the request from the
‘M2MDevices’ instance, the DIS returns the corresponding IOR back to the
‘M2MDevices’ instance (3).
Note: The use of ‘M2MDevices’ instance requires that the bearer and class
information is configured in the DIS. Nokia provides a text-based implementation
of DIS that is intended to be used in development phase only. In end-use, it is
recommended to make a DIS implementation that uses a database.
Once the Nokia ANC has resolved the requested addressing details (either
using ‘iorgen’ or ‘M2MDevices’), it sends an IOR to the server application (4).
The server application then sends a request to the Gateway (Service Provider
Edition) via the Gateway Access Software (5). The Gateway solves the final
destination of the request from the IOR (6), and then opens up a connection to
the corresponding remote application (7). Finally the remote application in
question sends a reply to the server application (8).
4.4.3.2 Obtaining IORs dynamically

Chapter 4.4.2.1 describes how to obtain an IOR dynamically with the customer
server application.
4.4.3.3 Obtaining IORs using the standard CORBA Naming Service

Chapter 4.4.2.2 describes how to obtain an IOR with the customer server
application using the standard CORBA Naming Service.
4.4.4 Publishing IORs with the customer server application

In the Platform there are two options available for publishing object references
when the object is located in the customer server application:
• Named references
4.4.4.1 Publishing IORs using named references

Chapter 4.4.1.1 describes how to publish an IOR with the customer server
application using named references.
60/67
4.4.4.2 Publishing IORs using the standard CORBA Naming Service
Chapter 4.4.1.2 describes how to publish an IOR with the customer server
application using the standard CORBA Naming Service.
61/67
5 DEPLOYMENT AND CONFIGURATION OF THE PLATFORM
SERVICES
This chapter provides an overview of the deployment and configuration of the
Platform services. The overview includes a configuration and deployment
example and short descriptions on the key components and techniques used in
the deployment/configuration process.
Note: The Nokia M2M solution enables flexible deployment and configuration of
the Platform services. The customer can utilise the interfaces and components
provided by Nokia can to build a custom-made configuration/deployment solution.
5.1 DEPLOYING AND CONFIGURING THE PLATFORM SERVICES
This chapter provides one possible example of deploying and configuring the
Platform services. The use of the different Nokia interfaces and components is

Gateway Service Access server
Provider Edition Software application
5
1
2
4
3
Nokia GSM
Connectivity Device
Terminal/ Information
Nokia 12 GSM Storage
module
Figure 34. Deploying and configuring the Platform services
Note: In this example the customer is responsible for implementing the customer
server application and DIS.
62/67
First the maintenance person installs the Nokia terminal or Nokia 12 module
and sends a short message that includes the terminal/module MSISDN to the
customer server application via the Gateway (1).
Then the Terminal Management Component (TMC) that runs on the customer
server application is used to configure the Nokia terminal/Nokia 12 module (2).
When the Nokia terminal/Nokia 12 module is configured for the first time, a
Smart Messaging interface is used via the TMC API.
When the TMC is used, the system also stores the configuration information
into the Device Information Storage (DIS) (3).
Once the configuration information has been stored, the customer server
application is used to test the connection to the Nokia terminal/Nokia12 module
(4). If necessary, the configuration can be reconfigured at this point.
When the process has been completed, the customer server application is used
to inform the maintenance person of the configuration status (5). The
maintenance person can be notified by sending a short message to his/her
mobile equipment (or by sending a LED indication to the remote device).
5.1.1 The Terminal Management Component

The TMC is used to configure Nokia terminals and Nokia 12 modules to
communicate with a specified Gateway. When the TMC used with the Service
Provider Edition, it is connected to the Gateway Access Software as illustrated
in Figure 35.
Nokia GSM GSM

Connectivity TCP/IP
Terminal Service Provider Gateway Access
GSM Edition Software
Nokia 12
GSM module TCP/IP Device
Information
Terminal Storage
Management
Component API
Customer
server
application
Figure 35. Using TMC with the Service Provider Edition
The TMC is a software component that can be embedded into Java

applications. It incorporates the necessary methods to configure Nokia
terminals and Nokia 12 modules with various communication bearers using
different configuration options.
63/67
The configuration options consist of user-defined parameters and parameters
that are set in the Service Provider Edition. The user can define only certain
parameters (such as proper bearer types, terminal IDs and dial numbers). The
Gateway parameters are collected automatically by TMC. For more information
on TMC, see the Nokia M2M Platform Terminal Management Component User
Guide.
5.1.2 The Device Information Storage

As described in Chapter 5.1, the TMC automatically stores the configuration
information into the DIS when it is used to configure the Platform services. The
Gateway uses the DIS for handling information related to Nokia terminals and
Nokia 12 GSM modules.
When the TMC stores the configuration information in the DIS, it configures the
user and bearer information of the DIS. The user information contains
identification information (IDs and passwords) related to the Nokia
terminals/Nokia 12 modules. The bearer information contains information on the
bearers (used bearers, ports, and timeouts) that are used by the Nokia
terminals/Nokia 12 modules.
The Gateway uses the User Information interface to authenticate connections

between the Gateway and Nokia terminals/Nokia 12 modules. The Bearer
Information and Class Information interfaces of the DIS are needed when the
customer server application requests the Nokia ANC to create object
references for CORBA client applications. For more information on the DIS, see
the Nokia M2M Platform Device Information Storage Programming Guide.
5.2 REMOTE APPLICATION MODULE UPDATE

The Remote AM Update feature makes it possible to update the Application
Module firmware over-the-air from the customer server application via the
Gateway and Nokia 12 module.
A logical view of the Remote AM Update feature is presented in Figure 36.
64/67
Customer remote Nokia Server
application M2M
Gateway
Application
Module
Remote AM Customer server
Update bootloader application
Remote
AM Update API
Protocol calls
Remote AM Update CORBA Remote AM

CORBA Servant Update API
Nokia 12
GSM module
Figure 36. A logical view of the Remote AM Update feature
Note: When the Remote AM update feature is used, the customer is responsible
for implementing the customer server application and Remote AM Update
bootloader.
The customer server application initiates the Application Module firmware

update process by checking the status of the AM. If there are ongoing
operations or transactions in the Nokia 12 module, the customer server
requests the Nokia 12 module to enter the Remote AM Update mode. Before
entering the Remote AM Update mode, the Nokia 12 module suspends the
M2M System Protocol traffic towards the AM.
Note: Nokia provides a CORBA client application implementation called Remote

AM Update API that the customer server application can use to control the whole
update procedure via the Gateway and Nokia 12 module. However, it is also
possible to use a custom-made CORBA client application to control the update
procedure.
In the Remote AM Update mode the AM firmware is updated block by block.

The Nokia 12 module has an integrated Remote AM Update CORBA Servant
65/67
functioning as a proxy. It translates messages coming from the API to a suitable
format for the bootloader. The CORBA Servant uses the Remote AM Update
CORBA interface to communicate with the customer server application, and the
Remote AM Update Protocol is used for communicating with the bootloader.
The bootloader is part of the AM software. The bootloader code implements the
Remote AM Update process in the AM. It facilitates communication with the
CORBA Servant, receives new firmware, erases the non-volatile memory of the
AM, and writes new firmware into it.
When the update procedure for all the blocks has been completed successfully,
the customer server application requests the Nokia 12 module to exit the
Remote AM Update mode. The Nokia 12 module resets the AM and restores
the M2M System Protocol operation. An exit is requested also in the case of a
failure. A new update procedure cannot be started before finishing the old one.
When the AM has undergone a normal boot-up, it returns to its normal

operation mode. It is up to the customer server application to check that the AM
is working properly with the freshly updated firmware.
For more information on the Remote AM Update feature, see the Nokia M2M
Platform Remote Application Module Update Programming Guide.
5.3 THE JAVA IMLET LOADING COMPONENT

The Java IMlet Loading Component (ILC) API provides functions to download
Java IMlet applications packed into Java IMlet Suites to Nokia 12 GSM
modules. The download process can be done over-the-air using the Gateway.
Figure 37 illustrates the use of the ILC API.
66/67
Nokia 12 GSM
module
GSM/GPRS network
Nokia M2M Gateway
TCP/IP
CORBA ORB
Java ILC API
Customer server application
Computer
Figure 37. The Java IMlet Loading Component
The ILC API provides IMlet Suite download functions that can be used in
customer applications. The IMlet Suite download process options are
configurable, for example the download packet size can be modified, and a
specified IMlet can be started once the downloading is finished. IMlet Suites
can also be downloaded asynchronously to multiple Nokia 12 modules (one at
a time).
The ILC API also contains a method to retrieve a reference to the

SuiteManager CORBA object located in the Nokia 12 module. The
SuiteManager object offers a method to control IMlet Suites and IMlets. For
more information on the Java IMlet Loading Component, see the Nokia M2M
Platform JavaTM IMlet Loading Component User Guide.
67/67

Nokia M2M Platform: Software Developer'S Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nokia M2M Platform: Software Developer'S Guide

Uploaded by

Copyright:

Available Formats

NOKIA M2M PLATFORM

SOFTWARE DEVELOPER’S GUIDE

ACRONYMS AND TERMS ...................................................................................................... 1

The guidelines in this document are applicable to software development tasks

• Nokia M2M Platform Remote Application Programming Guide

2.1 THE NOKIA M2M PLATFORM OVERVIEW

The Platform provides a scalable communication platform for different solutions

The Platform also makes it possible to run multiple applications concurrently.

2.2 THE NOKIA M2M PLATFORM SYSTEM ARCHITECTURE

Figure 1. Planning M2M system architecture

Depending on the customer case and the surrounding network, the

If Common Object Request Broker Architecture (CORBA) communication is

Figure 3. Local and wireless connectivity in the Platform system

Figure 4. IP traffic in the Platform system architecture

2.3 LOCAL CONNECTIVITY IN THE NOKIA M2M PLATFORM

2.3.1 Local connectivity between the Nokia GSM Connectivity Terminal

When AT commands are used, the Nokia terminal functions as a modem

The Nokia Smart Adapter

Remote device Customer server

Figure 6. The Nokia Smart Adapter in an M2M system

Remote Nokia 12 GSM Wireless

The asynchronous serial connection enables communication between the IMlet

In addition it is possible to connect the Nokia 12 module to an external Global

2.4 COMMUNICATION LINKS IN THE NOKIA M2M PLATFORM

2.4.1 The Nokia GSM Connectivity Terminal

In addition to the functionalities described in Chapter 2.3.1, the Nokia terminal

• Nokia GSM Connectivity Terminal Product Guide

2.4.2 The Nokia 12 GSM module

In addition to the functionalities described in Chapter 2.3.2, the Nokia 12

For more information on the Nokia 12 module, see

• Product Specification for Nokia 12 GSM Module

2.5 WIRELESS CONNECTIVITY IN THE NOKIA M2M PLATFORM

• The Nokia M2M Gateway Trial Version (hereon Trial Version)

GSM network Intranet

CSD RS-232 Customer

Nokia 12 IMP 1.0

Figure 8. The Nokia M2M Gateway Trial Version

2.5.2 The Nokia M2M Gateway Corporate Edition

Figure 9. The Nokia M2M Gateway Corporate Edition

2.5.3 The Nokia M2M Gateway Service Provider Edition

GSM network Service provider network Internet

Customer Gateway Gateway Customer

Nokia GSM Nokia 12

2.5.4 Wireless connectivity components and connections

Customer Gateway Gateway Customer

Figure 11. Wireless connectivity components and connections in the

• If Short Message Service (SMS) is used, a Short Message Service Centre

The Nokia M2M Gateway

The Gateway Access Software

Customer server application

Connections to different enterprise systems, such as databases and Enterprise

For more information on developing customer server applications, see the

2.5.5 Authentication and access control

Figure 12. RADIUS authentication for EGPRS/GPRS communication

The Gateway Access Software sends the authentication result

Note: The RADIUS authentication process for CSD/HSCSD is similar as the

Nokia M2M Gateway Gateway

Figure 13. MSISDN authentication for SMS communication

Note: When the RADIUS or MSISDN authentication is used, the actual

• Customer remote applications to an Application Module

Figure 14. Applications and application development services in the

3.1.1 Making applications to Application Modules

A software developer also needs access to application development services.