Policy-Based Management of Mobile Phones
Articles and Tips: article
Connectotel Ltd, London, UK
01 Mar 2001
This AppNote provides an overview of Mobile Phone Policy Manager, a new software solution from Connectotel Ltd, designed to provide policy-based management of cellphones and other mobile devices. The AppNote describes the development of Mobile Phone Policy Manager, the business requirements for customers who require management of cellphone devices, and the features of Mobile Phone Policy Manager which meet those business requirements.The terms "Cellphone," "Mobile Telephone," and "Mobile Phone" are used interchangeably throughout this AppNote to mean a handheld mobile device capable of being used for any combination of voice, data, and text communication. Since this AppNote was written in the UK, it retains the British spelling used by the author.
Mobile Phone Policy Manager started life as a research project at Connectotel in August 1999. Connectotel had undertaken a large number of assignments implementing the Novell ZENworks (now called "ZENworks for Desktops") software within a variety of customer environments throughout Europe. Conversations with customers at this time indicated that they were pleased that the PC could now be centrally managed as a resource by the IT department. However, that same department-or a telecom department aligned to the IT department-was now having to cope with the management of a new breed of electronic devices; namely cellphones, pagers, and personal digital assistants (PDA)s.
Connectotel had already developed a number of solutions for mobile phone communications, including SMSAlert (a plug-in for Novell ManageWise) and SMSGateWay, which provides e-mail-to-SMS (Short Message Service) messaging. As a result, it was decided to engage with customers to determine their business requirements for management of mobile devices and to begin designing and writing software to satisfy those requirements, which are summarised below. The software was designed to make use of Novell Directory Services (NDS) and to integrate with the existing Novell administration tool, as a series of NWAdmin snap-in modules.
The business requirements for cellphone management, as defined by customers, can be divided into four main categories:
Zero Day Start
Customers reported that they required a means of providing a central register of cellphones and their users, so that the IT or telecoms management teams could always know which cellphones were available and to whom they had been assigned.
Zero Day Start
"Zero Day Start" is a new buzz-phrase referring to the ability of an organisation to have new employees up and running, with all necessary hardware and software, on the first day of work. One of the pieces of hardware often supplied to new employees as a standard business tool is the cellphone.
Customers indicated that they wanted to be able to pre-load the cellphone address book with telephone numbers of all personnel relevant to the new employee joining the organisation. This facility would avoid the need for each new employee to enter this information manually, which is costly in terms of time and could lead to inaccuracies in the entry of the data.
Customers suggested that they required a means of being able to control centrally aspects of the cellphone, including the following:
SMS Service Centre
Cellphone ring tone
Wireless Application Protocol (WAP) configuration
Customers stated that they would like any NDS user to be able to send text messages to cellphones, and for any cellphone user to be able to send e-mail from their mobile phone, without necessarily requiring WAP capability on the phone.
Mobile Phone Policy Manager Features
This section describes the features of the Mobile Phone Policy Manager.
Mobile Telephone Object
The Mobile Telephone is created and managed as a newly defined object within NDS and is associated with a User object.
The NDS Mobile Telephone object benefits the administrator by providing a central point of administration for cellphone devices. The NDS Mobile Telephone object, and its relationship with the NDS User object, are the foundation for the other services described below.
Figure 1 shows the Mobile Telephone object, which is named according to its globally unique telephone number. In this case, the mobile telephone is located in the UK, so its number begins with the international prefix for the UK, which is "44". The other fields relate to properties such as the phone provider, date connected/disconnected, and the manufacturer and model of the phone.
Mobile Telephone object.
The association of the NDS user to the NDS Mobile Phone object is analogous to the relationship between user and workstation in the existing ZENworks for Desktops product.
An extra tab on the NDS User object, shown in Figure 2, allows the administrator to select additional properties, including the mobile telephone policy to be used, the "Calling Circle" to which the user belongs, and whether the mobile telephone should be used as a security token. (This last option will be described more fully in the "Further Applications" section under SMSLogin.)
User object associated with mobile phone, calling circle, and policy.
Each of these features is discussed in more detail below.
Mobile Telephone Policy
The Mobile Telephone Policy is another new NDS object, associated with the user. The policy is extensible, but contains at minimum the following properties:
Message Centre Number
GSM SMS Server
Comm Port for Update
On many recent cellphones it is possible to modify the logo (also known as "operator logo") which appears on the screen of the cellphone, as well as the ring tone. Furthermore, cellphones with WAP capability require configuration parameters which can be set up over-the-air by an administrator with suitable software. Thus, the following properties can be considered to be optional:
Mobile Phone Logo
Mobile Phone Ring Tone
Mobile Phone WAP Policy
Message Centre Number
This is the number which the cellphone uses to send SMS text messages. In international organisations this number will differ from one country to the next, so a different cellphone policy can be created for each country.
GSM SMS Server
GSM SMS Server. This property points to an NDS object, representing the SMS server through which text messages can be sent to the user. The administrator should choose the GSM SMS server which is relevant to the user to whom the policy is being assigned. (Note: GSM stands for Global System for Mobile communications.)
Comm Port for Update
This value indicates the communications port on the administrator workstation which will be used for communicating with the cellphone device.
The first three standard policy parameters can be seen in Figure 3.Mobile Telephone Policy object.
Mobile Telephone Policy object.
Several cellphone vendors, including Nokia and Siemens, allow an administrator to be able to change the logo which appears on the screen of the cellphone. For example, Nokia phones from the 5100 series onwards allow the logo to be defined as a 72x14 2-colour bitmap, corresponding normally to the network operator currently being used.
Mobile Phone Policy Manager makes use of this feature to allow branding of the phone for security purposes, as can be seen in Figure 4.
Logo property of the Mobile Telephone Policy object.
Thus, if the cellphone is lost or stolen, its owner can be easily identified and the phone returned to the corresponding organisation.
A number of cellphone vendors allow the user to define his/her own ring tone on the phone. For example, Nokia phones from the 6000 series onwards allow a user or administrator to define new ringtones in addition to the ring tones provided by the manufacturer. Figure 5 shows how an administrator can define the ring tone as part of a Mobile Telephone policy.
Ring Tone property of the Mobile Telephone Policy object.
The administrator may initialise and update the cellphone address book by associating the user with other users and groups to form a "calling circle" for each user, using standard NDS groups, as can be seen in Figure 6
Calling Circle, a standard NDS group object.
Once the calling circle has been defined, the administrator can upload the phone numbers (both static and cellphone numbers) of the calling circle members, by connecting the phone to the administrator workstation and selecting the option to update the cellphone (see Figure 7). The result of the process, which takes about 20 seconds, is that the cellphone then has the correct telephone numbers for all members of the calling circle.
Updating the cellphone address book.
This functionality can be compared broadly with the software distribution component of the existing ZENworks for Desktops software.
The GSM specification defines a mechanism for sending and receiving text messages to and from a mobile phone, known as the Short Message Service (SMS).
A text message may be sent to any user within NDS who has a cellphone, using either the administrator interface or an end-user interface of Mobile Phone Policy Manager. Both interfaces allow browsing for the NDS user or group object to which the message will be sent. Once the object has been selected, Mobile Phone Policy Manager looks up the cellphone object associated with the user, or users, and sends the SMS message to them.
The message is sent via the SMSGateWay software running on a NetWare server, or Windows 32 platform, anywhere within the network. SMS capability is available on virtually all GSM and PCS networks worldwide. Figure 8 shows how the administrator can use this option within NWAdmin.
Sending a text message from NWAdmin.
This is analogous to the SEND function for Novell NetWare, which allows a user or administrator to send messages to other computer users on the network.
As well as being able to send text messages from NDS to any cellphone user, any cellphone user may also send messages via e-mail to any NDS user using the Connectotel M-Mail system. Details of the public access M-Mail system, provided free of charge by Connectotel as a demonstration of this Mobile Phone Policy Manager feature, can be found at:
As at the time of writing (January 2001), M-Mail has more than 2000 active users worldwide, all registered within an NDS tree with Mobile Phone Policy Manager installed.
Once both user objects and cellphone objects exist in NDS, many additional applications become possible. Two of these, SIMSafe and SMSLogin, are described below.
As more and more data is stored on the cellphone, it becomes important to provide a means for backup of that data, in case the handset should be damaged, lost or stolen.
Typically a cellphone holds around 100 address book entries on the cellphone Subscriber Identity Module (SIM) card and may hold up to 1000 address book entries in the cellphones onboard memory. The SIMSafe software provides the user with the ability to backup or restore both the SIM memory and cellphone memory to a secure storage area within NDS.
SIMSafe is implemented as a browser plug-in for Netscape Navigator and MS Internet Explorer. To use the software, the user enters a username and password, connects the phone to the computer, then selects the option to back up or restore the cellphone address book. The address book contents are stored securely as an attribute of the User object within NDS.
As a side benefit, users may also edit their cellphone address book via the browser, even if they do not have access to their cellphone at the time. After making changes to the address book online, the user may connect the cellphone and use the SIMSafe restore feature to save the modified address book onto the cellphone.
SMSLogin (Patent Pending 9929291.4) allows authentication of any NDS user, using the cellphone as a security token. The authentication process can be summarised as follows:
The user connects to the Novell network.
The user switches on his/her cellphone (or it is already switched on) and enters the standard cellphone PIN (Personal Identification Number).
The Novell Client software prompts for the username and password of the user.
A Novell Client login snap-in module looks up the telephone number for the mobile phone or pager which is registered to the user.
A random "one-time use" PIN number is created by the login snap-in module.
The PIN number is sent as a "flash" (immediate display) text message to screen of the cellphone belonging to the user.
The user is prompted for the PIN which has been received at the cellphone.
The User enters the PIN into the dialogue box.
The login snap-in module compares the PIN entered at the computer keyboard with the PIN number which was sent to the cellphone.
If the entries match, the user is authenticated to the system.
By entering the PIN which has been received on the cellphone, the user has proved that he/she is the user holding the "security token."
It is hoped that this AppNote has shown how the business requirements described by customers have been satisfied. Mobile Phone Policy Manager meets the requirements as follows:
Asset Register. The administrator is able to relate cellphone objects to users and users to cellphone policies within NDS. The administrator is always able to know the cellphone which has been assigned to any user.
Zero Day Start. The administrator is able to define calling circles for new employees and is able to upload address books from the calling circle to the cellphone.
Policy-Based Management. The administrator may define and enforce policies for cellphone users, including SMS service centre, logos and ringtones. Policies are extensible so that new policies, such as for WAP configuration, can be added as required.
Messaging. An administrator or NDS user can send a text message to the cellphone of any user. Additionally, any cellphone user may send e-mail messages to any NDS user.
Thus, Mobile Phone Policy Manager offers organisations a solution for management of their cellphone devices via the existing NDS infrastructure. Furthermore, once Mobile Phone Policy Manager is in place, additional applications, which make use of the user/phone relationship can be implemented.
For further information about Mobile Phone Policy Manager, see the Connectotel home page at http://www.connectotel.com/ or e-mail Marcus Williamson at firstname.lastname@example.org.
* Originally published in Novell AppNotes
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.