aNovember 5, 1997

RF-Conductor!™ Release 1.0 WMS-Data

Marketing Product Description

Version 1.965

Change History

VersionDateAuthorChange History

1.961/6/97Lee RobinsonMake DDTs changes.

1.9511/5/97Lee RobinsonMake final changes which includes

removing alarm list at end of MPD.

By agreement, the MPD inspectors

decided these belong in a user’s

manual instead of the MPD.

1.9410/29/97Lee RobinsonMake additions to requirements for

launch time of paging data within

500 µsec of frame 0, cycle 0. Also

add requirement to support zones.

Correct cosmetic problems.

1.9310/27/97Lee RobinsonMake revisions that came out of

inspection on 10/24/97.

1.9210/20/97Lee RobinsonMake revisions that came out of

inspection on 10/20/97. This

includes adding an acronym table.

1.9110/8/97John KinneyIncludes all changes & additional

reqmnts based on 10/7 inspection

and inputs from E/ME/A and Asia

1.910/1/97John KinneyIncludes additional reqs for

TNPP and other changes based

on inputs from Jeff Couts, T.

Hill and S. Tewinkle.

1.89/30/97John KinneyModifications and clarifications

based on 9/30 review with

development team. Broken reqs

based on demo and beta phases.

1.79/25/97Lee RobinsonScrubbed for new RF-C! software

architecture. This version of the

MPD is derived from the Harmony

RF-C!, version 1.

Contributors:

This document was derived from the Harmony RF-C! Release 3.0, version 1.6 MPD. As such, it draws indirectly on the experienced inputs from the following people:

Dave Amerson, Ray Bartik, Rich Bennett, Alain Briancon, Dawn Brown, Robert Ellis, Mark Jones, John Kinney , Jyh-Han Lin, Gary MacDowell, Mike Maloney, Hagai Ohel, John Potocki, Chuck Rauch, Jim Starkweather, and Don Wilson.

Table OF CONTENTS

1. Executive Summary16

1.1 Program Drivers16

1.2 Product Goals16

1.3 Acronyms17

2. Overview19

2.1 Basic Operation19

3. System Architecture and Environment110

3.1 POCSAG, FLEX, and ReFLEX RF-C! Configurations113

4. Hardware114

4.1 Control System Environment:114

4.1.1 Environmental Specification:114

5. System Capacity115

5.1 One Way only scenarios115

6. Requirements118

Signatures

______

Tony Marshall

Director of Sales, North America

______

Lai Kokhian - Marketing Manager - Asia-Pacific Paging Systems Division

______

Niranjan Segal - Marketing Manager - EMEA Paging Systems Division

______

John Kinney

Sr. Manager - Product Manager, RF-Controls & Network Management

______

Babu Gopalakrishnan

Sr. Engineering Mgr - RF-Conductor!

1.Executive Summary

RF-Conductor! WMS-Data Release 1.0 largely focuses on adding the one way functionality needed to meet the one way only control market as well as provide a clear migration path to support the two way control market.

The initial deployment of Release 1.0 provides one way functionality only. It provides mixed FLEX and POCSAG within the same controller.

The initial release of RF-C! version 1.0 is intended to protect the C-NET installed base by providing additional functionality at the control point without replacing the NIU hardware (note that dual flash is needed to support the RF-C! It provides one way paging using WMS-Data NIU transmitter controllers and Nucleus transmitters). Support for two way and other IP based protocols (i.e. WMtp, OPP, IPP)will be added to the product in later phases.

Note:RF-Conductor! and RF-C! both refer to the new WMS-Data controller in this document. These terms are used interchangeably.

1.1Program Drivers

Considering price structure and market needs, RF-Conductor! WMS-Data Release 1.0 answers the ongoing market needs for one way control and is tiered to provide a smooth path towards one way and two way control environments.

Key market drivers for the product include:

1.Quality

2.Desire for increased link efficiencies to improve capacity of simulcast system.

3.Desire for higher speed links to improve capacity of simulcast system

4.Performance (batching efficiency with mixed protocols)

5.Time to Market - Q1 98

6.Maintainability

7.Alarms and statistics

8.Interim desire to mix one way traffic with two way traffic to allow for quicker payback on new infrastructure costs required by two way.

9. Redundancy

1.2Product Goals

The key goals of this project are to release this version of the RF-C! as quickly as possible with the features most demanded by our one way customers. C-NET is under extreme pressure to support Supersystems and SuperStream™. It is not feasible to add these functions to C-NET. More importantly, C-NET is at a competitive disadvantage to C2000. As such, an erosion of the installed base is currently taking place. This release of RF-C! will be used as an upgrade platform to enable our existing customers to move to higher speed links, improved link and OTA efficiency and, a migration path to ReFLEX and beyond.

1.3Acronyms

The following table contains a list of acronyms and terms found within this document.

Acronym / Term / Description
BHCR / Busy hour call rate. The percentage of users who access a system in the busy hour (0 to 100%).
bps or BPS / Bits per second
BSC / Battery save cycle. A parameter that controls how frequently pagers “wake up” and listen for paging information.
C! / Internal abbreviation for Choreographer!, The network management system developed by Motorola’s PSG to manage network elements using primarily SNMP.
CCD / Chinese character display. A two byte character set used in chinese character display pagers.
C-NET / The legacy RF controller platform that is intended to be replaced by the RF-Conductor!
codeword / A 32 bit data word. Over the air paging protocols send packets in codeword size chunks.
cps or CPS / Calls per second
DDN / Digital Data Network
EOT / End of transmission. An ASCII control character (hex 04) used within TNPP.
FLEX / An over the air paging protocol developed by Motorola that supports one way paging.
FM2 / A satellite link protocol that uses video technology and frequency division multiplexing.
FM3 / A satellite link protocol that uses video technology and both time and frequency division multiplexing. Typically requires paging RF control equipment to be located at the satellite uplink site.
GPS / Global Positioning System. A satellite based positioning system which provides precise timing and location information. It is used within simulcast paging systems to synchronize transmitter broadcasts.
HEX / Hexadecimal. A base 16 numbering system.
Hz / Hertz. Also cycles per second.
ICM / Infrastructure command message. A packet of information that contains command or control information.
IP / Internet Protocol. A network layer protocol used to route datagrams or packets of data across a network.
Kbps / Kilo-bits per second.
NIU / Network Interface Unit. The transmitter controller used to control Nucleus transmitters via synchronous distribution protocols.
OTA / Over the air.
PDM / Page data message. A packet of information that contains paging data.
POC512, POC1200, POC2400 / Abbreviations for POCSAG 512, 1200 and 2400 signalling speeds.
POCSAG / Post Office Code Standardization Advisory Group. A protocol used for over the air delivery of paging data.
QBS / Queuing, batching and scheduling. Functions performed by the RF-Conductor!
ReFLEX / An over the air paging protocol that supports two way data messaging.
RF / Radio Frequency
RF-C! / RF-Conductor!. The RF controller.
RS / Resend. An ASCII control character (hex 1E) used within TNPP.
SCPC / Single Channel Per Carrier. A satellite link protocol that permits users to use a subset of the full frequency spectrum.
Super systems / A scheduling mechanism that permits a single frequency to be re-used in several zones located within a larger simulcast area without interference.
SuperStream™ / Motorola’s proprietary synchronous distribution protocol used between the RF controller and the NIU transmitter controllers. It features link efficiencies up to and exceeding 100%.
TNPP / Telocator Network Paging Protocol. An application layer protocol designed for paging applications.
VDT / Video display terminal. Typically a “dumb” display device that is used as a console display unit.
VT100 / A type of DEC terminal which is frequently emulated.
WMS / Wireless Messaging System.
WMS-Data / Wireless Messaging System - Data. The name given to release 1.0 of the RF-Conductor! which supports mixed FLEX and POCSAG protocols.

2.Overview

RF-Conductor! WMS-Data Release 1.0 is a controller specified to maintain the low-range to high-end:

  1. One way only RF-Control market
  1. Hybrid one way and two way RF-Control market (future)
  1. Two way only RF-Control market (future)

Reliability and Time To Market are the key drivers and goals for this product.

2.1Basic Operation

As the centerpiece to the infrastructure system, release 1.0 of the RF-C! WMS-Data interfaces with the terminals via TNPP and with the transmitters via the SuperStream™ protocols. This release of the RF-C! embeds controller configuration, statistics, alarm display / management and software download capabilities within the controller. The user interface to the RF-C! supports a VT100 emulation interface. SNMP based configuration, statistics and alarms managementis not supported in release 1.0. Therefore, Choreographer! is not required for operation of the RF-C!.

The RF-Conductor! WMS-Data release 1.0 offers the following major new features (defined in section 6 of this document):

  • FLEX™ and POCSAG support
  • High link bandwidth
  • High distribution link efficiency (SuperStream™)
  • High capacity input and output ports
  • SuperSystems for 1-way traffic
  • Page Type filtering by control system or by simulcast system
  • TNPP version 3.6 support
  • Dynamic Encoding
  • Hot configuration
  • No page loss redundancy
  • 120 Simultaneous simulcast systems
  • High input call rates
  • SuperStream™ Distribution Link Protocol
  • Direct and GPS synchronization
  • 64 Maintenance Group support

3.System Architecture and Environment

There are several typical environmental scenarios which depict the proper application for RF-Conductor! WMS-Data release 1.0. This section will describe the system architectures which RF-Conductor! WMS-Data Release1.0 will operate. The key system architectures are :

  1. Move from C-NET link protocol (max. of 19.2 Kbps link speeds) to SuperStream™ link protocols (max. of 76.8 Kbps link speeds), AND be backward compatible to existing FLEX and POCSAG installed base of Nucleus transmitters.
  1. Permit the introduction of completely new FLEX, POCSAG systems
  1. Support conflicting simulcast systems (Supersystems).
  1. Provide a single control system capable of controlling any mix of the above protocols across multiple simulcast systemss.

The paging distribution system architecture solution meeting all of the above scenarios would be as depicted below in figure 1.0.

Figure 1.0 - System Architecture for One Way Paging

Figure 1.1 below represents the RF network management architecture for the above paging system architecture.

Figure 1.1 - Configuration and Alarming Components in WMS-Data System

In the above scenario we have:

  1. Upgraded the NIUs to dual flash WMS-Data NIU with new software and,
  1. Replaced the C-NET Platinum controller with the RF-Conductor! WMS-Data release 1.0,
  1. Changed the link protocol to the more efficient SuperStream™ link protocol,
  1. Continued using any third party network manager or alarm manager for inbound WMS-Data NIU alarm processing.

The transmitter network alarm reporting, when configured with WMS-Data NIUs, continues to be handled the way it was in the traditional C-NET Platinum system environment.

Software download and initiation of traditional over-the-air commands (OTA) will be initiated from the RF-C!. A typical OTA command would be those used to initiate a maintenance cycle for system alignment. These commands will be embedded in the SuperStream™ data stream for cases where the connectivity to the WMS-Data NIU is through synchronous distribution links like satellite distribution or DDN. A bank select (flash) command will be issued to the WMS-Data NIUs from the C-NET Platinum control point to cause the WMS-Data NIUs to boot-up using the new WMS-Data NIU software.

3.1POCSAG, FLEX, and ReFLEX RF-C! Configurations

The RF-C! shall be capable of supporting ReFLEX functionality in a later release that will allow efficient mixing of POCSAG/FLEX/ReFLEX on the same channel or mix of channels.

4.Hardware

4.1Control System Environment:

Specific hardware configurations will support the capacity requirements stated below. The hardware platforms choices will vary over time and be announced before product launch.

4.1.1Environmental Specification:

4.1.1.1Temperature:

5 to 35 degrees Celsius - Operating

-30 to 65 degrees Celsius - Non-operating

4.1.1.2Humidity:

20 percent to 80 percent (non-condensing) - Operating

5 percent to 95 percent (non-condensing) - Non-operating

4.1.1.3Altitude:

0 to 15,000 ft. - Operating

0 to 50,000 ft. - Non-operating

4.1.1.4Electrical Specification:

Input Voltage: 110 to 220 Vac, or -48 Vdc

Power Dissipation: Approx. 2800 watts

Heat Dissipation: 9548 BTU/hour maximum

FCC Testing: FCC Part 15 Class A

European EMC Testing

5.System Capacity

5.1One Way only scenarios

One way only system capacity will be based on a tiering of synchronous output capacity and equivalent busy hour call rate capacity. The primary variables which determine the capacity of the RF-Conductor! WMS-Data 1.0 are;

  1. mix of traffic (FLEX, POCSAG)
  1. type of message (Numeric, Alphanumeric or Transparent Data)
  1. average message size
  1. Busy Hour Call Rate - CALLS PER SECOND
  1. Number of SIMULTANEOUS simulcast systems

The table below (table 5-1) represents a typical output capacity scenario regardless of protocol mix. Note that the number of simulcast systems, number of TNPP ports and calls per second shall only be limited by processor/memory constraints and shall not be a design limitation. Future releases with faster processors and more memory shall be capable of achieving higher limits.

Number of Simulcast Systems / Calls per second / Output Link Rate
1 - 120 / 100% 10 Digit Numeric only: 460 cps
80% 10 Digit Numeric and 20% 80 character Alpha: 200 cps / Maximum link rate of each port (1 - 4) is 76.8 Kbps

Table 5-1

The table below (table 5-2) represents a typical input capacity scenario.

Number of TNPP Ports / Calls per second / TNPP Link Rate
1 - 24 / Bound by TNPP protocol / Maximum link rate of each port (1 - 24) is 38.4 Kbps

Table 5-2

The tables below show the maximum number of channels that can be supported in a non-mixed protocol environment. Each row in the table displays the maximum number of channels that can be supported for the indicated protocol and given link speed, the total link bandwidth needed per channel, and the calculated link efficiency. Each table presents data for the link speed identified in the caption of the table.

Table 5.3 - Link speed 9.6 kbps

Protocol
(pure, no mixing) / Max. Channels / Link Bandwidth Needed (per channel) / Approximate
Efficiency
FLEX 6400 / 1 / 6400 / 100%
FLEX 3200 / 3 / 3200 / 100%
FLEX 1600 / 5 / 1920 / 83.3%
POCSAG 2400 / 4 / 2400 / 100%
POCSAG 1200 / 7 / 1371 / 87.5%
POCSAG 512 / 16 / 600 / 85.3%

Table 5.4 - Link speed 19.2 kbps

Protocol
(pure, no mixing) / Max. Channels / Link Bandwidth Needed (per channel) / Approximate
Efficiency
FLEX 6400 / 3 / 6400 / 100%
FLEX 3200 / 6 / 3200 / 100%
FLEX 1600 / 11 / 1745 / 91.7%
POCSAG 2400 / 8 / 2400 / 100%
POCSAG 1200 / 15 / 1280 / 93.8%
POCSAG 512 / 32 / 600 / 85.3%

Table 5.5 - Link speed 38.4 kbps

Protocol
(pure, no mixing) / Max. Channels / Link Bandwidth Needed (per channel) / Approximate
Efficiency
FLEX 6400 / 6 / 6400 / 100%
FLEX 3200 / 12 / 3200 / 100%
FLEX 1600 / 23 / 1670 / 95.7%
POCSAG 2400 / 16 / 2400 / 100%
POCSAG 1200 / 31 / 1239 / 96.9%
POCSAG 512 / 65 / 591 / 86.6%

Table 5.6 - Link speed 64.0 kbps

Protocol
(pure, no mixing) / Max. Channels / Link Bandwidth Needed (per channel) / Approximate
Efficiency
FLEX 6400 / 10 / 6400 / 100%
FLEX 3200 / 20 / 3200 / 100%
FLEX 1600 / 39 / 1641 / 97.5%
POCSAG 2400 / 26 / 2462 / 97.5%
POCSAG 1200 / 51 / 1255 / 95.6%
POCSAG 512 / 109 / 587 / 87.2%

Table 5.7 - Link speed 76.8 kbps

Protocol
(pure, no mixing) / Max. Channels / Link Bandwidth Needed (per channel) / Approximate
Efficiency
FLEX 6400 / 12 / 6400 / 100%
FLEX 3200 / 24 / 3200 / 100%
FLEX 1600 / 46 / 1670 / 95.8%
POCSAG 2400 / 32 / 2400 / 100%
POCSAG 1200 / 62 / 1239 / 96.9%
POCSAG 512 / 131 / 586 / 87.4%

6.Requirements

This section presents the requirements for WMS-Data RF-C! in tabular form. Each requirement tag is of the form RFC-xxx-nn-t, where xxx represents a functionally related grouping such as FLEX, nn is the sequential requirement number and t is a letter which indicates when the requirement is to be supported. The letter B is used to indicate the requirement is needed prior to Beta, and C means it is needed before we go commercial.

Requirement

Number

TNPP (per version 3.6)
Note: All TNPP features described in this marketing product description shall be implemented strictly as defined in the 3.6 version of the TNPP protocol specification. No variations from this specification are implied or accepted as being offered with this product. Support of TNPP version 3.8 shall be included in the next release.
FLEX™ (per the G1.8 FLEX Document)
Note: All FLEX features described in this marketing product description shall be implemented strictly as defined in the G1.8 version of the FLEX protocol specification. No variations from this specification are implied or accepted as being offered with this product.
POCSAG
Note: All POCSAG features described in this marketing product description shall be implemented strictly as defined in the POCSAG protocol specification including implementation rules specified in a separate memo signed by Jim Black/Jim Marion dated 4/11/90. No variations from this specification or memo are implied or accepted as being offered with this product.
RFC-FLEX-01-C / FLEX Emergency Re-sync Pattern --In a “Direct-sync” system, Emergency Re-sync shall be sent either:
(1) upon GPS re-acquisition after a loss of GPS or,
(2) due to an operator initiated command from a VDT.
This feature shall be operator configurable as either enabled or disabled per link.
RFC-FLEX-02-C / FLEX Enable/Disable -- The RF-C! shall permit an operator to enable/disable FLEX on a per channel basis within each simulcast system.
RFC-FLEX-03-C / FLEX Frame Carry on - The RF-C! shall support the FLEX carry-on capability. The operator shall be able to disable carry-on or enter the maximum # of frames to carry-on (0-disable - 3 frames). This is operator configurable on a per simulcast system basis. Note that carry on should not be on in every frame, just the frames that are overloaded.
RFC-FLEX-04-B / ALL FLEX Speeds Supported -- The RF-C! shall support 1600 2-level, 3200 2-level, 3200 4-level, and 6400 4-level modes. This is operator configurable on a per channel, per simulcast system basis.
RFC-FLEX-05-B / FLEX Priority -- The RF-C! shall encode any priority messages into the priority address field as defined in the protocol. See RFC-QBS-23 for queuing information.
RFC-FLEX-06-B / FLEX Numeric Standard-- The RF-C! shall support standard FLEX pages with numeric only content. A max. programmable value (from 1 - 41) shall define the max. # of numeric chars supported.
RFC-FLEX-07-B / FLEX Numeric w/numbering -- The RF-C! shall support page numbering on a programmable basis allowing a user to determine if a page has been missed if this is supported in the pager. The number shall be assigned by the terminal. Note: Delivery order cannot be guaranteed.