AVL Applications And Interfaces

1
AVL Applications And Interfaces

• Seppo Nieminen
• Nokia Telecommunications / Professional Mobile
  Radio
• Product Manager, TETRA Wireless Data Products
• TETRA MoU Business Solutions Group Meeting
• 29.9.1999, LUL HQ, London

2
Outline

• Characteristics of the AVL applications
• TETRA data services and their suitability for
  delivering AVL
• TETRA air interface channels and their
  transmission capacity
• Radio resource consumption
• Relevant uses
• Strengths of TETRA data services
• Interfaces
• How to implement on TETRA in practice
• WAP
• Load management
• The future Just "AVL" or something more?
• Conclusions

3
Characteristics of the AVL applications

• Various data needs
• Position indications, control of the vehicle
  positioning equipment
• Task status reporting
• Task dispatch
• Emergency signals
• Vehicle status indications and control
• Reporting
• Access to work related data repositories
• Spontaneous data transmission, mobile-originated,
  mobile-terminated
• Delivery of vehicle position and other data in
  parallel to speech
• Open interfaces required at the terminal and
  infrastructure to connect vehicle and dispatch
  equipment
• A large fleet may cause a high total data load

4
TETRA data services summary

• Status
• Individual, group
• Standardized values
• Application use
• Short Data Service (SDS)
• SDS1, SDS2, SDS3, SDS Transport Layer (SDS-TL)
• Individual, group
• Application use (SDS1 3, SDS-TL)
• Text messaging (SDS-TL)
• Application specific protocols (SDS-TL), e.g.
  GPS, WAP, other
• Internet Protocol packet data (IETF IP, "DoD IP")
• Point-to-point, Mobile Originated setup (current
  ETSI spec)
• Circuit Mode Data
• Point-to-Point
• Point-to-Multipoint

• highly useful speech services
• Individual call, direct call
• Open channel group call
• Supplementary services

5
TETRA air interface

• TETRA air interface is four slot time division
  multiple access (TDMA)
• For Status, SDS and packet data, a time slot (TS)
  delivers 4,8 kbit/s (gross)
• Uplink net capacity affected by the frequency of
  random access attempts
• Uplink (UL) allocation in chunks of 0,5 - 1 - 2 -
  3 time slots

Frame 1
Frame 18
Frame 2
Frame 17
. . . . .
Carrier (C)
18 TDMA frames 1,02s
. . . . .
Timeslot 1
. . . . .
Timeslot 2
. . . . .
Timeslot 3
. . . . .
Timeslot 4
6
Logical channels
Frame 1
Frame 18
Frame 2
Frame 3
Frame 17
. . . . .
1
1
1
1
1
MCCH (C1)
. . . . .
2
3
4
2
3
4
2
3
4
2
3
4
2
3
4
SCCHs (C1)
TCH SACCH (Cx)
. . . . .
T
T
T
TCH FACCH (Cx)
. . . . .
T
T
3
3
. . . . .
4
4
4
4
4
PDCH (Cx)

• Master Control Channel (MCCH), always the first
  TS on the first carrier, mandatory
• Up to three Secondary Common Control Channels
  (SCCH), optional
• Slow Associated Control Channel (SACCH) On 18th
  frame when there is a Traffic Channel (TCH)
  delivering circuit mode traffic (SACCH 200
  bit/s)
• Fast Associated Control Channel (FACCH) During
  idle periods when there is a channel allocated
  for circuit mode traffic, optional
• Packet Data Channel (PDCH) Any unallocated time
  slot on any carrier

7
Status

• Unacknowledged
• Group addressing
• Requires a half TS, minimum (UL)
• Possible channelsMCCH, SACCH, FACCH, stealing

• 16 bit code word
• 32 000 values for standardization
• 32 000 values for application use
• Not suitable to deliver position, however very
  useful in fleet applications otherwise

8
SDS1, SDS2, SDS3

• Usage not specified
• Individual addressing, group addressing
• SDS1 16 bit code word. Requires
• 1 TS (UL) when an MS-ISDN number used
• 0,5 TS (UL) with TETRA Short Subscriber Identity
  (SSI) number
• SDS2 32 bit code word. Requires 1 TS (UL) when
• a 10 digit MS-ISDN number used
• TETRA SSI used
• SDS3 64 bit code word. Requires
• 1,5 TS (UL) when a 10 digit MS-ISDN number used
• 1 TS (UL) when TETRA SSI used
• Unacknowledged
• Possible channels MCCH, SCCH, SACCH, FACCH
• Some parties consider transmitting position with
  SDS2, SDS3

9
SDS Transport Layer (SDS-TL)

• A suite of protocols that use the variable length
  SDS4
• Text messaging
• GPS
• WAP (WDP, WCMP)
• Other
• Free protocol identifiers available for
  application use
• Text messaging
• Unacknowledged mode, acknowledged mode
• Undelayed end-to-end delivery
• Store and forward support
• Different data coding schemes
• 120/140 octets (140 octets 160 GSM 7-bit
  characters)
• GPS
• NMEA 0183, RTCM SC-104 defined
• Other protocols possible
• No common TETRA protocol defined yet - however
  needed

10
SDS-TL GPS

• Resource consumption vs. capacity
• 1 TS (UL) and TETRA SSI used 8 octets of
  Protocol Data
• 1 TS (UL) and a 10 digit MS-ISDN number 1 octet
  of Protocol Data
• 1,5 TS (UL) and TETRA SSI used 30 octets of
  Protocol Data
• 1,5 TS (UL) and a 10 digit MS-ISDN number 23
  octets of Protocol Data
• Features superior to SDS3 - same resource
  consumption
• Possible channels MCCH, SCCH, SACCH, FACCH

11
TETRA SDS-TL GPS, preferred architecture

• Minimize radio resource consumption
• Provide common feature set to the server
  applications
• Facilitate interoperability
• Protocol to be a) specified or b) adopted - a
  TETRA MoU initiative?

GPS or other position source
TETRA Network
Fleet Server
Black Box" and/or TETRA terminal
Conversion
Legacy GPS protocol - NMEA, RTCM, TAIP, TSIP, etc.
Common TETRA GPS protocol - optimized, binary
protocol - position indication - control requests
12
IP
Appli cation

• Internet/Intranet access

Tetra Network
IP address X
Application
Internet
Backbone/transmission
Operator
Customers
Company Intranet
Control Room Intranet
Enterprise Intranet
IP address Y
13
IP, continued

• "Always on, always connected"
• IP context association between an IP address
  and a TETRA identity (ITSI)
• IP usage steps
• 1) Activate IP context obtain IP address for
  the terminal, routing possible
• 2) Stay on MCCH
• 3) Move to PDCH for data transmission
• 4) Leave PDCH to MCCH after an idle period timer
  has expired
• 5) Repeat 3) and 4)
• 6) Deactivate IP context release the IP address
• Mobile originated context setup
• Excess overhead when delivering short messages
  like position information
• PDCH assignment
• IP header (UDP/IP 30 octets)

MCCH
PDCH
14
Data services, potential uses
15
Strengths of TETRA data services

• Versatile data services
• Fast message delivery, c.f. individual call setup
  300 ms
• Higher data rates than in MPT 1327
• Data features competitive with GSM
• Group addressing capabilities, economic
  multipoint delivery per cell, cf. SMS
• SDS does not suffer from delay caused by store
  forward,cf. SMS, direct end-to-end delivery is
  also possible
• SDS-TL is open for new protocols
• IP is a packet mode service - long session times
  economically

16
Interfaces
GPS, antenna Odometer Dead reckoning
Displays, status panels Other I/O
Control Room Interface - Status, SDS - Call
control - Audio interfaces - Programming API
"Smart Box"
PEI Other
TETRA network
SDS Interface - Status, SDS - Programming API
IP (over Ethernet etc.)
TETRA terminal
17
Supporting migration from GSM

• GSM "smart boxes"
• Integrated GPS
• Use AT command set (GSM 07.07)
• Use mainly SMS, sometimes CSD for file transfer
• Often incorporate an OEM GSM module
• Some standard protocols already in use, new ones
  being developed
• GATS from T-Mobil and Mannesmann Autocom. Used in
  Germany (PASSO, TEGARON) and in the USA
• WAP telematics group very active
• WAP and GATS may converge, redundancy at lower
  protocol levels
• TETRA counterparts
• PEI AT command set
• SDS-TL
• IP, CSD for file transfer
• TETRA modules later

18
Supporting migration from MPT

• MPT "smart boxes"
• External or integrated GPS
• External MPT terminal
• Some MPT OEM terminals available
• Use SDM (25 chars á 7 bit), EDM (100 chars),
  modem call
• Standard interface is the MAP 27 protocol
• Many products are generic providing connections
  also for GSM, Mobitex etc.
• TETRA counterparts
• PEI TNP1 has similar philosophy to MAP 27
• PEI AT command set in cases where the "smart box"
  supports it as an alternative interface
• SDS1, SDS2, SDS3, SDS-TL
• IP, CSD for file transfer

19
Nokia TETRA System Data Connectivity
Utility, PSS etc. Command Control Room
TETRA network
TETRA Terminal User Interface
Nokia DSC
Audio
Status, SDS
Nokia TETRA System Switches and Base stations
Audio
Workstations
Users, Groups, Control, etc. Status, SDS
Nokia CIS Server
Work flow applic.
Smart Box (GPS etc.)
Nokia BUS
TETRA Terminal
Status, SDS
Microsoft DCOM/COM
Status, SDS Application
Nokia TPDS
TETRA Terminal
Status, SDS
Nokia SDSI Server
Application
COM
Status, SDS
IP Packet Data
Windows Application
Application
Socket
IP Packet Data
Winsock
Handset Users, Vehicles, Fixed Installations
IT Network, Applications, Databases, Intranet
Customer Provisioning
Nokia CUS Server
DCOM
20
Managing AVL load in the network

• Tariffing
• Limit the length of the position indications -
  sole use of SDS3 ?
• Optimized SDS-TL protocol, especially Uplink -
  application/service provider/ETSI/TETRA
  manufacturer
• Secondary Common Control Channel (SCCH) - TETRA
  manufacturer/ operator
• Polling the position from the terminal, e.g. by
  using a designated Status value -
  application/service provider/ETSI/TETRA
  manufacturer
• Using the capabilities of the TETRA random access
  protocol on MCCH and SCCHs
• Access code (A, B, C, D)
• Subscriber class (1 16), Subscriber group
  (GTSI), PDU priority
• Requires a joint feasibility study and
  specification effort between operators and
  manufacturers

21
Concepts not recommended in TETRA

• Polling position information from the field units
  in multipoint radio style
• TETRA has advanced radio path sharing and
  addressing mechanisms in itself
• TETRA supports spontaneous mobile originated
  delivery
• Wastes downlink capacity
• Polling cycle duration limits the fleet size
• Delivering "printable" AVL protocols over the air
• Wastes uplink and downlink capacity
• Delivering differential GPS (DGPS) correction
  term over the air
• Wastes downlink capacity
• Inverse differential GPS (IDGPS) is a good
  alternative
• RDS or some other secondary channel to deliver
  the correction term to the vehicle locally

22
Trends in terminal development

• Fast developing market
• GPS in some mobile data terminals
• GPS already in some terminals
• WAP soon in both

?
How do the "smart boxes" look in the future?
23
WAP and TETRA

• WAP is bearer independent
• TETRA included in the WAP version 1.2
  specifications
• SDS-TL
• IP
• To be released in the end of -99
• New members in waves
• gtgt Equipment manufacturers
• gtgt Operators
• gtgt Application developers in 3Q/99
• Membership
• 145 members
• Full - 27,500 USD per year
• Associate - 7,500 USD per year
• www.wapforum.org

Other Services and Applications
Wireless Application Environment (WAE)
Wireless Session Protocol (WSP)
Wireless Transaction Protocol (WTP)
Wireless Transport Layer Security (WTLS)
Wireless Datagram Protocol (WDP)
UDP
Adaptation
IP (TETRA)
SDS-TL
Lower Layers
SDS4
24
WAP telematics
Telematics is currently an emerging industry
that, until now, has employed custom,
proprietary, bearer dependent implementations.
WAP and the WAP Forum present an opportunity to
open this market through standardization
activities which are bearer independent (WAP
TEG activity proposal)

• WAP telematics group (TEG) formed recently, works
  very actively
• Requirements approaching completion
• WAP telematics specification is possibly a WAP
  rel. 2.0 work item
• Use cases identified until now
• Safety Services
• Location Dependent Services
• Location Based Billing Services
• Device Lifetime Services (SW upgrade via
  wireless)
• Tracking Services
• Remote Services
• Are TETRA use cases covered with these?

25
WAP and telematics are already converging ...

• .. Sept. 8th, 1999 Ericsson and Mannesmann are
  cooperating to produce mobile communication
  systems that will eventually use WAP and
  Bluetooth to allow equipment in a car's cockpit
  to communicate with each other and the Internet.
• The alliance, formed between a subsidiary of the
  Swedish telecom company called Ericsson Mobile
  Communications and Mannesmann, will produce car
  information and entertainment systems including
  in-car Internet terminals, faxes, stereo and
  video capabilities as well as telematic
  equipment, says Karl-Horst Bockholt, director of
  public relations for German system supplier
  Mannesmann. Telematic equipment provides traffic
  guidance with the use of telecom, Bockholt says.
• The products will be sold first in Europe, where
  WAP is expected to take off first, and will later
  expand to the U.S. and Asia. The systems will be
  sold to vehicle manufacturers for cars, trucks
  and buses as well as to the automotive
  aftermarket, for car retrofits, Bockholt says.
• The two companies are predicting that more than
  10 million mobile terminals will be built into
  cars in Europe and the U.S. by 2003. ..

• WAP TEG builds on related activities where
  possible
• CEN, ERTICO, ITS America, ISO, SAE, VERTIS
• GATS Forum, The Telematics Suppliers Consortium,
  VICS

26
Example Winfleet

• Fleet Management Software for communication,
  locationing, and monitoring
• Positioning functions
• Position request
• Position reports at defined time intervals
• Position reports at defined distance intervals
  (if vehicle HW supports)
• Position reports at defined times (if vehicle HW
  supports)
• Last vehicle position
• Position database

Contact SkyCom S.à.r.l. Claude Lenert Tel. 352
769 231 skycom_at_skycom.lu
27
Just AVL or something more?

• Proprietary AVLassisted fleetmanagementapplicat
  ions only?
• What is the value chain in the TETRA case? Same
  as in GSM?
• Who will be the players in the TETRA market? Same
  as in GSM?
• What is the TETRA MoU role?

A TETRA "Mobile Location Services" Market?

• Safety services?
• Information services?
• Tracking services?
• Remote services?
• Billing services?

OR
Content Providers
Service Providers
Network Operator / Owner
Terminal
28
Conclusions

• TETRA is reality - existing fleet applications
  run over TETRA already today
• Interoperability of different 3rd party offerings
  not currently guaranteed
• Smart boxes" - functionality and terminal
  interfaces differ
• No specifications exist how to implement
  value-added features (integrated GPS etc.) into
  terminals
• Use of TETRA data services, especially SDS,
  uncoordinated
• Protocol development needed - native TETRA,
  adopting WAP telematics
• GSM Mobile Location Services market develops
  fast, however more oriented to the needs of
  individual users. TETRA has all the potential to
  become a superior choice to the professional
  users, individual and fleet
• Service provisioning vs. company run fleet
  applications?
• What else do professional users want than just
  fleet management?
• Innovative terminal development welcome - cf. GSM
  OEM modules
• Is there need for positioning TETRA handsets?
• Is there need for network-based positioning? Is
  it possible with TETRA?
• Contribute to the WAP telematics specification
  work
• Joint effort needed also here to create a
  multivendor TETRA market