SkyTel Wireless Network Developerâ€™s Reference Guide

SkyTel Wireless Network Developer’s Reference Guide

Edition 1.1

August 2005

SkyTel WIReleSSDeVelOPeR’S GUIDe

Version and Date

Notice

This document is published by SkyTel Wireless , L.P. without any warranty

whatsoever and is only made available for use by developers at their own risk.

SkyTel WIRELESS EXPRESSLY DISCLAIMS ALL WARRANTIES INCLUDING,

WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHATABILITY AND

FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY AGAINST

PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY INFRINGEMENT.

The document is copyrighted with all rights reserved. Your rights of ownership

are subject to the limitations and restrictions imposed by copyright laws. No

portion of this document may be copied, photocopied, reproduced, translated

or reduced to any electronic medium or machine form without prior consent

from SkyTel Wireless .

The information contained in this document alone is not sufficient for a

developer to produce a working product. The development of a working

product for use on the SkyTel Wireless Intelligent Wireless NetworkSM is a

complicated matter which requires knowledge and expertise not contained in

this document. This document is intended as supplemental information for the

experienced and trained communications system and application developer, and

radio equipment installer.

The correction of physical defects, typographical errors, inaccuracies of

current information, and the improvements to programs and/or equipment

in the document may be made solely by SkyTel Wireless at any time without

notice. Such changes will, however, be incorporated into future releases of the

document.

Trademark Notice

SkyTel Wireless is a service mark of SkyTel Wireless, LLC. SkyTel Wireless Intelligent

Wireless Network is a service mark of SkyTel Wireless , L.P. RIM and Research in

Motion are trademarks of Research in Motion Limited. All other trade names used

herein are trademarks of their respective companies.

© 2005 SkyTel Wireless , L.P. All Rights Reserved.

10 Woodbridge Center Drive Woodbridge, New Jersey 07095

Telephone: (732) 602-5500 Fax:

(732) 602-5285

http://www.SkyTelWireless.com

Printed in the United States of America.

Table of Contents1. Introduction 1Overview 1Purpose 1Audience 1Scope 1

2. Wireless Requirements 2Overview 2Geography 2Mobile Device 2Minimum Requirements 3Chat Application, A Symmetrical Model 4Modules . 4Chat Module 4MPAK Module 4MASC Module 4From Prototype to Production 5Benefits of a Client/Server Environment 6The Broker Paradigm How the Broker Paradigm Works 7Host Application Minimum Requirements 8Availability and Throughput 8In Summary 8

3. Network Overview and Features 93.1 System Overview 9 Introduction 9 Architecture 9 System Hierarchy 9 Base Stations 9 Local & Regional Switches 10 Message Switching 10 Network Control Centers 10 System Level Characteristics 11 RF Link Characteristics 113.2 Network Features 12 Overview 12 Transparent Roaming 12 Registration 13 Store-and-Forward 13 Group Broadcast 14 Closed User Groups (CUGs) 14 End-to-End Delivery Verification 14 POSACKs 14 NACKs 15 Battery Saving Protocol 15 Error Correction 16 Cyclic Redundancy Check 16 ROSI Protocol 16 Block Coding 16 Data Interleaving 18 MOBITEX Security 19 Subscription Security Features 20 Personal Subscriptions 21 MPAK Timestamp 21

Dynamic Routing 22

Continued on next page

Table of Contents, Continued3.3 Protocols 23 Overview 23 MPAK and MASC Protocols 23 MPAK Protocol 24 MASC Protocol 24 Transport Protocols 25

4. Mobile Application Design Guidelines 264.1 Overview 26 Introduction 26 Wireless Conditions 26 Notifying End-users of Wireless Conditions 264.2 Key Information for the Mobile User 27 RSSI 27 How to Assess the RSSI of a Radio Modem 27 Should End-users be Notified 27 Ways to Notify Users 27 Preventing Message Transmission 27 Roaming 28 Roaming Values 28 How Roaming Works 28 Should End-users be Notified 28 Battery Strength 29 How to Assess Battery Strength 29 Should End-users be Notified 29 How to Notify End-users 29 Prevention 29 Coverage 30 Out of Coverage 30 How to Assess when a Radio Modem is Out of Coverage 30 How to Assess when a Radio Modem is Back in Coverage 30 Polling the Radio Modem for Information 30 Inbound 31 Message Acknowledgment 314.3 Flow Control 32 B-Party Malfunction List 32 Quench State 32 Retry Algorithm 32 Message Sizing 33 Compression 33 Encryption 33 Network Notifications and Error Messages 33 User Errors 344.4 High-Level Application Flow Charts 35 Overview 35

5. Host Design Guidelines 375.1 Overview 37 Introduction 375.2 Retry Algorithms 38 Overview 38 Basic MOBITEX Host Retry Algorithm 38 Benefits for the Developer 39 Benefits for the Customer 39 Typical Host Retry Algorithm vs. Mailbox Enable Packet 41 Example 41 Mobile-Based Logic vs. Packet-Based Logic 42


Table of Contents, Continued5.3 Other Considerations 43 Overview 43 Host Retry Mechanisms 43 Non Time-Sensitive Messages 43 Time-Sensitive Messages 43 Method 1 44 Method 2 44 Host Pinging 45 Benefits 45 Disadvantages 45 Application(s) Most Aptly Suited for this Method 45 Receiver Ready Packet 45 Benefits 45 Disadvantages 45 Application(s) Most Aptly Suited for this Method 45 Hybrid - Host Pinging and Receiver Ready Packets 46 Benefits 46 Disadvantages 46 Application(s) Most Aptly Suited for this Method 46

6. Availability and Throughput 47Host Group Addressing Overview 47Implementation 47Process 47When a Failure Occurs 47Turning Node 48MPAKs 49Host Group Addressing 49Roaming Scenarios 50Impact on Applications 53Appendix A: MASC and MPAK Frames Reference Sheets A-1Protocols A-1MOBITEX Wireless Protocols A-1MPAKs A-2ASC Frames A-2ROSI Frames A-3Simple Messaging A-3Application Layer A-4Network Layer A-5Initializing the Radio Modem A-6Data Link Layer Initialization A-6Network Layer Synchronization A-7Startup Summary A-8Additional Information Frames A-9Sending Message Traffic A-10Receiving and Decoding Packets A-11MASC Layer Control Frames A-11ACK Frame A-11NACK Frame A-12RACK Frame A-12SENS Frame A-12SACK Frame A-12Error Messages A-12E-frame A-13FK-frame A-13


Table of Contents, ContinuedN-frame A-13R-frame A-13Error Codes A-14Information Frames and Other Packet Types A-15Additional MPAK Types A-16

A p p e n d i x B : S a m p l e T e s t P l a n B -1MASC Radio B-1MASC Radio Start-up Sequence B-1MASC Active Packet ESN Field B-1MASC Frames During Initialization B-2Radio Shutdown Sequence B-2MASC Fixed Terminal B-3MASC FST Start-up sequence B-3MASC Active Packet ESN Field B-3MASC Frames During Initialization B-3MASC FST Shutdown Sequence B-3MPAK X.25 B-4MPAK X.25 Configuration B-4MPAK X.25 Start-up sequence B-4MPAK X.25 Shutdown sequence B-4Communications Status B-4MASC MOX - Link Status B-4MPAK-X.25 MOX - Link Status B-4MASC Radio B-5Host Link Status B-5Host Coverage Status B-5Mobile Coverage Status B-5Mobile Link Status B-5Data Transfer B-5Message Transfer Type B-5Data Transfer using Terminal MAN B-5Minimum Message Size B-5Data Transfer using Terminal MAN Average Message Size B-5Data Transfer using Terminal MAN Maximum Message Size B-6Data Transfer using Group MAN B-6Data Transfer using Address List B-6Data Transfer using Emergency Messaging B-6Data Transfer using Personal MAN B-6Data Transfer using Positive ACK B-6Positive ACK, No Mailbox B-6Positive ACK, Mailbox B-7MOBITEX Traffic States B-7Host FROM_MAIL Traffic Condition B-7Mobile FROM_MAIL Traffic Condition B-7Host IN_MAIL Traffic Condition B-7Mobile IN_MAIL Traffic Condition B-8Host NO_TRANSFER Traffic Condition - No Mailbox Flag B-8Mobile NO _TRANSFER Traffic Condition - No Mailbox Flag B-8Host NO_TRANSFER Traffic Condition - Mailbox Flag Set B-8Mobile NO _TRANSFER Traffic Condition - Mailbox Flag Set B-8Host ILLEGAL Traffic Condition B-9Mobile ILLEGAL Traffic Condition B-9Host CONGEST Traffic Condition B-9Mobile CONGEST Traffic Condition B-9


Table of Contents, ContinuedHost ERROR Traffic Condition B-10

Mobile - ERROR B-10

Appendix C – MASC Frame Quick Reference C-1Appendix D – MPAK Frame Quick Reference D-1

List of FiguresFigure 2-1: Chat Application 5Figure 2-2: Example of a Client/Server Environment 6Figure 2-3: Broker Paradigm 7Figure 3-1: Core Network Architecture 10Figure 3-2: POSACK Flag Format 15Figure 3-3: ROSI Frames With Error Coding 17Figure 3-4: Error Correction Techniques 18Figure 3-5: Example of Dynamic Routing (HGA) 22Figure 3-6: ISO OSISeven Layer Model 23Figure 3-7: MPAK Structure 24Figure 3-8: MASC Frame Structure 24Figure 4-1: Receive Modules 35Figure 4-2: Send Modules 36Figure 5-1: Basic MOBITEX Host Retry Algorithm Process 40Figure 6-1: Host Group Addressing 48Figure 6-2: Multiple Host Connections 50Figure 6-3a: Roaming with Multiple Host Connections 51Figure 6-3b: Roaming with Multiple Host Connections 52Figure A-1: MASC and MPAK Protocol Relationship A-Figure A-2: MASC and MPAK Layer Frame Relationship A-2Figure A-3: Sample MOBITEX Application Screen A-3Figure A-4: MPAK structure A-4Figure A-5: B-Frame A-6Figure A-6: FP-Frame A-7Figure A-7: Radio Modem to Terminal Startup A-8Figure A-8: Additional Frames A-9Figure A-9: FH-Frame A-10Figure A-10: Link Layer ACKs and Network Acknowledgment A-10

List of TablesTable 3-1: Security Features 20Table 4-1: Traffic States 31Table 5-1: Retry Attempt Time Periods 41Table 5-2: Mobile-Based/Packet-Based Logic Comparison 42Table A-1: Creating a Text MPAK A-4Table A-2: Error Code Descriptions A-14Table A-3: Information Frames A-15Table A-4: PUSBCOM and DTESERV Classes A-16

1. Introduction

OverviewWelcome to SkyTel Wireless’ Developer’s Reference Guide. SkyTel Wireless has produced this document for Developers as a guideline of how to create both mobile and host application for use on the SkyTel Wireless Intelligent Wireless NetworkSM. SkyTel Wireless’s data network services provide significant differentiation from competitors’ offerings and a robust set of features including, but not limited to:

PurPOseThe purpose of this document is to provide a foundation and a set of guidelines for designing and developing an application that can pass proficiency testing for use on the SkyTel Wireless Intelligent Wireless Network. The document is structured to parallel the development life cycle (i.e., analyze, design, develop, and test). The contents include an anthology of white papers, specifications and guidelines developed by supporting technical organizations within SkyTel Wireless .

Audience This document should be used by developers who have an understanding of apacket-switched network.

scOPe This document describes the following information:

• Requirements that are imposed on applications that are operating in the wireless environment.

• High-level design strategies that work well in a wireless environment • Network architecture and features. • A basic understanding of the Core MOBITEX network. • Mobile device application guidelines and design strategies. • Host application guidelines and design strategies. • Strategies for scalability and reliability. • Development reference material (MASC and MPAK frames reference sheets) • A sample test plan.

2. Wireless Requirements

OverviewThe behavior of a wireless application is often determined by a number of factors, such as geography and the strength of the power source of the mobile device. This section details a number of these factors and ultimately defines requirements needed for an application to operate on the SkyTel Wireless Intelligent Wireless Network.

GeOGrAPhy The geography in which the mobile device is operating affects its behavior. These days, many people are familiar with some form of wireless communications and they are also familiar with a number of the geographical conditions, such as:

• Being out of coverage • Losing the signal when in a tunnel or basement • Encountering static from local interference sources • Roaming conditions.

On a cell phone, these conditions are immediately apparent since the audio clues associated with static and immediate loss of signal are familiar ones. However, with data communications, an application must provide the logic needed to handle these conditions.MOBITEX uses the MPAK protocol to manage traffic through the network. The applications network interface is responsible for correctly formatting MPAK headers sent into the network and for interpreting and acting upon MPAK headers received from the network. If a message cannot be delivered by the network, a packet is returned to the sender (A-party) with informational status bits set. The status of a returned packet indicates the state of the receiver (B-party). A wireless application must provide the logic necessary to handle these conditions. Typically, this is to give the user an option to retry or to wait a suitable timeout and automatically retry.

MObile device The mobile device introduces another set of constraints. By its nature, a mobile device has limited resources, requiring careful usage of code and data space. But it is the limited power source that presents a more challenging constraint. Mobile device users will quickly become frustrated if they are changing batteries daily.In a two-way network that guarantees a message delivery status, B-party must transmit an acknowledgement to the base station. Radio transmission represents the largest source of drain on the battery. This is unavoidable when the mobile is the A-party.

Current device technology and network features have made good progress to relieve(continued) this problem. However, a well-designed application is still the primary tool to address this issue. MOBITEX provides for a battery saving protocol that can be enabled under software control by the application. In addition, it is necessary for the application to ensure that it does not send multiple transmissions of the same packet to B-party as well as minimizing characters being sent from A-party. This minimizes the time the device is transmitting and, hence, minimizes battery drain, and reduces costs to the end-user.

Section 3 provides a detailed description all of the network features available, but there is one feature of the network that needs to be emphasized before discussion of high-level design strategies. MOBITEX is a reliable datagram delivery service. This means that A-party receives a notice when a message is not delivered. The network retries delivering a packet six times at 10-second intervals. If the network cannot deliver the message after the sixth retry, the packed is returned to the sender with an informational status code. The A-party can assume the message has been delivered after a suitable timeout greater than the 60-second timeout that occurs while the network performs its retries. The recommended timeout setting is 90 seconds because this allows a buffer to absorb delays that may arise during peak usage periods.

2. Wireless Requirements, ContinuedMiniMuM requireMents

Following is a set of minimum requirements that an application must implement to Requirements operate on the SkyTel Wireless Intelligent Wireless Network. • Uses a radio modem certified for use on the SkyTel Wireless Intelligent Wireless

Network. • Provides transmission of initialization sequence to radio on startup and when

recovering from a power failure or power level drops or spikes. • Provides transmission status information for each application level send. • Indicates in/out of coverage to the user. • Transmits active packet after extended period out of coverage. •Transmits inactive packet when going out of service. • Includes battery strength indication. • Implements timeouts greater than network retry. • Handles delivery status indicators in received MPAKs.

chAt APPlicAtiOn A syMetricAl MOdelTo look at a design model, take the application requirements listed above andcombine them with the MPAK protocol specifications.

EXAMPLE: Asimple chat application.The specification for this application consists of the following functions:

• Composing a message • Sending a message • Receiving a message • Reading a message.

When designing a portable application, you also need specifications to control the radio modem. MOBITEX certified modems all adhere to a protocol called MOBITEX Asynchronous Communications (MASC). This is specified as part of the overall MOBITEX specification. With this final piece, you can design the application. A diagram of a chat application is shown in Figure 2-1.

MOdules By layering the system into three modules, you can create a set of tools that can beused again and again.

• Chat Module • MPAK Module • MASC Module.

chAt MOdule The Chat module provides a primary user interface. Chat accepts messages that are input and displays messages and status information about messages that have been sent. An end-user is able to input the address in an address field on the message and can also choose to resend a message from a list of previously sent messages. Chat sends and receives messages by exchanging buffers with the MPAK module.

MPAK MOdule The MPAK module is responsible for formatting and interpreting the network transport protocol (MPAK). This module contains code to handle all delivery status indicators. Since the network deals only in datagrams up to 512 bytes, the MPAK module dissembles and assembles messages into packets. Finally, the MPAK module sends and receives packets by exchanging packets with the MASC module.

2. Wireless Requirements, Continued

MAsc MOduleThe MASC module sends and receives to the network through the radio modem. It implements a full MASC protocol so it periodically queries the radio for information about its connection to the network and displays coverage and power level information in a status bar.

By putting two of these systems on the network, you now have a simple peer-to-peer application that will function properly on the SkyTel Wireless Intelligent Wireless Network.

FrOM PrOtOtyPe tO PrOductiOnA chat application is useful for a workgroup as well as for a group of friends whowould like to stay in touch with each other. As the user community grows, the usersbegin to face the limitations inherent in portable mobile devices. For example, users inthis situation will use a battery a day because their devices are in constant use, andtheir typing speed is suppressed while the devices are sending data over the air.Sending messages to multiple recipients requires management for each messagetransmission. For larger messages the packets must be maintained in memory untilthey are sequenced properly. For a chat application to work effectively, developersmust create an application that performs the following functions:

• Manages a large number of users. • Logs usage activity for support and billing. • Controls user activity.

To meet these requirements, developers must not design an application for peer-topeerimplementation, but rather for a client/server implementation.

Figure 2-1: Chat application

2. Wireless Requirements, ContinuedFrOM PrOtOtyPe tO PrOductiOn, cOntinued

beneFits OF A client/server envirOnMentBy creating a client/server environment, developers can manage users and control Client/Server user activity from a single point. The wireless device no longer communicates directly with other users, thus eliminating multiple sending of the same message. Instead, the wireless device sends to and receives messages from one network address and the SMS Gateway server distributes the messages, as shown in Figure 2-2.

The Client/Server environment also eliminates potential coverage problems. Since theserver is directly connected to the SkyTel Wireless Intelligent Wireless Network, if anend-user sending a message is within the coverage area, he is always able to send amessage to the server, even if the recipient of the message is out of coverage. Theserver can provide a mailbox storage area for the recipient of the message, until here-enters the coverage area

the brOKer PArAdiGMTo provide additional services, the architecture of the server should be that of a three-tiered client server. The implementation of a middleware gateway server not only provides messaging services, but also provides brokering service for our mobile community to access other servers. The server manages communications with the wireless device and executes transactions on behalf of these mobiles. Please refer to Figure 2-3 for a diagram of this process.

Figure 2-2: Example of a Client/Server Enviroment

2. Wireless Requirements, Continuedthe brOKer PArAdiGM, cOntinued

nOte: Most successful services offered on the MOBITEX network today have this architecture.

hOw the brOKer PArAdiGM wOrKsA mobile user submits a request to the gateway, which then performs the followingBroker functions~ Breaks the request down into the component transactions.

• Adds the appropriate information from the user’s profile. • Submits transactions to the appropriate servers on the LAN • Compiles the return information into a message • Manages the delivery to the requesting mobile device.

A server like this can grow to a large capacity. Since it is directly linked to theSkyTel Wireless Intelligent Wireless Network, the throughput can be up to fivetimes that of the radio channel. In addition, the geographical influences, such asroaming, do not apply to the host connections. These factors require an adjustment ofthe minimum requirements laid out earlier in this section to account for the behavioraldifference inherent in the host side application. The requirements below apply to thehost side of a mobile application.

Figure 2-3: Broker Diagram

2. Wireless Requirements, Continued

hOst APPlicAtiOn MiniMuM requireMentsWhen creating a Host Application, it must adhere to the following criteria:~ Minimum time duration before first retry for a packet must be greater than 60 sec.

• Implements a progressively increasing retry timeout for mobiles that are unreachable.

• Does not send new packets to a mobile that is known to be unreachable. • Includes a timeout of not less than 90 seconds for packets sent to mobiles under

an application level acknowledgment implementation. • Includes status of Host Connection indicator that provides alert messages when the

connection is down. • Transmits initialization sequence when recovering from a power failure. • Handles delivery status indicators in received MPAKS.

AvAilAbility And thrOuGhPutAs the customer base grows, availability and network performance becomeincreasingly important issues that affect future growth and customer retention.

The SkyTel Wireless Intelligent Wireless Network offers a key feature to addressboth of these requirements, Host Group Addressing (HGA). HGA allows multiple hostconnections into the network to be addressed as a single address by the mobiledevices. There is no need to program additional addresses and failover capabilitiesinto the mobile devices. The network routes to the closest instance of an HGA,whether it is a few miles away, or across the country.

SkyTel Wireless Network Configuration Management implements a limit of 56 Kbpsfor any connection into a single switch in the network, which prevents any onecustomer from monopolizing a single switch. This restriction benefits the applicationbecause it requires developers to design in a way that address higher throughputlevels using an option that also provides for redundancy of connections to the server.

To complete the set of requirements for the host application, add the following: • A host managing more than 500 mobile devices must implement HGA.

in suMMAry If developers use the requirements outlined in this section, they can minimize the chance of being flow-controlled by the network. For additional information on networkflow control, please refer to Section 4.3, for mobiles, and Section 6 for Hosts.

3 . Ne twork Overview and Features3.1 SYSTEM OVERVIEW

intrOductiOnSkyTel Wireless ’s Core Network is a nationwide, digital, packet-data service thatcomprises land-based radio transceivers arrayed in a cellular-like grid and hierarchicalpacket switched facilities, all interconnected by digital transmission lines. The system isbased on Ericsson’s MOBITEX technology, which features nonproprietary interfaceson both the radio link and the host access link.

SkyTel Wireless ’s service objective is to provide a one-way packet transit time thataverages between five and seven seconds for maximum-sized packets (exclusive ofprocessing times in radio terminals and hosts), when the originator and the recipientare in satisfactory contact with the SkyTel Wireless Intelligent Wireless Network.

Architecture Radio base stations in the SkyTel Wireless Core Network are geographicallydistributed over a service area in much the same way as those in a cellular telephonesystem. Base stations are installed in a pattern that allows frequency reuse in nonadjoiningareas. This cellular layout, as compared to a single-channel simulcastsystem, provides extraordinary capacity and is easily expanded, when required, toprovide additional capacity. Unlike cellular telephone systems, however, the SkyTelWireless Intelligent Wireless Network is designed to provide a nationwide service andis optimized for data communications. Please refer to Figure 3-1: Core NetworkArchitecture for a visual representation of this layout.

systeM hierArchyThe SkyTel Wireless Core Network is connected through multiple hierarchicalswitching levels. Each level in the hierarchy contains packet switches with the ability todecide if a packet is locally deliverable or must be transferred to a higher-levelswitching node.

bAse stAtiOns At the first level in the hierarchy of the SkyTel Wireless Core Network are basestations, many of which operate on multiple radio channels simultaneously. Eachbase station also includes a packet switch that efficiently routes traffic betweensubscribers.

(Continued on the next page)

3 . Network Overview and Features3.1 SYSTEM OVERVIEW, CONTINUED

lOcAl & reGiOnAl switchesThe higher levels of the switching hierarchy consist of local switches and redundant regional switches, which are, in turn, interconnected via a redundant Frame Relay backbone. Developer host connections are accommodated at the local-switch level through a front-end processor (FEP) that supports protocol conversion as necessary.

MessAGe switchinGMessage switching is performed at the lowest network node common to the originator and recipient of the message. This distributed switching capability ensures fast response times and efficient message handling within the network.

netwOrK cOntrOl centersThe Network Control Centers (NCCs) are the focal point of both network administration and performance monitoring, which includes the collection and analysis of maintenance and traffic data from the network. The primary NCC is in Woodbridge, New Jersey and a secondary NCC is in Richardson, Texas. Each NCC is capable of handling all network management functions if the other NCC fails.

Figure 3-1: Core Network Architecture

3 . Network Overview and Features3.1 SYSTEM OVERVIEW, CONTINUED

systeM level chArActeristicsFollowing are a number of system level characteristics for your information:

base transmitter (mobile receiver) Frequency band – 935 to 940 MHzBase Receiver (mobile transmitter) Frequency Band – 896 to 901 MHz RFChannel Spacing – 12.5 kHzChannel Raw Data Rate – 8,000 bpsForward Error Correction – Hamming [12,8] code

Minimum Packet length – 11 bytes for the header, plus 1 byte of user data. Thispacket is 96 bits long; transmission duration is 37 ms.

Maximum Packet length – 512 bytes of user data. The total length is 7,256 bits,with a transmission duration of 0.907 s. If multiple addressing is used, the longestpacket is 7,736 bits, with a transmission duration of 0.967 s.

rF channel Access Protocol – A reservation-based slotted ALOHA algorithm isemployed. This access strategy has two important features:

• high channel efficiency – The use of reservations allows base stations to efficiently schedule inbound packets of various lengths without chance of collision.

• Flexibility – Channel can be tuned for various and changing traffic conditions.

rF linKMobile and Portable Radio Modem Transmitter Power – Maximum of 2 W (under characteristics automatic power control).

base transmitter Output Power – Up to 30 W (adjustable to change service areaand/or to provide link balance).

link balance – SkyTel Wireless base stations are configured with balancedinbound and outbound radio links between the base stations and the 2 W radiomodems. This characteristic ensures that if a mobile or portable unit can receive abase station’s signal, it is able to communicate to the base station with a high degree ofconfidence.

3 . Network Overview and Features3.2 NETWORK FEATURES

OverviewIn addition to its highly reliable datagram delivery service, the SkyTel Wirelesssolution offers several system-level features not generally available with competingtechnologies. These features include, but are not limited to:

• Transparent Roaming • Registration • Store-and-Forward • Group Broadcast • Closed User Groups (CUG) • End-to-End Delivery Verification • POSACKs • NACKs • Battery Saving Protocol • Error Correction • MOBITEX Security • Dynamic Routing

Following are summary descriptions of several key system features and associatedbenefits that would enhance the functionality and simplify the implementation ofapplications on the SkyTel Wireless Intelligent Wireless Network.

trAnsPArent rOAMinGThe transparent roaming function is inherent in MOBITEX compatible radio modems,which always select the best base station for communicating with the SkyTelWireless Core Network. There are two types of roaming, local and wide-area.Local Roaming – As a modem moves within a local area, it periodically monitors thesignal strength on adjacent base stations. When it detects a significantly better basestation signal, it registers with the new base station for service.Wide-Area Roaming – If a modem is switched off and transported (wide-area) toanother location, it reestablishes contact with the system by quickly searchingthrough SkyTel Wireless ’s national list of 200 channels until it finds and registers witha suitable base station.

(Continued on the next page)

3 . Network Overview and Features3.2 NETWORK FEATURES, CONTINUED

reGistrAtiOnRegistration performs two important functions:

1. The system is notified of the modem’s current location so that outbound packets are automatically routed to the mobile user.

2. The modem is always operating on the base station most able to ensure reliable communication.

The registration process is completely transparent to the mobile user and theapplication.

When compared with alternative approaches, SkyTel Wireless ’s solution toroaming has several significant advantages:

• Built Into All Radio Modems – Greater choice of suppliers. • Available In All Areas – Allows users to roam to any SkyTel Wireless

coverage area in the United States, using the same radio modem. • Faster – Ensures immediate packet delivery to any mobile in coverage. • More Efficient – Minimizes wasted packets sent to mobiles that have moved

since their last transmission to the SkyTel Wireless Intelligent Wireless Network.

• More Reliable – Each mobile unit makes decisions based on actual performance and not on assumed criteria.

stOre-And-FOrwArdSkyTel Wireless ’s Store-and-Forward feature allows applications to deal moreeffectively with radio modems that are temporarily out of coverage (e.g., in a tunnel, orsimply turned off). Each registered subscriber (terminal or personal subscription) hasstorage space allocated within the SkyTel Wireless Core Network for up to tenpackets. If a packet is undeliverable, it may, at the sender’s discretion, be stored in theSkyTel Wireless system for up to 72 hours. When the intended recipient’s radiomodem reestablishes contact with the system, it automatically registers with a localbase station; all packets stored in the system for that radio modem are then forwardedto the base station, and on to the unit.

Unique to SkyTel Wireless , this store-and-forward capability operates in SkyTelWireless coverage areas nationwide, regardless of distance or location, at noadditional cost. Potential uses for store-and-forward include:

• Coverage Smoothing – Allows applications to send messages to mobiles that are temporarily out of coverage. The sender never has to retransmit the message periodically until the mobile unit is back in coverage. Coverage need not be continuous to be effective.

• Wake-up Indication – A host application or dispatcher can post a store-andforward message (to be acknowledged when received) to a user’s application. The host application or dispatcher can then be notified when the unit goes into service.


GrOuP brOAdcAstThe SkyTel Wireless Core Network supports a unique group broadcast servicethat functions much like a paging service. This service allows transmission of amessage to all units belonging to the subject group and currently registered with one ofa predetermined set of base stations defined in the group subscription. Up to eightbase stations or host connections may be included in the group subscription (searcharea). All mobiles belonging to the subject group listen for messages addressed to thegroup subscription as they do for messages addressed to their individual terminalsubscription. Each base station defined in the group subscription transmits the groupmessage six times at ten-second intervals.

~ NOTE: Unlike other message types, the receiving mobiles on the radio link do notacknowledge group messages.

clOsed user GrOuPs (cuGs)SkyTel Wireless offers great flexibility in addressing traffic among network users.Developers may choose to restrict traffic by Closed User Groups (CUGs) that areadministered within the SkyTel Wireless Core Network. Users within a CUG have avirtual private network. They may neither send messages to nor receive messagesfrom users outside their group. However, the fact that individual users may belong tomultiple CUGs gives developers the flexibility to create groups with partial overlap. Forexample, field service and field sales personnel within the same organization mayeach belong to a separate CUG. At the same time, management personnel canintercommunicate by virtue of their own (third) overlapping CUG.

end-tO-end delivery veriFicAtiOnMOBITEX is a guaranteed delivery negative acknowledgement network. That is, adatagram that is undelivered for any reason is returned with an error status code setan unreturned datagram can be assumed delivered

POsAcKs This feature provides delivery confirmation of packets over the airlink to the sender’smodem or radio terminal. When the sending host or mobile enables the POSACKfeature, the base station serving the receiving party returns a POSACK packet once itreceives an airlink ack from the receiver.

~ NOTE: POSACK is an airlink only feature. A POSACK cannot be used to verify ahost connection.

A return receipt is generated only if the sending party enables the POSACK flag inthe MPAK. Setting the POSACK flag in the packet header causes the base station tosend a replica of the delivered packet back to the sender when the packet isdelivered to the intended radio modem. If the POSACK feature is invoked inconjunction with the network mailbox, a return receipt is sent when the message isdelivered from the mailbox to a radio terminal.


POsAcKs, cOntinuedFactors to consider when using this feature are:

• POSACK packets cannot be placed in the store-and-forward facility. • Returned POSACK packets are sent to the Network Control Center (NCC). • Undeliverable return receipts are discarded in the network. • POSACK packets are billed as status messages.

To use the POSACK feature, Developer applications must be configured to set thePOSACK flag in the MPAKs as well as interpret the POSACK packets received fromthe network. The POSACK flag format is shown in Figure 3-2: POSACK Flag Format.

nAcKs MOBITEX uses negative acknowledgments (NACKs) to return undeliverabledatagrams (packets).

bAttery sAvinG PrOtOcAlThe SkyTel Wireless Intelligent Wireless Network supports a battery saving protocolthat works with the radio modems to conserve battery power. Radio modems inbattery saving mode can sleep for a period of time (10 to 160 seconds) and wake upto check if there are any packets addressed to them. If the radio modem does nothear its MAN, it goes back to sleep and continues this process. However, if the radiomodem wakes up and hears its MAN, it will stay awake to receive the message fromthe network. The radio modem remains in the operational state for 12 seconds afterreceiving a message before going back into sleep mode.

Figure 3-2: POSACK Flag Format


errOr cOrrectiOnThe harsh radio environment requires error detection and correction schemes inCorrection order to insure extremely low error rates. The MOBITEX radio packet (maximum 512 bytes) is divided into blocks of 160 bits of data. Each byte of these 160 bits is encodedinto 240 bits of error correction Hamming Code that can correct one error in twelveconsecutive bits. These encoded bytes are then interleaved across the 30 bytes ofencoded data (containing 20 bytes of raw data). This process allows the code tocorrect up to 30 consecutive bit errors during slow fading conditions that are prevalentin the radio environment.

cyclic redundAncy checK In addition, if there are errors after the coding and scrambling, the CRC error check(Cyclic Redundancy Check) catches the error and the radio link employs automaticrepeat request algorithm to request the blocks received in error. If the repeat algorithmfails, the radio modem and the base station radio links automatically repeat thetransmissions up to a specified number of times before a packet is returned as afailure to the application. The application software can further improve reliability.

rOsi Protocol There are three methods incorporated into the ROSI protocol toensure that the probability of successful transmission through the radio link is99.999999%. The three error detection/correction methods used in the ROSIprotocol are:

1. Forward error correction (block coding) – Minimizes unnecessary retransmissions of messages caused by normal radio link error conditions.

2. data interleaving – Makes forward error correction more effective in recovering from fading conditions induced by normal mobile and portable activities.

3. Automatic repeat request – Signal Loss.

blOcK cOdinG Block coding is a sophisticated error detection method required for high data ratesystems. Blocks of data (primary and following blocks as defined by the ROSIprotocol) are followed by a block check character (BCC) that is defined by analgorithm. The same algorithm is used by the receiver to generate another BCCbased on the data received. If the two BCCs are identical, the data is correct.

The block check character used in the ROSI protocol is the Cyclic Redundancy Check(CRC). In the data link layer, the primary and following blocks are coded, the frameheader, introduced at the physical layer, is not. The CRC code detects all one and twobiterrors, and all bursts errors up to 16 bits in length.

Figure 3-3: ROSI Frames With Error Coding shows the CRC attached to primary andfollowing blocks of an M-frame in the data link layer.


blOcK cOdinG (continued)

In the physical layer, the primary and following blocks are further coded by adding fourparity bits to each byte. This brings the total size of a block to 240 bits. These addedbits are referred to as a shortened (12,8) Hamming Code and provide a means for thereceiver to perform forward error correcting. Figure 3-3: ROSI Frames with ErrorCoding illustrates the error-detection coding (shortened Hamming Code) attached toprimary and following blocks of a radio frame.

Also in the physical layer, a parity byte (2*4) is added to the radio frame header toprovide single bit-error correction. The first four bits correct the base ID and part of thearea ID. The second four bits correct the rest of the area ID and the control flags.Figure 3-3: ROSI Frames with Error Coding illustrates the parity coding attached tothe header of a radio frame.

Figure 3-2: ROSI Frames with Error Coding


dAtA interleAvinGRadio frame blocks (including the CRC and Hamming Codes) are interleaved beforethey are transmitted. Interleaving provides protection against burst errors (errorslonger than one bit). Without interleaving, the Hamming Code can correct onlysingle bit errors. After interleaving, a burst of up to 20 errors can be corrected.Interleaving is performed by sending all of the bit 0s of each byte in the blockfollowed by all the bit 1 s, and so on.

Finally, a scrambling sequence is used to generate a pseudo-random pattern of 1sand 0s. Scrambling is not a form of error correction but is used to ensure that theradio receiver remains locked to the center of the carrier frequency band (long bursts ofcontinuous 1s or 0s may cause the radio to drift). The scrambling sequence is alsoknown by the receiver’s radio modem to enable the message to be descrambled.Figure 3-4: Error Correction Techniques illustrates all the error correction techniquesincorporated in the ROSI protocol.

Figure 3-4: Error Correction Techniques


MObiteX securityMany mobile data Developers assume that all radio transmissions employ the samenarrow-band FM broadcasting technology. Although this technology is used inexisting wireless, voice-based communication systems (e.g., analog, cellularnetworks, and specialized mobile radio [SMR]), MOBITEX is quite different.

The Core MOBITEX Network uses advanced digital packet radio technology thatdistinguishes it from ordinary communications systems. The combination of digitaltechnology and packet data switching yields a high degree of inherent security thathelps to safeguard the privacy of user data. In addition, use of sophisticatedprotocols and radio modems significantly restricts unauthorized access to the CoreMOBITEX Network.

Although it is the only publicly accessible segment of the data path in a MOBITEXsystem, the airlink is usually not the most vulnerable segment of the communicationsnetwork. Receiving and transmitting data over the airlink in the Core MOBITEXNetwork is a complicated process. In fact, because of the technical expertise required,the use of various radio channels at various times by mobiles, and the sophisticatedscrambling and interleaving techniques employed in the over-the-air protocol, it mightbe easier to break into the user’s computer system rather than into the network itself.However, SkyTel Wireless recommends and supports the use of end-to-endencryption for all sensitive information.

The Core MOBITEX Network uses a Time Division Multiple Access (TDMA) methodwith a modified Slotted Aloha channel access algorithm. This unique channel accessalgorithm provides efficient channel utilization. Data is sent over the airlink in shortbursts at 8,000 bps using Gaussian Minimum Shift Keying (GMSK) modulation,encoded and interleaved for error correction, and then scrambled.

Messages in a MOBITEX system are made up of packets (called MPAKs) at thenetwork layer (OSI layer 3). In the radio modem, MPAKs are encapsulated fortransmission over the radio link by protocols at the data link (OSI 2) and physical (OSI1) layers. The data link layer of the radio modem performs the entire required baseband signal processing operations. The MPAKs are broken up into radio frames bythe radio modem. A frame header of 56 bits is generated and placed in front of eachradio frame. Data blocks consist of 20 bytes, each containing eight bits of datafollowed by four bits generated with a (12,8) Hamming Code. A radio frame has up to20 data blocks. In order to protect against burst error, interleaving is performed. Theinterleaving process can be viewed by imagining the data arranged as rows in a 12bits wide by 20 bits long matrix. The data is then sent column wise. Up to this point,the Hamming Code corrects single bit errors per byte and the interleaved code allowsa burst of 20 errors to be corrected. The data following the frame header is thenscrambled.

Scrambling provides a mechanism to achieve DC voltage balance by eliminatinglong sequences of ones and zeros in the data stream. The modem then performsthe GMSK modulation before applying the signal to the radio transceiver and ontothe appropriate radio channel. The receive operation is the exact reverse of thetransmit operation. Refer to Figure 3-4: Error Correction Techniques, for a pictorialview of this operation.


subscriPtiOn security FeAturesSeveral different subscription services can be linked to enhance data security. Refer to Table 3-1: Security Features for descriptions of these services and their role in the Core MOBITEX Network.

Figure 3-1: Security Features

SeCuRITy FeATuReS

MAN CHeCKING Every mobile and fixed terminal in the Core Mobitex Network is assigned a unique eight-digit, 24-bit Mobitex Access Number(MAN). The MAN is stored in electronically erasable,programmable, read-only memory (EEPROM) in the radiomodem, and can be changed only by authorizedSkyTel Wireless

eleCTRONIC SeRIAl

NuMBeR CHeCKING

A unique, 32-bit electronic serial number (ESN) is hard-codedinto each radio modem and is validated by the base stationwhen the device registers with the network. The ESN preventsuse of unauthorized radio modems and can facilitate thelocation and identification of stolen mobile equipment. If theMAN of a radio modem is altered, the Core Mobitex Networkwill detect such an alteration. For additional security, anencoded form of ESN is transmitted over the air by the radio modem. The Core Mobitex Network verifies that each MANmatches its ESN when a mobile radio tries to access the CoreMobitex Network. Any mismatch in numbers triggers an alert tothe Network Control Center (NCC), which sends a DIEcommand to the modem, rendering it inactive. The NCC usesDIE and LIVE commands to control Core Mobitex Networkaccess by mobile terminals. A Mobitex radio modem can bepermanently disabled by sending it a special command calleda “lethal injection.” A modem so disabled must be returned forservice before it will operate again.

PMAN In addition to the standard MAN, a personal Mobitex Access Number (PMAN) subscription provides additional data securityUsers with PMAN subscriptions have the additional benefit of a personal password, which must be sent to the Core Mobitex Network before access is granted

CuG SeRvICe Users who do not want entities or individuals outside their owngroup to communicate with them may subscribe to the CUG service. Within a CUG, subscribers can only receive messages from, or send messages to, subscribers of the same CUG. Thisservice keeps users from accidentally or intentionallytransferring messages to other network users. The CUG feature,in conjunction with the ESN feature, makes it difficult forunauthorized users to gain access tocustomer terminals andhost computers.

eND-TO-eND

DATA eNCRyPTION

Data encryption at the user’s application level provides thebest protection of user data. The application uses the sameencryption algorithm at both ends of the communication path,thus securing the entire path. Because the customer at theapplication level implements end-to-end encryption, datasecurity is administered and controlled solely by the customer.SkyTel Wireless suggests that customers assess theirindividual security needs and select the most suitableencryption algorithm for their purposes.


subscriPtiOn security FeAtures (continued)Table 3-1: Security Features lists many of the security measures inherent in the CoreMOBITEX Network and the wide selection of features available to enhance datasecurity. Each Developer must determine the level of data security needed.

SkyTel Wireless ’s security goal is two-fold:

• To protect Developer’s proprietary information. • To prevent unauthorized access to a Developer’s computer systems.

Any landline, which supports the use of the SkyTel Wireless Intelligent WirelessNetwork, has the same protection and safeguards as any other network provided bytelecommunications common carriers. Although it may be possible to monitor theradio portion of a transmission on the SkyTel Wireless Intelligent Wireless Network,interleaving, scrambling, coding, roaming, and the sheer volume of packets on a givenradio channel make detection and reconstruction of a particular message difficult.

PersOnAl subscriPtiOnsPersonal Subscriptions allow people to log into the network from any device orSubscriptions terminal and provides an extra level of security for applications. An application can use the login password information to determine who was involved in a particulartransaction. A personal subscription also gives users the flexibility of using differentterminals.

MPAK tiMestAMPThe MOBITEX Interface Specification (MIS) defines the protocols used within aMOBITEX network and is set by the MOBITEX Operators Association (MOA), agroup of approximately 18 operators of MOBITEX networks from around the world.SkyTel Wireless is a member of MOA. MOA’s policy is to maintain backwardcompatibility for the protocols and interfaces contained in the MIS.

Under the current MIS adopted by MOA, the time stamp field contained in theMOBITEX PAcKet (MPAK) protocol contains only three bytes and is given in minutesrelative to 1 January 1985. Thus, to obtain calendar time, an offset value must beapplied to the number represented in these bytes. A wrap to zero will occur in the year2016.

The time stamp is used primarily for network purposes and is not recommended orsupported for end-user applications. It is expected that users requiring time and dateinformation will elect to place time and date information within their data, utilizing themore precise clocks provided by their host processors and/or terminal equipment.


dynAMic rOutinGDynamic Routing, sometimes referred to as Host Group Addressing, is a network feature that allows multiple host connections to share a common MAN to provide host redundancy and/or load balancing. An example of Dynamic Routing is shown in Figure 3-5.

If it is anticipated that Dynamic Routing may be required in the future, the applicationshould be designed at the onset to support this function using the following guidelines:

• The mobile should use the Dynamic Routing MAN as the destination address in the first packet of the transaction, but must use the fixed address (FST) MAN as the destination for all subsequent packets in the transaction. The FST MAN is extracted from the host’s first outbound packet to the mobile device.

• The host must use the FST address being used in the sender address field ofthe MPAK to notify the mobile that host MAN should be used.

The mobile should use the FST MAN in all responses to packets from a DynamicRouting host.

Following these guidelines ensures that although a mobile could talk to any DynamicRouting host, the communication is maintained between a mobile and only one hostfor the duration of a transaction. It also ensures that all returned packets(undeliverable to the mobile) are directed back to the proper host.

Figure 3-5: Example of Dynamic Routing

3 . Network Overview and Features, Continued3.3 PROTOCOLS

OverviewThere are two protocols that need to be implemented in the mobile application toallow communication with the Core MOBITEX network. These protocols are:

• MPAK network layer protocol • MASC link layer protocol.

MPAK And MAsc PrOtOcOlsThe MPAK protocol formats the data packet into an addressed datagram that is sentthrough the network to its destination. The MPAK protocol also gives feedback if thepacket has difficulty reaching its destination.

The MASC protocol ensures there are no errors in the packet between the terminaland the radio modem. The diagram below shows the MPAK and MASC protocols asthey relate to Figure 3-6: ISO OSI Seven Layer Model.

Figure 3-6: ISO OSI Seven Layer Model

3 . Network Overview and Features, Continued3.2 NETWORK FEATURES, CONTINUED

MPAK PrOtOcOlThe MPAK network layer protocol is the only protocol in the Core MOBITEX Network that traverses the entire network. The MPAK protocol consists of seven components: the sender address, receiver address, traffic state, subscription flag,packet type, date/time, and the user data. The packet components are shown in Figure 3-7: MPAK Structure.

For more information on the MPAK protocol please refer to the Quick Reference Guide to Understanding MASC and MPAK Protocols and Ericsson’s MOBITEX Interface Specification.

MAsc PrOtOcOlMASC The MASC link layer protocol ensures the integrity of the packet between theProtocol application and the radio modem. The MASC protocol also has a set of commands to query information from the radio modem. The MASC frame consists of seven parts:

• Start character • Packet length • MASC frame definition • Start of data character • Data • Checksum • End of frame character.

The packet components are shown in Figure 3-8: MASC Frame Structure.

For more information on the MASC protocol, refer to The Quick Reference Guide toUnderstanding MASC and MPAK Protocols and Ericsson’s MOBITEX InterfaceSpecification.

trAnsPOrt PrOtOcOlsThe Core MOBITEX Network does not provide a transport protocol. Transport protocols provide end-to-end Acknowledgments and manage message assembly and disassembly for messages larger than 512 bytes. A transport protocol uses a mechanism called a Sliding Window Acknowledgment that allows the transport to adjust the number of packets sent before requiring an Acknowledgment (Ack) based on the reliability of the link. Therefore, if the transport has sent a few packets and has had no problem receiving the Acks for each packet, it may adjust the window to three packets per Ack. If the transport has to re-send packets, it may adjust the window down to one packet per required Ack.

In a connectionless, packet-switched network like the SkyTel Wireless Intelligent Wireless Network, it is possible for packets to reach a destination out of sequence. The transport layer of the application ensures that messages are reassembled in the proper order.

Figure 3-7: MPACK Structure

Figure 3-8: MASC Structure

4. Mobile Application Design Guidelines4.1 OVERVIEW

intrOductiOnThis section explains how a well-designed mobile application should handleconditions that are unique to wireless data communications such as signal strength,roaming, out-of-coverage, and battery strength. In addition, this document will explainsome of the features of the SkyTel Wireless Intelligent Wireless Network that youcan use to enhance a mobile application. This section is not considered to be aprogrammer’s guide or protocol reference. If you need detailed information of thattype, please refer to Ericsson’s MOBITEX Interface Specification or the QuickReference Guide to Understanding MASC and MPAK Protocols (also located inAppendix A).

wireless cOnditiOnsWireless conditions are items that can affect how quickly a message is sent acrossthe SkyTel Wireless Intelligent Wireless Network. The following types of wirelessconditions are discussed within this section of the document:

• RSSI • Roaming • Battery strength • Coverage • Polling the radio modem for information • Inbound message acknowledgment • B-party malfunction list • Message sizing • Compression • Encryption

nOtiFyinG endusers OF wireless cOnditiOnsWhile end-users do not need to know about the status of all wireless conditions at a given moment, they must know the status of certain conditions, such as when they are in or out of coverage, or what the level of battery strength is in their handheld device. There are several ways to alert end-users to these types of wireless conditions:

Place all the wireless condition indicators on the main form of an application.

nOte: If the screen size is small, it can be difficult to show all ofthe necessary indicators.

• Have a separate form or application area that the end-user can easily access from the main form.

• Create pop-up messages that result from generating a query, by pushing a specific button, or by selecting a menu item.

nOte: Regardless of which method of displaying wireless conditions best suitsthe application, status indicators should be included in the application design.Continued on next page

4. Mobile Application Design Guidelines, Continued4.2 KEY INFORMATION FOR THE MOBILE USER

rssiA MOBITEX radio modem has quite a bit of intelligence. The radio modem decideswhich base station to talk to based on the amount of radio signal it measures from allthe base stations it can hear. The radio modem constantly evaluates the signalstrength of all the base stations that it hears and connects to the base station with thebest radio signal strength. This signal strength is referred to as RSSI (Radio SignalStrength Indicator).

hOw tO Assess the rssi OF A rAdiO MOdeMThe RSSI of a radio modem can be obtained by using a command in the MASCProtocol (refer to the F A02 frame). This command should be used periodically topoll the radio modem and should return a value ranging from 0 to 50.

shOuld endusers be nOtiFiedRSSI information should be made available to end-users so they are aware if theyare in an area with good or poor coverage.

wAys tO nOtiFy usersThe RSSI information can be presented in numeric form, graphical form, or in aBoolean condition.

If the RSSI signal strength is displayed in numeric form, the value alone might not bemeaningful to users. Developers should consider combining the value with a colorcodingscheme or another graphical representation to make it easier for users tounderstand.

eXAMPle: If the background color or the color of the numeric value were tochange based on the signal strength, it would be easier for endusersto determine current coverage conditions at a glance. Forinstance, values 15 - 50 could be shown as green, values 6 - 14could be shown as yellow, and values 0 - 5 could be shown as red.

Using graphical displays of a series of bars or a graduated single bar are alsoeffective ways to show signal strength.

PreventinG MessAGe trAnsMissiOnThere are several things developers can do to prevent end-users from trying to sendinformation when coverage is insufficient. Developers can disable the send buttonwhen the coverage is below a certain threshold, or use a pop-up box that informs theuser that the signal strength is insufficient for communications. The pop-up boxshould disappear when good coverage is attained.

rOAMinGThe radio modem’s ability to choose different base stations based on RSSI is calledroaming. The radio modem does not roam based on signal strength alone. The radiomodem also listens for a frame identifying that the signal is from a SkyTel Wirelessbase station and not a signal from a paging tower or a vacuum cleaner. This paradigmis different from a cellular telephony network in which the base station decides when amobile is to be handed off to another base station.

4. Mobile Application Design Guidelines4.2 KEY INFORMATION FOR THE MOBILE USER

rOAMinG vAluesA radio modem does not roam from one base station to another the instant it receives a higher RSSI signal. Rather, a radio modem evaluates three roaming values it gets from the network:

hOw rOAMinG wOrKsA radio modem does not roam onto a base with a signal strength that is less than theBad_Base value. A radio modem roams to a base with a Good_Base value.However, a radio modem does not roam off of a base with a Good_Base valueunless it hears a base station with a signal strength equal to the RSSI of theCurrent_Base plus the Better_Base value. eXAMPle: If the Bad_Base is 3, the Good_Base is 5, the Better_Base is 6 and the Current_Base is 10, the user’s radio modem is on a base with good signal strength. If the radio modem hears a base with an RSSI of 12, it will not roam to that base. In order for the radio modem to roam it needs to have an RSSI equal to or greater than Current_Base plus Better_Base, which in this example would be an RSSI of at least 16 (Current_Base (10) + Better_Base (6)). This algorithm prevents the radio modem from constantly roaming back and forth between base stations. RSSI changes constantly when a user is moving and this algorithm keeps communication between the modem and the base station more stable.

shOuld end-users be nOtiFiedRoaming is a wireless condition that is transparent and is not reported to the end-user.

bAtttery strenGthMost wireless devices use batteries for power and radio modems are no exception. When the battery strength of a radio modem decreases, it becomes more difficult to transmit packets to the network. Transmitting information requires much more power than receiving information and battery strength in a radio modem is a condition that must be considered. The Core MOBITEX Network has features that help extend battery life of a radio modem. These features are described in Section 3 of this document.

hOw tO Assess bAtttery strenGthThe battery strength of a radio modem can be obtained by using a command in theMASC Protocol (refer to the F A03 Command). This command should be usedperiodically to poll the radio modem and should return a value ranging from 0 to 50.

rOAMinG vAlue descriPtiOn

bAd_bAse

GOOd_bAse

better_bAse

The lowest acceptable signal strength.

The signal strength necessary to accept a new base station as Current_Base.

The signal strength improvement required beforethe mobile switches from the Current_Base to anew base.


shOuld end-users be nOtiFiedEnd-users should be made aware of the battery strength of their handheld devices.

hOw tO nOtiFy end-usersLike the RSSI, developers should consider using a graphical display or color code scheme so users can quickly and easily determine battery strength.

PreventiOnThere are also several things developers can do to prevent users from using a radiomodem when the battery is almost dead. Developers can create an application thatshuts off the radio modem by using the MASC FO frame when a certain threshold ismet or use a pop-up box that informs the user that the battery needs to be replaced. In fact, a combination of these two techniques is an ideal way to manage this situation.

cOverAGeCoverage is the area served by a particular wireless network or base station.

Roaming occurs automatically based on the intelligence of the radio modem. When aradio modem roams from one base station to another, it does so seamlessly, meaning that the end user never knows it has occurred and data traffic is not affected. However, there are times when the signal strength becomes too low on the current base station and no other base station exists. This results in an out of coverage situation.

Out OF cOverAGeAn out-of-coverage condition occurs when the Current_Base signal strength goesbelow Bad_Base and no other base exists. At this point, the radio modem is nolonger connected to the network and no communication can take place.

While the radio modem is out of coverage, it scans through its list of frequenciestrying to find a base station. When the radio modem hears another base station withsufficient RSSI, it locks on to that base station and communication resumes.

hOw tO Assess when A rAdiO MOdeM is Out OF cOverAGeA radio modem that goes out of coverage sends a notification to the applicationusing the MASC FG frame. Developers should use this information the same way alow RSSI value is handled.

hOw tO Assess when A rAdiO MOdeM is bAcK in cOverAGeThe “in coverage” condition of the radio modem is sent from the radio modem to theapplication using a MASC FF frame. This command should be used in conjunctionwith the RSSI value to determine if communications should resume.

POllinG the rAdiO MOdeM FOr inFOrMAtiOnThe radio modem dynamically informs the application whether the radio modem is in orout of coverage. Most mobile applications periodically poll the radio modem for RSSI,battery strength, and, possibly, neighbor list information. The frequency and timeintervals of the polling need to be considered. SkyTel Wireless recommends that theinformation is polled at a rate no faster than 15-second intervals. If the polling intervalis faster than 15 seconds, the application spends much of its resources needlesslyand in some cases interferes with the ability to send messages. Constant polling mayalso drain the radio modem batteries.


inbOund MessAGe AcKnOwledGMentTo avoid potential network congestion and inefficient use of network resources,applications and/or their communications front ends need to incorporate appropriatelogic to deal with the various NACK (Negative ACKnowledgment) conditions on theCore MOBITEX network. NACKs consist of the sender’s original datagram with the“traffic state code” set as shown in Table 4-1: Traffic States.

With regard to mobile-to-host traffic, the mobile usually receives a NACK usuallywithin five seconds. Message retry by the sender should be delayed by at least twominutes after a NACK is received to avoid congesting the radio link.

table 4-1: Traffic States

cOnditiOn nAcK tyPe

in MAil

illeGAl

nO trAnsFer

errOr

cOnGest

Addressee is out of contact and MBOX Flag enabled

MPAK Header was improperly formatted

Addressee is out of contact and MBOX Full or Flag disabled

MPAK not deliverable due to communications failure in network

MPAK not deliverable due to congestion in one of the nodes

4. Mobile Application Design Guidelines, Continued4.3 FLOW CONTROL

b-PArty MAlFunctiOn listThe SkyTel Wireless Intelligent Wireless Network has a feature that protects itself and its subscribers from allowing mobile units to congest the network with too many message retries due to an unavailable host application or connection. All base stations maintain a list called the B-party Malfunction List (BML), which includes destination MANs (MOBITEX Address Numbers) that have produced congestion warning indications because of excessive undelivered and returned packets due to error, no transfers and congestion situations.

quench stAteThe base station acts as a proxy for the BML members and returns the packets to thesending MANs without having these packets traverse the network. The base stationalso periodically allows test packets to pass through the network in order to query theBML members to see if the situation has cleared. This testing cycle is called a quenchstate. The quench state begins when packets to the MAN in the BML are returned tothe sender with appropriate return flags. The base station starts with a 30 secondquench state and nearly doubles this time every time a test packet fails.In the current network configuration, the maximum time a terminal’s MAN can be in thequench state without a test packet being sent to it is one hour. A MAN is removedfrom the BML when a packet is successfully delivered to it.The sender’s application receives return packets with the same return flag as the lasttest packet sent to a member of the BML. For example, if the last test packet sent isreturned with a NO-TRANSFER flag, the subsequent packets are returned to themobile sender with the same flag. In addition, the base station adds an artificial transitdelay (10 seconds) to the returned packets, in order to simulate the round-trip timethrough the network and to delay the application level retries from the sending mobiles.

retry AlGOrithMIf a mobile retry algorithm is too aggressive, the Quench state is reset to its originalvalue. For this reason, the following mobile retry algorithm is recommended:

eXAMPle: Under normal conditions, a mobile should wait for at least two minutes to receive a NACK. If a NACK occurs, the mobile should wait at least two minutes, then try and retransmit. If the retransmission fails, the mobile should enter a back-off algorithm as such: two attempts with a waiting period of two minutes between subsequent failures, then two attempts waiting a period of five minutes, and then every ten minutes until achieving a successful transmission. Once a successful transmission occurs, the waiting period after a NACK can be reset to two minutes.

MessAGe siZinGMOBITEX packets have maximum lengths of 512 bytes and messages of this lengthprovide the highest transmission efficiency on the network under normal conditions.Under abnormal conditions, however, such as marginal coverage areas, shortermessages may have a better probability of getting through the radio link. Anapplication can affect performance by modifying packet length.

In addition, the outbound packet queue in each radio channel of a base station limits themaximum number of packets that can be buffered in this queue to 10 packets for asingle MAN. This limitation provides a fair allocation of the radio resources amongmultiple users by preventing a single MAN from seizing the entire radio channel for along period of time.

4. Mobile Application Design Guidelines, Continued4.3 FLOW CONTROL

cOMPressiOnThe application developer can choose any type of compression to help increase theefficiency of the application. A compression scheme should be considered forapplications that send multiple or large packets, because compression can increaseperceived throughput and decrease messaging costs. Only end-user data in thepacket can be compressed; the MPAK framing cannot be compressed. Transportfunctionality, especially packet sequencing, should not be compressed.

encryPtiOnAs with compression, the application developer may choose any type of encryptionmechanism to help ensure data security with the understanding that the MPAK headercannot be encrypted and the transport layer function should not be encrypted.Compression could be used as a simple form of encryption. SkyTel Wirelessrecommends that encryption be employed end-to-end in the application and not justover the air. The combination of end-to-end encryption and the network’s inherentsecurity capabilities provides a significant level of security to the user’s data on theSkyTel Wireless Intelligent Wireless Network, however, encryption is the best optionand is recommended for any sensitive data.

netwOrK nOtiFicAtiOns And errOr MessAGesMessages sent from a mobile device do not always reach their destination. There are several reasons a communications failure might occur, including operator error, device failure or temporary network problems. Although these problems do not occur often, the application should alert the end user to the problem.

There are several types of frames that can originate from either the SkyTel WirelessIntelligent Wireless Network or the radio modem. These frames alert the applicationto errors or conditions that prevent communications between the radio modem andthe SkyTel Wireless Intelligent Wireless Network. These frames (FK, N, and R)need to be handled by the application and the information needs to be communicatedclearly to end-users.

eXAMPle: An FK frame with an error code indicating that the radio modem returns the last packet sent because the radio modem’s transmit buffer is full. The end-user needs to be informed that the last packet he tried to send was not sent and is not buffered in the radio modem.

Accordingly, the application needs to perform one of the following two tasks. It must communicate to the end-user that the packet needs to be sent later, or it must store the packet until the radio modem buffer is not full SkyTel Wireless prefers the second solution.

In addition, the application should provide a means to prevent additional packets from being sent until the radio sends a message stating that the buffers are free and the current status should be communicated to the end-user.

4. Mobile Application Design Guidelines, Continued4.4 HIGH-LEVEL APPLICATION FLOW CHARTS

OverviewA mobile application should be ready to respond to the changing conditions of thewireless environment. A well-designed application is modular and the modules canbe altered as new features are added to the network or when additional features arerequired in the application. Sample flow charts of module functions for both receiveand send functions are included to help developers design an application.

Figure 4-1: Receive Modules

4. Mobile Application Design Guidelines, Continued4.4 HIGH-LEVEL APPLICATION FLOW CHARTS

OverviewA mobile application should be ready to respond to the changing conditions of thewireless environment. A well-designed application is modular and the modules canbe altered as new features are added to the network or when additional features arerequired in the application. Sample flow charts of module functions for both receiveand send functions are included to help developers design an application.

Figure 4-2: Send Modules

5. Host Design Guidelines5.1 OVERVIEW

intrOductiOnWhen designing a host for the SkyTel Wireless Intelligent Wireless Network, it is important to remember that the host is communicating with wireless mobiles that may not always be available. Wireless mobiles can go out of coverage for a variety of reasons. For instance, the mobile may enter an area that is affected by terrain, (i.e., passing under a bridge or entering into a valley of an area that is otherwise covered by a signal), or the mobile may temporarily go into an area that has little or no coverage.

The designer/developer of the host system cannot assume that the mobile is always available. Also, because a mobile may be unavailable for periods of minutes or hours, the host cannot try re-sending the message to the mobile at the same interval that the host would try to re-establish a connection on a wireline type of system.

In a wireline environment, there is a clear indicator of connectivity. With connectivity, allsenders and recipients are assumed to be available. In this environment, it is reasonable to queue outbound packets in a global queue that is set to deliver packets at a fixed interval. However, in a wireless environment, globally storing packets for delivery at a fixed interval can cause the host to be flow-controlled if the mobiles are out of coverage.

If the network detects a host that is sending undeliverable packets, it reduces the number of packets per second that the host can send. This prevents a malfunctioning host from monopolizing resources used by all of the other hosts.

A well-designed host manages communications to each mobile as individual links. A well-designed host provides handling for all of the different traffic states returned by MOBITEX on a mobile-to-mobile basis.

For a list of the different traffic states to which the host application must recognize and react, please refer to Table 4-1: Traffic States.

5. Host Design Guidelines Continued5.2 RETRY ALGORITHMS

OverviewRetry algorithms are generally complex procedures used to re-establishcommunications between a host and a client application when the client applicationdoes not acknowledge a message from the host. Retry algorithms consist of countersand timers. The counters track the number of attempts made to reestablishcommunications and the timers track the time that has elapsed since the last request.Most retry algorithms change the time interval between re-sending information byextending the amount of time that is allowed to elapse before the next retry. This isoften referred to as “backing off”. nOte: Due to the unique configuration of MOBITEX, the above retry algorithm is not appropriate for use on the Core MOBITEX Network. Alternative retry algorithm methods that increase efficiency by using the features of the MOBITEX network are discussed later on in this section.

bAsic MObiteX hOst retry AlGOrithMThis method uses a short, application-specific coded packet with the mailbox flag set toon and works as follows:

1. The host sends a packet to a mobile device.

2. The network cannot deliver the packet to the mobile because the mobile is out of coverage or not in service.

3. The network sends the packet back to the host as undelivered.

4. The host sends out an application-specific coded, mailbox-enabled packet to the mobile.

5. The network is unable to send the packet to the mobile.

6. The network stores the packet in the network mailbox and informs the host that the message is stored in the network mailbox.

7. The host begins to queue new messages for the out of service mobile.

8. Time elapses.

9. The mobile comes back into network coverage and receives the message that was placed in the mailbox.

10. The mobile application receives the code, which informs it to send an application-specific code to the host informing the host that the mobile is ready to receive messages.

11. The host receives the mobile’s message and sends the queued messages destined to the mobile.

For a visual depiction of this process, please refer to Figure 5-1: Basic MOBITEXHost Retry Algorithm Process.


beneFits FOr the develOPerThe Basic MOBITEX Host Retry Algorithm method provides advantages to thedeveloper. They are: • Less code to write • Faster to implement • Fewer computer resources wasted.

beneFits tO the custOMerThe advantages to the customer are:

• More reliable mechanism • Fewer computer resources wasted • Reduced development costs (less time to develop) • Provides the fastest response from the mobile when it is back in coverage (in most cases) • May reduce congestion on host • May reduce invoice • Will reduce overall network congestion (if many mobiles are out of service).

Figure 5-1: Basic MOBITEX Host Retry Algorithm Process

5. Host Design Guidelines, Continued5.2 RETRY ALGORITHMS

tyPicAl hOst retry vs. MAilbOX enAble PAcKetThe following example compares the Typical Host Retry method and the Mailbox Enable Packet method. This example provides a better explanation of how the Algorithm typical Host Retry algorithm is not ideally suited for use with the Core MOBITEX Network.

eXAMPle: A company with a fleet of 1000 mobile users implements a typical host retry algorithm. Assume 10 percent (100 mobiles) are out of service and the host has an average of 3 messages per out-of-coverage mobile. The host retry algorithm is configured to wait for a specified amount of time between additional attempts to send the message. To observe these time periods, refer to Table 5-1: Retry Attempt Time Periods:

Based on these time frames, the following situation occurs:

The retry algorithm’s intelligence level determines if the host has 100 counters and 100 timers running or 300 counters and 300 timers, depending on whether the focus is mobile-based or packet/message-based. Potentially, if a table or list is used in the application, there is only one timer and one counter, but then the table would have to be scanned every 10 or 15 seconds. This could become resource intensive if there are a large number of entries in the table.

There is another problem with this scenario. If all the mobiles come back into coverage 19 minutes and 30 seconds after the host’s first attempt send a message, each mobile then has to wait another 18 minutes and 30 seconds to receive messages because the next attempt will not occur for 20 minutes.

nuMber OF Minutes between AtteMPts retry AtteMPt nuMber

1

3

2

4

every AtteMPt AFter

2

5

2

10

20

Figure 5-1: Retry Attempt Time Periods


MObile-bAsed lOGic vs. PAcKet-bAsed lOGicTable 5-2: Mobile-Based/Packet-Based Logic Comparison shows the averagenumber of packets sent per minute using mobile-based logic and using packetbasedlogic, during the first hour after 19.5 minutes have elapsed from the host’sfirst attempt:

If the preferred method suggested in this document were used, only 100 shortmailboxed packets would be sent. In addition, the mobiles would respond 19minutes and 30 seconds faster without having to use the resources of at least 100timers and counters or having to scan one table.

If the preferred method suggested in this document were used, only 100 shortmailboxed packets would be sent. In addition, the mobiles would respond 19minutes and 30 seconds faster without having to use the resources of at least 100timers and counters or having to scan one table.

Figure 5-1: Basic MOBITEX Host Retry Algorithm Process

PAcKets Per MinuteusinG PAcKet-bAsed

lOGic

PAcKets Per Minute usinGMObile-bAsed

lOGic Minutes

2 300

(roughly 13 packets per minute) (roughly 38 packets per minute)

5 300

2 300

10 300

20 300

500 1500

100

100

100

100

100

500

5. Host Design Guidelines Continued5.3 OTHER CONSIDERATIONS

OverviewThe network mailbox holds mailboxed packets for only 72 hours and this must betaken into account when creating an efficient application design. Several methodsare defined within this section for handling information that is time-sensitive andinformation that is not time-sensitive.

hOst retry MechAnisMsThe following list shows the recommended methods that the host should use to re-Mechanisms establish communications with an unavailable mobile: • Host Retry Algorithms • Mailbox Enable Packets

There are also alternative methods that the host may use depending on which host application is being used. These methods are: • Host Pinging • Receiver Ready Packets • Hybrid (Host Pinging and Receiver Ready Packets)

All of the aforementioned methods are described in further detail within this section ofthe document.

nOn tiMe-sensitive MessAGesIf the information stored in the host for the mobile never expires, then anotherapplication-specific, mailboxed packet should be sent to the mobile before the 72-hour hold period expires. This means that additional logic is needed in the hostapplication. The host should make a simple table that includes the identifier for themobile, plus a time stamp from the network message noting that the packet wasplaced in the mailbox. The table should be scanned periodically to determine wheneach packet expires and if expiration is set to occur before the next sweep. If thepacket is going to expire before the next sweep through the table, then anotherapplication-specific, mailbox-enabled packet should be sent to the mobile. The oldrecord should be deleted or marked expired from the current list and the new recordshould be recorded in the table.

tiMe-sensitive MessAGesSome messages are more time-sensitive than others. For example, in a dispatchapplication, a mobile might need to respond within a specified period of time or themessage must be sent to another mobile for action. When messages are timesensitive,some additional logic needs to be implemented in the host. Following aredescriptions of two types of message retry methods.

Method 1: If the messages are time-sensitive and all the logic is on the host side, there is asimple method to handle retries. After the first message from the host is sent back from the network as undelivered, an application-specific, coded message with the mailbox flag enabled is sent to the mobile. If the mobile is still out of service, the message is placed in the mailbox. The code in the message placed in the mailbox tells the mobile application to respond to the host when it receives the mailboxed message.


The host makes a table of outstanding mailboxed messages that includes the timestamp of when the messages were sent. When the host determines that the time hasexpired for a particular message, the host first marks the mobile as temporarily out ofservice, then it deletes the record from the outstanding message queue. The hostthen either automatically or manually reassigns the message from the original mobileto a mobile that is still marked as in service. Because the original mobile is marked astemporarily out of service, it does not receive any cancellation message, nor does itreceive any additional messages from the host.When the out of service mobile sends a response to the original mailboxed messagefrom the host, the host then marks the mobile as back in service. New messages cannow be sent to the mobile because it is in service.

Method 2 In this method, the host sends an application-specific, coded message with the mailboxflag enabled where the code in the packet cancels the first request. It is also helpful tohave a message ID that is the same in both mailboxed packets. Additionally, themobile application should wait 30 seconds before responding to the first request sothat the application can receive the cancel request prior to acting on the first request.The host would have a simple table that tracks each mobile, message ID, and thetime stamp indicating when the message was sent. This list would have to bereviewed by the host periodically. When the set time has expired, the host wouldsend a cancel packet with the mailbox flag enabled and mark the mobile astemporarily out of service.

hOst PinGinGHost Pinging is one alternative method. With this method, the host sends out anapplication level packet to the mobile periodically to ensure the mobile is in contactwith the network and is reachable by the host. The host may or may not actuallyhave traffic for the mobile. The host wants to ensure if there is traffic to send it issent to a mobile that is immediately reachable by the host. The host may mark amobile as temporarily out-of-service if the ping is not received by the mobile.

beneFitsIf information being sent out is critical and must be received by a mobile, then thismethod could apply.

disAdvAntAGesThe ping messages are billable and could be costly depending on the size of themobile fleet and the frequency that the pings are sent.

APPlicAtiOns MOst APtly suited FOr this MethOdEmergency Service Dispatch and any other application where knowing the instant availability of the mobile is imperative.

reciever reAdy PAcKetThis is similar to the host ping; however, it is sent by the mobile. The mobile sends amessage to the host every time it comes back into coverage after losing coverage.

beneFitsThe host will know that the mobile has re-entered coverage.


disAdvAntAGesThe mobile can never send a message stating that it is out-of-coverage. If a mobile istraveling in a fringe area of coverage it could lose coverage shortly after sending amessage to the host stating that it is in coverage. If the customer has a large fleet witha large portion of the fleet going through areas of non-coverage this could be costly..

APPlicAtiOns MOst APtly suited FOr this MethOdEmergency Service Dispatch and any other application where knowing the instantMost Aptly availability of the mobile is imperative.



hybrid - hOst PinGinG And reciever reAdy PAcKetsA hybrid combination of Host Pinging and Mobile Receiver Ready packets is also an option. In this method the host sends out application pings. If the ping is not acknowledged by the mobile, the host marks the mobile as temporarily out-ofservice. The host does not have to send any more pings after the host marks the mobile temporarily out-of-service nor will any messages be sent or queued for it. When the mobile comes back into coverage it sends an application layer packet informing the host that the mobile should be placed back in service. The host then periodically pings the mobile until the mobile does not acknowledge the ping. The cycle then repeats.

beneFitsThe host does not have to ping a mobile that it has marked temporarily out-of service.

disAdvAntAGesThe number of packets sent from both the host and the mobile can be costly.

APPlicAtiOns MOst APtly suited FOr this MethOdThis application is best suited for emergency service dispatch and any other application where knowing the instant availability of the mobile is imperative.

hOst GrOuP AddressinG OverviewThe SkyTel Wireless Intelligent Wireless Network has a Host Fail Over/Redundancy Option called Host Group Addressing. The Host Group Address (HGA) function allows a developer’s host or gateway to have several access points to the SkyTel Wireless Intelligent Wireless Network. With the implementation of HGA, developers can build redundancy in their host connection to SkyTel Wireless to provide for increased reliability and capacity.

iMPleMentAtiOnHGA is a powerful function that should be implemented in the initialapplication design for optimum use. Although HGA can be added at a later date,retrofitting it into an existing design and deploying it to an existing fleet of users may bedifficult and costly. In addition, some functionality may be limited. Users of this featurecan either make a single physical connection with an HGA on the SkyTel WirelessIntelligent Wireless Network, or deploy multiple host connections, each to a differentHGA port. In either case, not all connections need to be active simultaneously.


PrOcessHost Group Address allows multiple connections from a host to share another commonMAN (referred to as an HGA MAN) to provide host redundancy and/or load balancing.

A host connection to SkyTel Wireless is assigned a single unique MOBITEX AccessNumber (MAN). Mobile devices send data to this host using the MAN as the destinationaddress. Conversely, a host sends data to the mobile(s) using the specific address(MAN) of the mobile device. Depending upon the physical connections of the host(s) tothe SkyTel Wireless Intelligent Wireless Network, traffic is dynamically routed betweenthese multiple connections.

when A FAilure OccursIn the event that one of the connections is lost, all traffic is routed to the remainingactive connections. The SkyTel Wireless Intelligent Wireless Network monitors thetraffic state to determine if a connection is lost. When a failure occurs, one or morepackets are returned with a traffic state of No Transfer. This triggers the network to reroutethe traffic to another host operating under the same HGA MAN.

As shown in Figure 6-1: Host Group Addressing, Host Connection 1 and HostConnection 2 are connected to the same Local Switch operating under the same HostGroup Address. The mobile device sends traffic to the host using the HGA MAN. If bothconnections are active, the traffic is routed to the connections basically in an alternatingfashion. In the event a host connection is lost due to a scheduled maintenance or failure,the remaining host receives all traffic, once the failure condition is detected by thenetwork.



6. Availability and ThroughputhOst GrOuP AddressinG Overview

When designing a host for the SkyTel Wireless Intelligent Wireless Network, it is important to remember that the host is communicating with wireless mobiles that may not always be available. Wireless mobiles can go out of coverage for a variety of reasons. For instance, the mobile may enter an area that is affected by terrain, (i.e., passing under a bridge or entering into a valley of an area that is otherwise covered by a signal), or the mobile may temporarily go into an area that has little or no coverage.

iMPleMentAtiOnHGA is a powerful function that should be implemented in the initial application design for optimum use. Although HGA can be added at a later date,retrofitting it into an existing design and deploying it to an existing fleet of users may be difficult and costly. In addition, some functionality may be limited. Users of this feature can either make a single physical connection with an HGA on the SkyTel Wireless Intelligent Wireless Network, or deploy multiple host connections, each to a different HGA port. In either case, not all connections need to be active simultaneously.

PrOcessHost Group Address allows multiple connections from a host to share another commonMAN (referred to as an HGA MAN) to provide host redundancy and/or load balancing.A host connection to SkyTel Wireless is assigned a single unique MOBITEX AccessNumber (MAN). Mobile devices send data to this host using the MAN as the destinationaddress. Conversely, a host sends data to the mobile(s) using the specific address(MAN) of the mobile device. Depending upon the physical connections of the host(s) tothe SkyTel Wireless Intelligent Wireless Network, traffic is dynamically routed betweenthese multiple connections.

when A FAilure OccursIn the event that one of the connections is lost, all traffic is routed to the remaining active connections. The SkyTel Wireless Intelligent Wireless Network monitors the traffic state to determine if a connection is lost. When a failure occurs, one or more packets are returned with a traffic state of No Transfer. This triggers the network to reroute the traffic to another host operating under the same HGA MAN.

As shown in Figure 6-1: Host Group Addressing, Host Connection 1 and Host Connection 2 are connected to the same Local Switch operating under the same Host Group Address. The mobile device sends traffic to the host using the HGA MAN. If both connections are active, the traffic is routed to the connections basically in an alternating fashion. In the event a host connection is lost due to a scheduled maintenance or failure, the remaining host receives all traffic, once the failure condition is detected by the network.

6. Availability and Throughput, ContinuedhOst GrOuP AddressinG Overview

When designing a host for the SkyTel Wireless Intelligent Wireless Network, it is important to remember that the host is communicating with wireless mobiles that may not always be available. Wireless mobiles can go out of coverage for a variety of reasons. For instance, the mobile may enter an area that is affected by terrain, (i.e., passing under a bridge or entering into a valley of an area that is otherwise covered by a signal), or the mobile may temporarily go into an area that has little or no coverage.

iMPleMentAtiOnHGA is a powerful function that should be implemented in the initial application design for optimum use. Although HGA can be added at a later date,retrofitting it into an existing design and deploying it to an existing fleet of users may be difficult and costly. In addition, some functionality may be limited. Users of this feature can either make a single physical connection with an HGA on the SkyTel Wireless Intelligent Wireless Network, or deploy multiple host connections, each to a different HGA port. In either case, not all connections need to be active simultaneously.

PrOcessHost Group Address allows multiple connections from a host to share another commonMAN (referred to as an HGA MAN) to provide host redundancy and/or load balancing.A host connection to SkyTel Wireless is assigned a single unique MOBITEX AccessNumber (MAN). Mobile devices send data to this host using the MAN as the destinationaddress. Conversely, a host sends data to the mobile(s) using the specific address(MAN) of the mobile device. Depending upon the physical connections of the host(s) tothe SkyTel Wireless Intelligent Wireless Network, traffic is dynamically routed betweenthese multiple connections.

when A FAilure OccursIn the event that one of the connections is lost, all traffic is routed to the remaining active connections. The SkyTel Wireless Intelligent Wireless Network monitors the traffic state to determine if a connection is lost. When a failure occurs, one or more packets are returned with a traffic state of No Transfer. This triggers the network to reroute the traffic to another host operating under the same HGA MAN.

As shown in Figure 6-1: Host Group Addressing, Host Connection 1 and Host Connection 2 are connected to the same Local Switch operating under the same Host Group Address. The mobile device sends traffic to the host using the HGA MAN. If both connections are active, the traffic is routed to the connections basically in an alternating fashion. In the event a host connection is lost due to a scheduled maintenance or failure, the remaining host receives all traffic, once the failure condition is detected by the network.

6. Availability and Throughput, Continued

when A FAilure Occurs, cOntinued

turninG nOdeIn its simplest form, Host Group Address is an alias. No more than eight instances of theHGA alias can exist in a single network branch. When a mobile device sends data usingan HGA MAN, the packet is passed upward in the network hierarchy until the packetreaches a switch within a branch that contains one or more HGA connections. Thisswitch is called the turning node.

If the turning node contains only one HGA, the packet is sent to it. If the turning nodecontains two or more HGA connections, then all packets arriving at that switch arerouted in a round robin fashion to all of the turning node HGA connections in an effort todistribute the load among them. This same routing strategy applies to positive andnegative acknowledgment packets returned to an HGA. If a mobile must communicatewith a specific location, it should address the messages to the unique terminal MANassociated with the host at that particular location.

nOte: Other routing algorithms may be used in the future. No assumption should bemade relative to predictability or precise load balancing of traffic.

Figure 6-1: Host Group Addressing


MPAKsMOBITEX is a packet-switched network and, as such, user data is encapsulated intopackets with user data of up to 512 bytes in length. A packet, regardless of size, isreferred to as a MOBITEX PAcKet (MPAK). Each MPAK presented to the networkcontains a destination and origination MOBITEX Address Number (MAN). Mostmessages are short and can be typically contained within a single packet. However insome applications, the amount of data being sent exceeds a single packet. In theseinstances, the message will be broken into multiple packets.

hOst GrOuP AddressinGAs shown in Figure 6-1: Host Group Addressing, two hosts are physically connected toAddressing the same location using Host Group Addressing. A mobile device sends a singlemessage that is approximately 1024 bytes in length. The message is sent across theSkyTel Wireless Intelligent Wireless Network as two 512-byte packets. The first packetmay be sent to Host Connection 1 and the second packet may be sent to HostConnection 2. Assuming that the two connections represent two separate systems thatare unable to synchronize these packets, given that a portion of the message is resident ateach host connection, neither is capable of deciphering the message. Therefore, theindividual message fragment results in abnormal handling conditions, or appears as ifpart of the message was lost. This same scenario can also occur even when the hostconnections are on two different local switches.

To eliminate occurrences of this type, the mobile should use the HGA MAN as thedestination address in the first packet transmission. Subsequent packets should then beaddressed using the physical FST MAN that should be obtained from the host’sresponse to the mobile. This will ensure that communication can be established with anyone of the HGA hosts, providing the desired redundancy and capacity benefits, whileproviding session integrity for the duration of a session. This will also ensure that anyreturned packets are directed to the proper host.

As illustrated in Figure 6-2: Multiple Host Connections, the mobile sends a packet usingan HGA. The base receiving the packet routes the packet to Local Switch 1. In thisinstance, Host Connection 1 is known to Local Switch 1 and the packet is routed to Host1. No additional routing through the network hierarchy is required.

However, if Host Connection 1 were unavailable, the packet would be routed throughthe hierarchy to a point where the other host would be known. As can be seen in Figure6-2: Multiple Host Connections, the packet would be routed to the National Switch anddirected to Host Connection 2, since it is at this point in the network that Host 2 isknown. Keep in mind that even though there are two distinct physical connections todifferent local switches, the hosts may physically reside in the same location. Thedifference between the two is the point-of-presence that is known to the networkhierarchy.


rOAMinG scenAriOsFigures 6-3a: Roaming with Multiple Host Connections and 6-3b: Host Connections illustrate the possible scenarios during roaming. In Figure 6-3a: Roaming with Multiple Host Connections, the mobile has roamed to a new base station that is configured to a different local switch. Local Switch 2 does not have a host connection, nor is it aware of any physical connection. When the mobile sends a packet using HGA, the packet is routed through the network hierarchy to search for an HGA host. In this example, HGA Host 1 is known at Regional Switch 1. The packet is then routed to Host connection 1 via Local Switch 1. All subsequent traffic from the mobile, providing it stays in the same coverage area, is automatically routed to Host 1.

Figure 6-2: Multiple Host Connections

Figure 6-3a: Roaming with Multiple Host Connections


rOAMinG scenAriOs, cOntinuedThis configuration is extremely effective for many mobile applications that may roam fromarea to area. By having multiple points-of-presence, traffic is dynamically routed to thehosts providing more efficient load balancing. For example, the mobile in Figure 6-3b:Roaming with Multiple Host Connections is equidistant between Host Connections 1 and 2;therefore, traffic is dynamically routed to alternating hosts, depending upon the session,thus providing better load balancing to the host systems. As the mobile moves closer toHost Connection 2, traffic is then routed to Host 2. As always, in the event either host isunavailable, all traffic is routed to the closest known host, or the next available host.

The network automatically detects if a connection to a host (fixed terminal) is unavailable. The Host Group at the unavailable fixed terminal is inactivated. Once the failure is detected, packets addressed to the Host Group are routed to another active member of the same Host Group Address. For example, Host Connection 1, as depicted in Figure 6-3b, is unavailable. The network may initially return some packets, which were addressed for Host Connection 1, to the sender. Once the network has detected that Host Connection 1 is lost, all subsequent traffic is routed to an available Host Group. In this case, traffic would be routed to the host connection configured under Local Switch 4. When the connection to the host is re-established, the communication software notifies the network and normal operation resumes.

Figure 6-3b: Roaming with Multiple Host Connections


iMPAct On APPlicAtiOnsAs previously stated, HGA is a powerful function that should be implemented in theinitial application design. Although HGA can be added at a later date, retrofitting it intoan existing design and deploying it to an existing fleet of users may be difficult andcostly.

Existing applications can be modified to use a new HGA in place of the FST address atboth ends, or the physical FST MAN can be modified in SkyTel Wireless ’s CustomerAccount Management system to become an HGA. If the modification is made in SkyTelWireless ’s system a new physical FST MAN must be created. SkyTel Wirelessrecommends that the modification is made to the application, where possible, to supportthe change of address.

For applications that involve a single host, minor modifications may be necessary toaccommodate Host Group Addressing. The inbound packet should be addressed to theHGA MAN and the outbound packets could use either the physical FST MAN or the HGAMAN in the sender address field. Although the effect is the same, the physical FSTaddress (MAN) is recommended if multiple hosts are deployed.

o get the best performance, the host should send packets to the mobile terminalsusing the same port/line/virtual circuit as did packets from the mobile. A tableassociating each mobile with the last known port/line/virtual circuit would accomplishthis and permit the shortest path routing even in the outbound direction.

Appendix A: MASC and MPAK Frames Reference Sheets

PrOtOcOlsAll MOBITEX networks support the MASC and MPAK protocols. The MPAK(MOBITEX PAcKet) network protocol is used to route user data through the system.The MASC (MOBITEX Asynchronous Communications) protocol is used tocommunicate between a radio modem and a terminal device. These protocolsconform to the OSI seven-layer model. Figure A-1: MASC and MPAK ProtocolRelationship shows the relationship between the protocols used on a MOBITEXsystem when communicating between a terminal and a base station.

Higher-level protocols (network independent, layers 4 through 7) can be overlaid byuser applications. These protocols include transport, session, presentation, andapplication layers and are used by applications to define how the data is handledafter it is received. These protocols may be contained in the MPAK and enableapplication designers to control data after it is received from the MOBITEX system.

MObiteX wireless PrOtOcOlsApplications designed to interface with the MOBITEX networks may use manyWireless protocols. This document discusses the two protocols that are required forProtocols interfacing between a terminal and a standard MASC radio modem. From thebottom of the OSI stack up they are: the MASC protocol (link layer) and the MPAKprotocol (network layer). The physical layer, RS-232 is not covered in thisdocument. Details about the RS-232 layer can be found in the MOBITEX InterfaceSpecification (MIS), available from Ericsson. In addition to supplying routing andcommunications interfaces, protocols used on a MOBITEX system provideinformation, such as, Is the radio modem in coverage? or What is the radio signalstrength? This information is necessary because MOBITEX systems use radiowaves to communicate (as opposed to wires).

Figure A-1: MASC and MPAK Protocol Relationship

Appendix A: MASC and MPAK Frames Reference Sheets, Continued

MPAKsAll messages are sent through the MOBITEX system in packets, called MPAKs, thatcontain user data of up to 512 bytes, coded as ASCII text or transparent data. EachMPAK contains addressing information, network data, and user data. Messageslonger than 512 bytes must be sent in multiple MPAKs. The structure of an MPAK andthe relationship of an MPAK to the data link layers are shown in Figure A-2: MASCand MPAK Layer Frames.

MAsc FrAMesMASC is the link layer protocol used to communicatebetween a terminal and a radio modem. MASC provides all the necessary commandsto send and receive MPAKs and to provide terminal control. MPAKs are transmittedacross the MASC link by encapsulating MPAKs in MASC frames. Acknowledgments(ACKs) are used to maintain an orderly transfer of frames. Figure A-2: MASC andMPAK Layer Frame Relationship illustrates the relationship between MPAKs andMASC frames.

A complete listing of MASC Frames is shown in Appendix C, while MPAK Framesare displayed in Appendix D.

rOsi FrAMesROSI (Radio Open System Interface) is the link layer protocol used to communicatebetween the radio modem and a base station. MPAKs are transmitted across theROSI link by encapsulating MPAKs in ROSI frames (refer to Figure A-2: MASC andMPAK Layer Frames). As in the MASC link layer, ACKs are used to maintain anorderly transfer of frames. Details about the ROSI protocol can be found in the MISdocument.

Figure A-2: MASC and MPAK Layer Frame Relationship


siMPle MessAGinGA simple way to understand the MASC and MPAK protocols is to compare the sending of a message in MOBITEX with mailing a postcard. Picture yourself at a PC using a messaging application to send the message “hello” to a friend (refer to Figure A-3: Sample MOBITEX Application Screen). The message will be delivered over the MOBITEX system. Just as addressing a postcard, the MOBITEX message needs both the receiver’s address and the return address. In MOBITEX, the addresses are called MOBITEX Access Numbers (MANs). A MAN is an 8-digit number that is usually associated with a radio modem. A MAN can also be associated with a person, a group, or a host; the system associates MANs with a radio modem (person or group). After the sender’s and receiver’s addresses are entered, the message is delivered by pressing the send key.

When the send key is pressed, the message and addresses do not go directly to the modem. First, several actions must be performed by the software. These actions follow communications rules called protocols. The following sections show how messages are converted to packets that conform to the MASC and MPAK formats for use over the MOBITEX networks.

APPlicAtiOn lAyerAt the application layer, text is entered on a terminal. Enter the text: Send hello

Enter the sender’s and receiver’s address: From: 16002417 (MAN) To: 16002720 (MAN)

netwOrK lAyerThe network layer protocol creates a text MPAK as shown in Figure A-4, using the data entered in the application layer, by performing the steps on next page:

Figure A-3: Sample MOBITEX Application Screen


netwOrK lAyer, cOntinuedA simple way to understand the MASC and MPAK protocols is to compare the sending of a message in MOBITEX with mailing a postcard. Picture yourself at a PC using a messaging application to send the message “hello” to a friend (refer to Figure A-3: Sample MOBITEX Application Screen). The message will be delivered over the MOBITEX system. Just as addressing a postcard, the MOBITEX message needs both the receiver’s address and the return address. In MOBITEX, the addresses are called MOBITEX Access Numbers (MANs). A MAN is an 8-digit number that is usually associated with a radio modem. A MAN can also be associated with a person, a group, or a host; the system associates MANs with a radio modem (person or group). After the sender’s and receiver’s addresses are entered, the message is delivered by pressing the send key.

Figure A-4: MPAK Structure

Figure A-1: Creating a Text MPAK


netwOrK lAyer, cOntinued

nOte: A packet with only a start (^) and end [CR] character will receive a response from the receiving device.

Figure A-1: Creating a Text MPAK (continued)


initiAliZinG the rAdiO MOdeMBefore any messages can be sent to the radio modem and transmitted over the MOBITEX networks, the radio modem must first be initialized. Initialization is a brief exchange of frames that lets the radio modem know it is communicating with a MOBITEX-capable terminal. Initialization is primarily a link layer function (MASC protocol) but a network layer synchronization (MPAK protocol) also exists.

dAtA linK lAyer initiAliZAtiOnThe first and most important frame in the initialization sequence is called a B-frame.The B-frame is included in the MASC frame definition field of an Information Frameand can be sent by either the radio modem or the terminal. The contents of a Bframeare as follows:

Where:

B = frame type [SP] = space type 47E = maximum size of the information frame in HEX (47E = 1150 decimal) , = comma 0 = shortest time between subsequent frames in milli-seconds (in 10 ms intervals).

In the following B-frame, the maximum frame length is 1150 characters and the timebetween frames is as fast as possible (no delay):

^0010b[sP]47e,0:5d[cr]

The following B-frame indicates that the maximum frame length is 1150 characters witha 30 ms delay between frames:

^0010b[sP]47e,3:5e[cr]

It is important to note that a B-frame is bi-directional; either the radio modem or theterminal/application can send it. When a radio modem is first powered on it alwayssends a B-frame to the terminal.

After a B-frame is sent, the receiver responds by sending an acknowledgment (ACK).The sender does not send any more frames until this ACK is received. In the MASCprotocol, every frame is ACKed by the receiver. The contents of an ACK are asfollows:

^*0[cr] or ^*1 [cr]

Figure A-1: Creating a Text MPAK


dAtA linK lAyer initiAliZAtiOn, cOntinuedNote that an ACK contains either a 1 or a 0. This is because ACKs are alternated starting from zero. The first ACK sent from either device is 0, the next ACK is 1, and the following ACK is 0 again.

Once a B-frame is ACKed, the link is initialized.

netwOrK lAyer synchOniZAtiOnAfter the link layer initialization is completed, the network (MPAK) layer is synchronized. The MPAK layer is synchronized by sending a MASC “FP” command to the radio modem. The Layer contents of an FP-frame are shown in Figure A-6:

The FP command retrieves the following (in an FP frame sent by the radio modem): • MAN of the radio modem • Type of device (radio modem or fixed terminal) • MANs the radio modem can use as aliases.

The MPAK layer synchronization is complete after all of the frames are ACKed.

stArtuP suMMAryA summary of the initialization process is shown in Figure A-7: Radio Modem toSummary Terminal Startup The startup sequence was started by the radio modem.

Figure A-6: FP-Frame


stArtuP suMMAry, cOntinued

AdditiOnAl inFOrMAtiOn FrAMesIn addition to the frames used in the initialization process, frames are sent from theradio modem to the terminal to provide important information about the network. Theseframes are used to provide information about the following: • Condition of radio modem network contact • If the radio modem is working in a valid area • Current mode of radio modem (power saving or express)

The following frames can be sent by the radio modem to the terminal any time after Information the link layer is initialized:

Figure A-7: Radio Modem to Terminal Startup


AdditiOnAl inFOrMAtiOn FrAMes, cOntinued

Figure A-8: Additional Frames

MPAKs stored in the radio modem buffer prior to initialization may also be sent to theterminal after the link is initialized.


sendinG MessAGe trAFFicIn the ROSI protocol, a network acknowledgment is sent by the base station to theradio modem to acknowledge the receipt of a packet. The radio modem, in turn,sends an FH-frame to the terminal to notify the terminal (or acknowledge) that theMPAK was received by the base station. The contents of a network acknowledgmentare as follows:

Figure A-10: Link Layer ACKs and Network Acknowledgment illustrates a messagesent from an application to the base station and the returned ACKs.

Packets and ROSI ACKs are sequenced from 0-9. Sequencing is used only between the radio modem and the network and is not end-to-end. This example does not show the optional packet sequencing that is available.

receivinG And decOdinG PAcKetsA packet sent between a radio modem and a terminal must be verified to ensure that theMASC link layer packet is correct. A MASC layer frame is checked for the following:

• Presence of a start character • Correct packet length • Correct LRC • Presence of an end character

Figure A-9: FH-Frame

Figure A-10: Link Layer ACKs and Network Acknowledgment


receivinG And decOdinG PAcKets, cOntinuedIf above characteristics are correct, a MASC ACK is sent to the sending device. If any errors are detected, a MASC NACK is sent. Further, processing of the MASC packet is performed by the receiving device after the packet is ACKed. The first process is to determine the packet type.

The receiving device processes the packet based on the packet type. If the packet received by a terminal (running the messaging application, for example) is an MPAK, information, such as the sender’s MAN and user data (text message) are converted to ASCII and displayed on the terminal. Other MPAK information available to the application are: traffic state, subscription flag, packet class, packet type, and time of transmission. If the received packet is an information frame, such as the radio signal strength (FA-frame), only significant information is processed.

MAsc lAyer cOntrOl FrAMesIn the MASC link layer, there are five control frames that provide information about thetransfer of MPAKs between the radio modem and the terminal. They are:

• ACK • RACK • NACK • SENS • SACK

AcK FrAMeA link layer ACK frame informs the sending device that a frame hasbeen successfully transmitted across the physical link (i.e., the cable connecting theradio modem to the terminal). An ACK frame contains the following:

nOte: The MASC ACK differs from the ACK used on the ROSI data link layer. The ROSI ACK

is sent between the radio modem and a base station in response to correctly received radio frames (see Figure A-10).

nAcK FrAMeThe NACK frame informs the sending device that the frame was not received correctly. A NACK is sent when a received frame does not meet all of the link layer requirements (e.g., the LRC was calculated incorrectly). However, if a frame does not meet the basic link layer requirements (i.e., no start or end character), the radio modem ignores the frame and does not respond. A NACK frame contains the following:

rAcK FrAMeA RACK is used by the sending device to request the value of the last ACK sent. A RACK is sent if the ACK is lost, or no ACK is received ten seconds after an information frame is sent. A RACK frame contains the following:


sens FrAMeA SENS frame is used to check the communications link during a period of inactivity.Successive SENS frames are sent at least 10 seconds apart. If the sending unit doesnot receive a SACK (in response to the SENS) within 10 seconds, it sends a secondSENS.

If no SACK or ACK is received after the second SENS, the link is considereddown and must be re-initialized. A SENS frame contains the following:

sAcK FrAMeA SACK frame is sent in response to a SENS if the link is active. A SACK frame contains the following:

errOr MessAGesThere are several ways that the existence of data link errors are communicatedMessages between an application and a radio modem. The two most common ways use the“E” and “FK” frames.

e-FrAMeThe E-frame is sent by the radio modem as a response to a command or function fromthe terminal that cannot be executed either because the requested command orfunction is not implemented or the included parameters are incorrect. The data field isempty in this frame. An E-frame contains the following:

FK-FrAMeThe E-frame is sent by the radio modem as a response to a command or function fromthe terminal that cannot be executed either because the requested command orfunction is not implemented or the included parameters are incorrect. The data field isempty in this frame. An E-frame contains the following:


n-FrAMeA SENS frame is used to check the communications link during a period of inactivity.Successive SENS frames are sent at least 10 seconds apart. If the sending unit does not receive a SACK (in response to the SENS) within 10 seconds, it sends a second SENS.

r-FrAMeThe R-frame is used by the radio modem to send an error code to the terminal when the MPAK being sent from the application does not conform with the MPAK protocol format, orthe network or link layer protocols. If packet sequencing is being used in the MPAKs, R-frames include the sequence number.

r-FrAMeThe R-frame is used by the radio modem to send an error code to the terminal when the MPAK being sent from the application does not conform with the MPAK protocol format, orthe network or link layer protocols. If packet sequencing is being used in the MPAKs, R-frames include the sequence number.


errOr cOdesTable A-2: Error Code Descriptions defines error codes that can be returned by FK, N and R-frames:

Figure A-2: Error Code Descriptions

descriPtiOnerrOr cOde

01 DIE Mode ordered from the network.

02 LIVE Mode ordered from the network.

0A Receive buffer full. Radio modem is unable to receive more MPAKs from network.

0b Receive buffer free. Radio modem can receive MPAKs from the network.

0c Receive buffers for data from the terminal are full.

0d Receive buffers for data from the terminal are free.

10 Returned command during DIE mode.

12 Returned command during MANUAL mode.

13 Radio modem returns MPAK to the terminal. Transmit memory space buffer full.

16 Login request denied. MAN already exists in Flexlist.

17 Login request denied. Flexlist is FULL.

18 MPAK sender MAN is not in TMAN or Flexlist.

51 Illegal MPAK type. Not allowed for transmission to network.

52 Illegal MPAK state.

53 Illegal MPAK flags.

54 Illegal Send List.

55 Illegal MPAK length.

56 Illegal addressee in MPAK.

61 Temporary default list received from terminal is incorrect.

62 MPAK returned on command FI or FO.

63 Attempt to change into already active mode (i.e., express/battery save).

64 Invalid logout request. The MAN is not present in the Flexlist.

65 Mode change already in progress.

A0 Transmit buffer full. Not enough memory to hold MAX length MPAK.

e0 Unsuccessful radio transmission.

F0 Transmit buffer full. MAX # of MPAKs in Xmit buffer has been exceeded.

F9 Incompatible radio transceiver module. (Non-integrated radio modems.)

FA Radio transceiver LOW BATTERY. (Non-integrated radio modems.)

Fb Modem battery low. (Non-integrated radio modems.)

Fc Fatal radio error. Unrecoverable fault in radio transceiver.

Fd Other error. Radio modem unable to transmit MPAK.


inFOrMAtiOn FrAMes And Other PAcKet tyPesThere are other MASC frames that are included to make the MASC protocol implementation complete. Please refer to Table A-3 for a list of Information Frames.

Figure A-3: Information Frames

FrAMe FunctiOn sent FrOM Pc resPOnse FrOM rAdiO

FA Radio Signal Strength Value ^000EF[SP]A02:34 ^0011 F[SP]A02,32:6C

Battery Strength ^000CF[SP]I:38 ^0011 F[SP]A03,52:6B

Fi Cancel last packet ^000EF[SP]A02:34 “F K” and “N” frames

FM Turn off transmitter ^000DF[SP]M0:0B

FA Turn transmitter on ^000DF[SP]M1:0A

FO Turn radio modem off ^000CF[SP]O:3E ^000CF[SP]O:3E

Fr Change Network ID

CANADA ^00015F[SP]RC4D7,C4D7:78 ACK

U.S. ^00015F[SP]RB433,B433:78 ACK

Ft Change Temporary Default List

FX Change bit rate

1200 ^0011F[SP]X01,01:XX ^0011F[SP]X01,01:XX

2400 ^0011 F[SP]X01,02:75 ^0011 F[SP]X01,02:75

4800 ^0011 F[SP]X01,03:74 ^0011 F[SP]X01,03:74

9600 ^0011 F[SP]X01,04:73 ^0011 F[SP]X01,04:73

FZ Product Information

Software ID ^000EF[SP]Z01:2C Varies depending on Manufacturer

Software Version ^000EF[SP]Z02:2F Varies depending on Manufacturer

Physical Serial Number ^000EF[SP]Z03:xx ^000XF[SP]Z03xxx/yyy/zzzzzz:XX

xxx = Manufacturers code

yyy = Model Number

zzzzzz = Identification Number

FrAMe FunctiOn sent FrOM rAdiO MOdeM

FG Informs terminal that radio modem is out of coverage ^000CF[SP]G:36[CR]

FF Informs terminal that radio modem established network contact ^000CF[SP]F:37[CR]

Fs Informs terminal about changes in traffic area ^000FF[SP]S0,1:0A[CR]


AdditiOnAl MPAK tyPesMPAKs are broken down into three classes:

• PSUBCOM • PSOSCOM • DTESERV

SkyTel Wireless does not use the PSOSCOM class on its networks. The packettypes associated the PSUBCOM and DTESERV classes are listed in Table A-4below. For a description of these packets please refer to Motorola’s MobileAsynchronous Communications (MASC) Interface document, Ericsson’s MobidemProgrammers Guide or the MOBITEX Interface Specification (MIS), which areavailable from Ericsson.

Figure A-4: PUSBCOM and DTESERV Classes

PsubcOM dteserv

teXt (Ascii) LOGINREQ

dAtA (Any code) LOGINGRA

stAtus LOGINREF

hPdAtA LOGOUT

eXtPAK LOGOUTORD

GROUPLIST

TIME

ACTIVE

FLEXLIST

INACTIVE

MODE

Appendix B: Sample Test PlanMAsc rAdiO

The following Start-up, Shutdown and Initialization test sequences are to be performed on MASC Radio Modem Drivers.

MAsc rAdiO stArt-uP sequenceEnsure that the start-up sequence is as follows:

The application should assume no coverage until FH frame for ACTIVE packet hasbeen received.

MAsc Active PAcKet esn FieldCheck that ACTIVE packet contains space for ESN (bytes 9-12 should be set to zero).

MAsc FrAMes durinG initiAliZAtiOnDuring initialization, ensure the following:

1. Check that no MASC frames are sent by the application other than those required by the initialization sequence.

2. Check that the application does not assume coverage due to reception of FF frames. Coverage should only be assumed on reception of FH in response to

ACTIVE

Execute this test for a MASC Radio modem driver. Check that the shutdownsequence is as follows:

packet transmission.

Appendix B: Sample Test Plan, ContinuedrAdiO shutdOwn sequence

During initialization, ensure the following:

MAsc FiXed terMinAlExecute this section for MASC Fixed Terminal Drivers

MAsc Fst stArt-uPCheck that the start-up sequence is as follows:

Application should assume contact with network when MASC ACK for ACTIVE packetis received.

MAsc Active PAcKet esn FieldCheck that ACTIVE packet contains space for ESN (bytes 9-12 should be set to zero).

MAsc FrAMes durinG initiAliZAtiOnEnsure that no MASC frames are sent by the application during initialization other than those required by the initialization sequence.

MAsc Fst shutdOwn sequenceEnsure that the shutdown sequence is as follows:

Appendix B: Sample Test Plan, ContinuedMPAK X.25

Execute this section for MPAK X.25 Drivers

MPAK X.25 cOnFiGurAtiOnEnsure that the X.25 link is configured correctly with regard to the following items: • window sizes • packet sizes

MPAK X.25 stArt-uP sequenceCheck that the start-up sequence is as follows:

MPAK X.25 shutdOwn sequenceCheck that the start-up sequence is as follows:

cOMMunicAtiOns stAtusIn this test, the application should have a transaction/session in progress (i.e., the coverage/link indicators should be updated in real time).

MAsc MOX-linK stAtusCheck that the Network (Link/No Link) status is reported in real-time by the application or via a keyboard press.

M PAK-X.25 MOX - linK stAtusCheck that the Network (Link/No Link) status is reported in real-time by the application or via a keyboard press. In the case of MPAK-X.25 check for: 1. Level 3 failure. 2. Level 1, 2 failure.

MAsc rAdiO hOst linK stAtusCheck that the Network (Link/No Link) status is reported in real-time by the application or via a keyboard press.

hOst cOverAGe stAtusCheck that the Network (In Coverage/No Coverage) status is reported in real-time by the application or via a keyboard press.

MObile cOverAGe stAtusCheck that the Network (In Coverage/No Coverage) status is reported in real-time by the application or via a keyboard press.

MObile linK stAtusCheck that the Network (Link/No Link) status is reported is reported in real-time by theapplication or via a keyboard press.

Appendix B: Sample Test Plan, ContinueddAtA trAnsFer MessAGe trAnsFer tyPe

Check whether any of the following transfer types are supported by the application: • Text • Data • Status • HP Data

dAtA trAnsFer usinG terMinAl MAn MiniMuM MessAGe siZeCheck the following message transfers and repeat for all relevant packet types. 1. Send message from Mobile A to Host. 2. Send message from Mobile B to Host. 3. Send message from Host to Mobile A. 4. Send message from Host to Mobile B. 5. Send message from Mobile A to Mobile B. 6. Send message from Mobile B to Mobile A.

dAtA trAnsFer usinG terMinAl MAn terMinAl MAn AverAGe MessAGe siZeRepeat the procedure described for minimum size messages, but use an averagesize message.

dAtA trAnsFer usinG terMinAl MAn terMinAl MAn MAXiMuM MessAGe siZeRepeat the procedure described for minimum size messages, but use a maximum size message.

dAtA trAnsFer usinG GrOuP MAnCheck the following message transfers: 1. Send message from Mobile to Group G1. 2. Send message from Host to Group G2.

dAtA trAnsFer usinG Address listCheck the following message transfers 1. Send message from Mobile A to Mobile B and Host. 2. Send message from Host to Mobile A and Mobile B.

dAtA trAnsFer usinG eMerGency MessAGinGCheck the following message transfers: 1. Send Emergency message from Mobile.

dAtA trAnsFer usinG PersOnAl MAnCheck the following message transfers: 1. Log-in subscriber P1 on Mobile A. 2. Send message from subscriber P1 to Host. 3. Send message from Host to subscriber P1. 4. Log-out subscriber P1 on Mobile A.

dAtA trAnsFer usinG usinG POsitive AcK, POsitive AcK, nO MAilbOXCheck the following message transfers:

1.1. Ensure that Mobile is active. 2. Send an MPAK from Host to Mobile with Pos-Ack Flag set and No MailBox set. 3. Check that the packet is delivered to mobile and that the packet is returned to the sender as a PosACK.

Appendix B: Sample Test Plan, ContinuedPOsitive AcK, MAilbOX

Check the following transfer 1. Ensure that Mobile is NOT active. 2. Send an MPAK from Host to Mobile with Pos-Ack Flag set and MailBox set. 3. Ensure packet has been mailboxed. 4. Ensure packet has been returned to Sender with IN_MAIL traffic state. 5. Activate Mobile on network. 6. Check that packet is returned delivered to mobile and that the packet is returned to the sender as a Pos ACK.

MObiteX trAFFic stAtes hOst FrOM_MAil trAFFic cOnditiOn 1. Ensure that the Host is not active on the network. 2. Send an MPAK from Mobile to Host with Mailbox Flag set. 3. Ensure MPAK has been Mailboxed. 4. Activate Host on network. 5. Host should receive the MPAK from the Mailbox. 6. Check that the application handles this traffic state.

MObile FrOM_MAil trAFFic cOnditiOn 1. Ensure that the Mobile is not active on the network. 2. Send an MPAK from Host to Mobile with Mailbox Flag set. 3. Ensure MPAK has been Mailboxed. 4. Activate Mobile on network. 5. Mobile should receive the MPAK from the Mailbox. 6. Check that the application handles this traffic state.

hOst in_MAil trAFFic cOnditiOn 1. Ensure that the Mobile is not active on the network. 2. Send an MPAK from Host to Mobile with Mailbox Flag set. 3. Ensure MPAK has been Mailboxed and returned to Host with IN_MAIL flag set. 4. Check that the application handles this traffic state.

MObile in_MAil trAFFic cOnditiOn 1. Ensure that the Host is not active on the network. 2. Send an MPAK from Mobile to Host with Mailbox Flag set. 3. Ensure MPAK has been Mailboxed and returned to Mobile with IN_MAIL flag set. 4. Check that the application handles this traffic state.

hOst nO_trAnsFer trAFFic cOnditiOn - nO MAilbOX FlAG 1. Ensure that the Host is not active on the network. 2. Send an MPAK from Mobile to Host with Mailbox Flag NOT set. 3. Ensure MPAK has been returned to host within 40 seconds with NO_TRANSFER flag set. 4. Check that the traffic condition is logged for diagnostic purposes. 5. Check that retries do not take place for at least 30 seconds. 6. Ensure that a finite retry philosophy is implemented.

MObile nO_trAnsFer trAFFic cOnditiOn - nO MAilbOX FlAG 1. Ensure that the Mobile is not active on the network. 2. Send an MPAK from Host to Mobile with Mailbox Flag NOT set. 3. Ensure MPAK has been returned to mobile within 40 seconds with NO_TRANSFER flag set. 4. Check that the traffic condition is logged for diagnostic purposes. 5. Check that retries do not take place for at least 30 seconds. 6. Ensure that a finite retry philosophy is implemented.

Appendix B: Sample Test Plan, ContinuedhOst nO_trAnsFer trAFFic cOnditiOn - MAilbOX FlAG set

1. Ensure that the Host is not active on the network. 2. Send 6 MPAKs from Mobile to Host with Mailbox Flag set. 3. Check that the 6th MPAK returned to the Host is a NO_TRANSFER. This indicates that the mailbox is full. 4. Check that the traffic condition is logged for diagnostic purposes.

MObile nO_trAnsFer trAFFic cOnditiOn - MAilbOX FlAG set 1. Ensure that the Mobile is not active on the network. 2. Send 6 MPAKs from Host to Mobile with Mailbox Flag set. 3. Check that the 6th MPAK returned to the Mobile is a NO_TRANSFER. This indicates that the mailbox is full. 4. Check that the traffic condition is logged for diagnostic purposes.

hOst illeGAl trAFFic cOnditiOnThis test is best performed using the Network Simulator.

1. Send an MPAK from Host to an Unregistered MAN or a MAN outside the Closed User Group. MPAK will be returned to the Host with Traffic State set to ILLEGAL. 2. Check that the traffic condition is logged for diagnostic purposes. 3. Check that a message is displayed on the Application User Interface to indicate that the system administrator should be contacted. 4. Check that retries do not take place.

MObile illeGAl trAFFic cOnditiOnThis test is best performed using the Network Simulator. 1. Send an MPAK from Mobile to an Unregistered MAN or a MAN outside the Closed User Group. MPAK will be returned to the Mobile with Traffic State set to ILLEGAL. 2. Check that the traffic condition is logged for diagnostic purposes. 3. Check that a message is displayed on the Application User Interface to indicate that the system administrator should be contacted. 4. Check that retries do not take place.

hOst errOr trAFFic cOnditiOnThis test is best performed using the Network Simulator. 1. Send an MPAK to the Host with Traffic State set to ERROR. 2. Check that the traffic condition is logged for diagnostic purposes. 3. Check that retries do not take place for at least 30 seconds. 4. Ensure that a finite retry philosophy is implemented.

MObile errOrThis test is best performed using the Network Simulator. 1. Send an MPAK to the Mobile with Traffic State set to ERROR. 2. Check that the traffic condition is logged for diagnostic purposes. 3. Check that retries do not take place for at least 30 seconds. 4. Ensure that a finite retry philosophy is implemented.

Appendix C: MASC Frame Quick ReferenceMAsc FrAMes

The MASC Frames appear on the following pages.

Sent from the radio modem to the terminal

Bi-directional. Data fields are empty unless noted.

Sent from the terminal to the radio modem

request express/Powersaving Mode status

(param-0/i)

value in dbpu (param-00-FF)

(seq.-0-9) Optional

(code-01, 02, 04, 05, 06)

(tX-0-7)

(param-0-9)

(param-0-9)

(mode-0-09)

(funct-0-03)

(dev-Mcu, MOX)

(tX-network. id for mobile transit)(rX-network. id for mobile receive)

(Out-0/1, cmd 0/1)

(sum-total #ch,num-# ch. in cmd, M-0-3data-channel is)

(funct-01-03,prod-sw vers.esn)

send express/Powersaving Mode status

request rssi value

send rssi value

request battery strength

send battery strength

network contact established

network contact lost

MPAK sent to network

cancel send MPAK

send error Message

disable/enable transmitter

turn OFF radio Modem Power

request MAn

send MAn

send device identity

send net network id

send traffic Area information

charge temp. def. channel list

request changedata rate

battery savingMode control

request express/Powersaving Mode status

request Product id

send Product id

Appendix C: MASC Frame Quick Reference, ContinuedMAsc FrAMes, cOntinued

request network contact status

(param 1=1-no contact, 2-contactparam2=1-One, 2-live)

(param-terraMAn,rexsist, group list)

(param1-nd)(param2=network operator name)

(param1-nd)(param2=network operator name)

(sel= 1-disabled, 2-enabled)

(sel= 1-disabled, 2-enabled)

(param=Arealist, command)

stAtes_cOde=00,01,10,11)

(report=0,1 MOde=0, express, 1batt. save, shiPMent=-,1,2,3,4

(len=max lengtgh of i-frame(rt=min between frames)

(param=frame sync, rssi_PrOc, rssi_PeriOdscan_time, # bases. current_base id, current_area, to, roaming value, neighbor list)

(seq=0-5) (data=MPAK)

(err=13,02,03,e0, F0) (seq=0-1)(data=MPAK)

(err=13,02,03,e0, F0) (seq=0-1)(data=MPAK)

list networkcontact status

request subscriber information

list subscriber information

request network change

request current network

list current network

list Mobitex time Filter setting

enable Mobitex time Filter setting

request Area list

list Area list

request roaming Parameters

list roamingParameters

request lock toup/down channel

unlock to up/down channel

list lock up/downchannel status

request Operation Mode

list Operation Mode

request change Operation Mode

received Functionnot executed

initialize MAsccommunications link

send/receive MPAK

send MPAK Failed

request Product id

returned Failed MPAK

Appendix D: MPAK Frame Quick ReferenceMPAK FrAMes

The MPAK Frames appear on the following pages.

Sent from the network to the terminal

Bi-directional.

Sent from the terminal to the network

(subscription tags: 0-10x=use optional address list)

teXt

lOGinreF

GrOuPlist

lOGOut

FleXlist

bOrn

Active

lOGOutOrd

FleXreq

inFOreq

esnreq

inActive

lOGinreq

inFO

rOAM

lOGinGrA

tiMe

AreAlist

esninFO

die

live

MOde

dAtA

stAtus

hPdAtA

eXtPAK

without Optional Address list

PsubcOM dtserv: terminal status

dtserv: subscription state

dtserv: teminal information

with Optional Address list

rOAMOrd

Appendix D: MPAK Frame Quick Reference, ContinuedMPAK FrAMes, cOntinued

The MPAK Frames appear on the following pages.

without Address list

bits bits

teXt

dAtA

stAtus

hPdAtA

eXtPAK

lOGinreq

lOGinGrA

lOGinreF

lOGOut

lOGOutOrd

bOrn

Active

GrOuPlist

inActive

die

live

rOAMOrd

rOAM

FleXreq

FleXlist

inFOreq

inFO

tiMe

AreAlist

esnreq

esninFO

MOde

sOs

sOsinFO

sOsAcK

transfer OK

From Mailbox

in Mailbox

no transfer

illegal

congested

technical error

busy

Place in Mailbox

Pos AcK

Address list

unknown subscription

PsubcOM

dtserv

PsOscOM

SkyTel Wireless Network Developerâ€™s Reference Guide

Documents

Transcript of SkyTel Wireless Network Developerâ€™s Reference Guide