This document provides an elementary description of the messaging system used during phase I of the Camera Phone Proof-of-Concept Project. It does not contain the detail of a formal system design document – in part because the details of commercial systems are not publicly available and are proprietary in nature. While the description of most components is generic, there is sufficient information to gain an understanding of the general system design of commercial MMS systems.

It should be noted that some system constraints are a function of specific user devices and provider service options.

B. ORGANIZATION OF DOCUMENT

Project Background
MMS System Primer
MMS System for Phase I of the Camera Phone Proof-of-Concept Project

C. REFERENCES

The following documents provide additional reference for the Camera Phone Proof-of-Concept project.

Operational Concept Description Document – Phase I
Technical Requirements Specification – Phase I
Operational Procedures Document – Phase I

D. DEFINITIONS

Commercial Mobile Radio Service (CMRS): An FCC designation for mobile wireless service offered by any carrier or licensee whose wireless network is connected to the public switched telephone network (PSTN) and/or is operated for profit.These companies include the traditional cellular and Personal Communications Systems (PCS) providers, such as Verizon Wireless, Sprint, Cingular, and T-Mobile.

Note: Nextel Communications is not a CMRS provider, but an Enhanced Specialized Mobile Radio (ESMR) provider. Traditionally, ESMR providers cater to business and industrial customers and have systems with either no connection or limited connection to the PSTN. These companies also operate in a different frequency bands than the cellular and PCS providers. However, Nextel has full connection to the PSTN and the operational distinction between Nextel and other CMRS providers has disappeared.

Short Message Service (SMS): The transmission of short text messages to and from a mobile phone, fax machine, and/or IP address. Messages must be no longer than 160 alphanumeric characters and contain no images or graphics. Once a message is sent, it is received by a provider’s

Short Message Service Center (SMSC), which must then deliver it to the appropriate mobile device.

Short Message Service Center (SMSC): A network element in a provider’s network that routes and delivers SMS messages

Multimedia Messaging Service (MMS): A store-and-forward method of transmitting graphics, video clips, sound files, and short text messages over wireless networks using the Wireless Application Protocol (WAP). Providers deploy special servers, dubbed Multimedia Messaging Service Centers (MMSC) to implement the offerings on their systems.

Multimedia Messaging Service Center (MMSC): A network element in a provider’s network that routes and delivers MMS messages

Internet Email Server: A network element in a provider’s or organization’s network that routes and delivers email messages

Simple Mail Transfer Protocol (SMTP): A client/server protocol utilized for email transmission across the Internet. Used by client applications to send email messages to email servers. It is also utilized for sending email messages between email servers (sending server acts like a client in this instance).

Post Office Protocol (POP): A communication protocol utilized by email client applications to retrieve email messages from an email server

Internet Message Access Protocol (IMAP): A communication protocol utilized by email client applications to retrieve email messages from an email server

HyperText Transport Protocol (HTTP): A request/response protocol between clients and servers. It is the primary method used to convey information on the World Wide Web.

Wireless Application Protocol (WAP): A protocol suite for applications that use wireless communication

Wireless Session Protocol (WSP): A protocol in the WAP suite – best thought of as a compressed version of HTTP

Internet Service Provider (ISP): A company that provides individual users and/or other organizations/companies access to the Internet. With access to the Internet, users can browse the World Wide Web (WWW), send, and receive e-mail, etc. ISPs that serve large companies often provide a direct connection from the company's networks to the Internet. ISPs themselves are connected to one another through Network Access Points (NAPs).

Wireless Internet Service Provider (WISP): An ISP providing its services via wireless networks

Network Service Provider (NSP): A company that provides Internet access to ISPs. Often referred to as backbone providers, NSPs offer direct access to the Internet backbone and the Network Access Points (NAPs).

Network Access Point (NAP): A public network exchange facility where Internet Service Providers (ISPs) can connect with one another in peering arrangements. The NAPs are a key component of the Internet backbone. They are also the points of most Internet congestion.

Field Users:These individuals are responsible for creating and distributing digital imagery from the field (e.g., the scene of an incident). During Phase I, these users will include Virginia State Police (VSP) Officers, VDOT Safety Service Patrol Officers, and field personnel from select towing and recovery companies.

Center Users:Personnel stationed at a fixed facility (e.g., the VDOT STC or the VSP dispatch facility). These individuals are recipients of the digital imagery supplied by field users. During Phase I, these users will include Virginia State Police Dispatchers, VDOT Smart Traffic Center (STC) Operators, and dispatchers from select towing and recovery companies.

Fixed Center Users:Center Users that rely on fixed communication services (e.g., wireline Internet access) and fixed computing resources (e.g., desktop computer)

Mobile Center Users:Center Users that rely on mobile communication services and mobile computing resources (e.g., PDA)

Note: The distinction between fixed and mobile center users is required during initial implementation since some participating agency facilities do not have dedicated Internet access.

Note: Mobile Center Users may include project oversight officials from the VSP.

II. BACKGROUND

The Camera Phone Proof-of-Concept Project will examine the utility of capturing and distributing incident scene imagery to towing and recovery providers, HAZMAT remediation contractors, and other follow-on response organizations. The premise of the project is that if this information is supplied in a timely fashion, the responders can correctly size and more rapidly configure their response to the scene from remote dispatch facilities. As suggested in Figures SD-1 and SD-2, a faster and properly calculated response will shorten the response time to an incident, which can subsequently shorten the duration of the incident and reduce traffic congestion.

Figure SD-1 represents a common dispatching scenario for towing and recovery services. In this instance, a VSP officer uses radio communication – typically some form of land mobile radio (LMR) – to request services from the Division 7 Dispatch Center and relay information about the incident scene.

Figure SD-1, Baseline Operations - VSP Field User

Figure SD-1, Baseline Operations - VSP Field User

The Division 7 Dispatch requests service from the appropriate towing company, which subsequently dispatches a truck. After arriving at the incident scene, it is determined that different/additional resources are required. Due to developing traffic congestion, it can take significantly longer for these new resources to arrive at the scene.

Figure SD-2 illustrates a similar scenario, including a modified flow of information and potential time-savings when supplementing radio communication with MMS messages.

Figure SD-2, Enhanced Operations - VSP Field User

Figure SD-2, Enhanced Operations - VSP Field User

In addition to requesting services using radio, the VSP officer uses a picture phone to assemble an annotated image (or images) of the incident scene. This multimedia information is then distributed among a predefined group of users. In this case, this would include users at the VSP Division 7 Dispatch Center, the VDOT STC, and the participating towing company dispatch facilities. The towing companies are the initial benefactors; they now have much more information with which to determine the proper resources for a response. The difference in elapsed time between scenarios (i.e. with and without MMS) could be significant.

The inclusion of MMS within this scenario is not intended to eliminate radio communication – only augment it. Since radio communication is still employed (and required) as part of the dispatch process, an initial dispatch of towing services may have occurred before the MMS message is composed, distributed, and analyzed. However, if an additional towing dispatch will eventually be required, the MMS system may enable a more timely and adequate response.

Note:While messages will be sent directly to the participating towing companies, they will not respond unless requested to do so by VSP Division 7 dispatch per standard operating procedures.

This scenario may be applicable for other field users (such as VDOT SSP), with possible variations to the radio dispatch procedures.

The purpose of this project is to facilitate the response of follow-on resources to incidents. This project has two key demonstration objectives. The first is to capture and distribute traffic incident scene imagery with relatively inexpensive and commercially available equipment and services. The second is to determine the value of this information to the noted responders.

This project will proceed in multiple phases. This phased approach will allow the demonstration to advance in manageable steps from simpler and smaller scale deployments in the initial phase (i.e., Phase I) to more technically complex and broader scenarios in the later phases. This document provides a high-level description of the messaging system used during Phase I.

III. MMS SYSTEM PRIMER

The communication infrastructure used to send and receive MMS messages will introduce various degrees of latency (i.e., the amount of time it takes for a message to traverse the network) and compatibility/consistency issues (i.e., the ability to receive a similar message by all users). These impacts will differ among service providers, location, time of day, and other parameters, and can be particularly apparent when sending messages between providers. The purpose of this primer is to provide an overview of major MMS communication infrastructure components and the process of sending and receiving an MMS message.

A. MMS Infrastructure Components

1. MMSC – Multimedia Messaging Service Center
Primary server utilized for MMS Messaging. Routes and delivers MMS messages. It can be viewed as having three primary components:

a) MMS Server
Core component of the MMSC – contains, tracks, routes, and stores the MMS messages within the carrier’s network

b) MMS Web Server
MMS Server module (or separate server) that sends and receives MMS messages to and from end user devices (phones, PDAs) within a carrier’s network, as well as between carriers. It sends MMS messages and images via HTTP and/or WAP (or, more accurately, replies to requests for MMS messages with the requested message/image). In addition, it can send notifications of new/incoming MMS messages to end user devices via WAP/WSP “PUSH”.

c) MMS Email Gateway
MMS Server module (or separate server) that sends and receives MMS messages to and from the Internet (via email). It converts the messages between the internal MMS/WSP/WAP format (within a carrier’s network) and the Internet-standard SMTP format.

There are MMSC implementations by multiple vendors, including Nokia, NowMMS, Exomi, and Lucent.

2. SMSC – Short Message Service Center
Primary server utilized for SMS Messaging. Routes and delivers SMS messages, both within a carrier’s network and between carriers (when authorized between carriers).

Notifications of new MMS messages can be delivered via SMS (and therefore via the SMSC). While technically MMS messages can be delivered via SMS, it is never implemented this way in practice.

Figure SD-3, MMS Infrastructure Components

Figure SD-3, MMS Infrastructure Components

B. MMS MESSAGE CONTENT

MMS messages can contain digital photographs, graphics, video clips, audio files, and/or short text messages. The content of any specific MMS message will depend on the features and capabilities of the source device - either camera phone or computer - and the service provider messaging system design, in particular, any conversion that occurs when the carrier sends messages to users on other networks.

C. MMS MESSAGE EXCHANGE

During the exchange of an MMS message between two end users, the MMS message will travel through a number of infrastructure components. This exchange can include multiple handoffs, as well as multiple conversions (e.g., converting to and from SMTP). Each of the steps in the message exchange introduces delays into the final delivery of the MMS message.

The five scenarios examined in this document are messaging between (1) two phones on the same provider network, (2) two phones on two different provider networks, (3) one phone on a provider network and one desktop computer on the Internet, (4) one desktop computer on the Internet and one phone on a provider network, and (5) one desktop computer on the Internet to another desktop computer on the Internet.

1. MMS Message Exchange: Intra-Provider – Phone-to-Phone
This scenario involves the sending of an MMS message by one camera phone to another camera phone on the same provider. The infrastructure architecture for this scenario includes the MMSC components (e.g., MMS Server and MMS Web Server) and SMSC components of one provider, as shown in figure SD-4.

Figure SD-4, Intra-Provider MMS Message Exchange

Figure SD-4, Intra-Provider MMS Message Exchange

a) Communication: Phone to MMSC (Send Message)
After the MMS message is composed and assembled/encoded by the user equipment (i.e. camera phone), the phone transmits the entire MMS message via an HTTP “POST” to the MMSC, as illustrated in Figure SD-5, below. Upon successful receipt, the MMSC replies to the phone within the open connection with an HTTP “OK” message.

b) Communication: MMSC to Phone (Message Notification)
After receiving an MMS message that is destined for one of the users on its network, the MMSC temporarily makes it accessible (i.e., publishes it) on a web server internal to the MMSC with a private URL specific to that particular MMS message. If the target phone is currently available on the network, the MMSC sends a WAP/WSP “PUSH” notification or an SMS notification to that phone, including the private URL in the notification.

Upon receiving a notification, most phones will notify the user of an incoming MMS message (e.g., ring, vibration). After alerting the user, some phones are configured to immediately retrieve the message from the MMSC (“immediate delivery”) – other phones/configurations will wait for the user to manually ask for the retrieval of the MMS message by the phone from the MMSC (“deferred delivery”).

c) Communication: Phone to MMSC (Retrieve Message)
To retrieve the message from the MMSC, the destination phone makes an HTTP “GET” request to the MMSC (via its MMS Web Server component) on the specified temporary private URL. The MMSC responds to the request with the actual content (text and multimedia attachments) of the MMS message. After successfully downloading the message, the destination phone makes a new HTTP “POST” to the MMSC with an acknowledgement of the receipt of the MMS message; the MMSC subsequently replies with an HTTP “OK”.

Depending on the provider’s system and the configuration of the relevant devices, the MMSC might use a WAP/WSP “PUSH” to notify the source phone (origin of the message) that the MMS message was received by the destination phone.

The MMS message is typically available at the private URL on the MMSC’s web server until either the destination phone acknowledges receipt of the message or until a provider-specified timeout, whichever occurs first.

Figure SD-5, Sequence Diagram: Intra-Provider MMS Message Exchange

Figure SD-5, Sequence Diagram: Intra-Provider MMS Message Exchange

2. MMS Message Exchange: Inter-Provider – Phone-to-Phone
This scenario involves the sending of an MMS message by one camera phone to another camera phone on a different provider network. The infrastructure architecture for this scenario is an extension of the Intra-provider scenario. It includes the MMSC components of each provider, as shown in Figure SD-6.

Figure SD-6, Inter-Provider MMS Message Exchange

Figure SD-6, Inter-Provider MMS Message Exchange

a) Communication: Phone to MMSC (Send Message)
This step operates in the same manner as with intra-provider communication.

b) Communication: MMSC to MMSC (Message Exchange)
When an MMSC receives an MMS message for a phone outside of its network, it contacts that carrier’s MMSC and transmits the MMS message to that MMSC. This transmission can be performed via HTTP or via SMTP, depending on the agreements between the carriers and the settings of each carrier’s MMSC.

c) Communication: MMSC to Phone (Message Notification)
This step operates in the same manner as with intra-provider communication.

d) Communication: Phone to MMSC (Retrieve Message)
This step operates in the same manner as with intra-provider communication.

Note: Notification to the sending phone of message delivery typically works between GSM-based providers, but not between CDMA providers, nor between a GSM provider and a CDMA provider

3. MMS Message Exchange - Internet - Phone-to-Computer
This scenario involves the sending of an MMS message by one camera phone to a non-phone user's Internet email address. The infrastructure architecture for this scenario is an extension of the Intra-provider scenario. It includes the MMSC components of one provider and the destination user's Internet Email Server, as shown in Figure SD-7.

Figure SD-7, Phone-to-Computer Internet MMS Message Exchange

Figure SD-7, Phone-to-Computer Internet MMS Message Exchange

a) Communication: Phone to MMSC (Send Message)
This step operates in the same manner as with intra-provider communication.

b) Communication: MMSC to Internet Email Server (Message Exchange)
The MMS Email Gateway (typically an internal module of the MMSC) converts the MMS message from its WSP/WAP message components into a single SMTP message. This SMTP message could contain text with encoded image/video/multimedia attachments, or text with a unique private URL back to the sending MMSC’s MMS Web Server – similar to the process described previously in Intra-Provider Message Notification. The sender listed within the new outgoing SMTP message is typically in the following format:

phonenumber@emailgatewayhost.wirelesscarrier.com

This is a valid email address – typically, the MMS email gateway will also receive email for this address, converting it into an MMS message, sending it to the specified phone.

The MMSC then connects to the recipient’s Internet Email Server. The communication between the MMS email gateway and the Internet email server is simply a typical SMTP exchange between two Internet SMTP servers. The originating server (in this case, the MMS Email Gateway) connects to the receiving server, identifies itself (using the SMTP “HELO”/”EHLO” message), identifies the sender and receiver of the incoming message (using the SMTP “MAIL FROM” message with the “sender” address of the source phone, and the SMTP “RCPT TO” message using the destination email address), and transmits the converted/SMTP-encoded MMS message (using the SMTP “DATA” message).

c) Communication: Computer to Internet Email Server / MMSC (Retrieve Message)
The destination computer contacts its Internet Email Server using POP, IMAP, or other email retrieval mechanisms, and retrieves the incoming SMTP-encoded email message. As previously determined by the sending MMSC, the email message may contain the entire MMS message, or a link back to the MMSC for message retrieval.

If the entire MMS message was included within the email message, the text of the MMS message is displayed to the user within the user’s email client application. Depending on the email client application settings (and the source carrier’s SMTP encoding settings), the multimedia attachments (images, video, etc.) may be displayed in-line with the text, or may be shown as clickable attachments to the message.

If only the text portion of the MMS message was included in the email message, a link to the full MMS message (including the multimedia content) is supplied within the email message. The user can then click on that link – when doing so, that URL is opened within the email application or within a web browser (depending on the application’s settings), and the full MMS message is displayed. This is similar to the process described previously in Intra-Provider Retrieve Message – the primary difference being that the retrieved message is formatted for a standard web browser instead of a phone display.

4. MMS Message Exchange – Internet – Computer-to-Phone
This scenario involves the sending of an MMS message by an Internet-based computer to a camera phone. The infrastructure architecture for this scenario is an extension of the Intra-provider scenario and the Phone-to-Computer Internet scenario. It includes the MMSC components of one provider and the destination user’s Internet Email Server, as shown in Figure SD-8.

Figure SD-8, Computer-to-Phone Internet MMS Message Exchange

Figure SD-8, Computer-to-Phone Internet MMS Message Exchange

a) Communication: Computer to Internet Email Server (Send Message)
The desktop computer user’s email application transmits the message to the Internet Email Server. This is done in a manner specific to the email application and Internet Email Server associated with the desktop computer.

b) Communication: Internet Email Server to MMSC (Message Exchange)
This is the inverse of the exchange detailed in the Phone-to-Computer scenario. The Internet Email Server communicates with the MMS Email Gateway – which emulates a standard SMTP-based Internet Email Server for incoming traffic – and sends the SMTP-encoded MMS message to the MMSC.

c) Communication: MMSC to Phone (Message Notification)
This step operates in the same manner as with intra-provider communication.

d) Communication: Phone to MMSC (Retrieve Message)
This step operates in the same manner as with intra-provider communication.

5. MMS Message Exchange – Internet-Only – Computer-to-Computer
This scenario involves the sending of an MMS message (or, more accurately, an email message with multimedia attachments) by an Internet-based computer to another Internet-based computer. The infrastructure architecture for this scenario is an extension of the Internet components of the previous scenarios.

a) Communication: Computer to Internet Email Server (Send Message)
This step operates in the same manner as with the computer-to-phone Internet communication.

b) Communication: Internet Email Server to Internet Email Server (Message Exchange)
This step operates in the same manner as with the computer-to-phone Internet communication.

c) Communication: Computer to Internet Email Server (Retrieve Message)
This step operates in the same manner as with the phone-to-computer Internet communication.

IV. MMS SYSTEM: CAMERA PHONE PROOF-OF-CONCEPT PROJECT

This section describes the MMS system used in the camera phone proof-of-concept project. This system includes a specific instance of the basic MMS communication infrastructure described in the MMS SYSTEM Primer . Details of the providers’ system components are proprietary – and therefore unknown. User infrastructure components include Internet email servers and Internet Web servers, which may be part of the network service provider’s system, or may be part of the organization’s in-house IT infrastructure. The project-specific system also includes a project-standard message composition, as well as a particular organizational message flow.

The users of this system include field users, fixed center users, and mobile center users.

Fixed Center Users:Center Users that rely on fixed communication services (e.g., wireline Internet access) and fixed computing resources (e.g., desktop computer)

Mobile Center Users:Center Users that rely on mobile communication services and mobile computing resources (e.g., PDA)

Note: The distinction between fixed and mobile center users is required during initial implementation since some participating agency facilities do not have dedicated Internet access.

Note: Mobile Center Users may include project oversight officials from the VSP.

The following subsections describe the project-specific system infrastructure and user/device associations, message composition, and system message flow. Information is current as of the release of this document.

A. Project Specific System Infrastructure and USER/Device Associations
This section details the project-specific MMS system infrastructure, as well as the devices associated with each of project’s users. These project-specific details are exemplified in Figure SD-9.

Figure SD-9, Project-Specific MMS System Deployment and Device Associations

Figure SD-9, Project-Specific MMS System Deployment and Device Associations

The specific numbers and types of MMS equipment and services are currently unknown. Equipment will include more than one device, and service will include more than one provider (providers could include Nextel, Verizon Wireless, Cingular, Sprint, and/or T-Mobile).

1. Field Users

As of the release of this document, the camera phone(s) and service(s) to be used by the “Field Users” have yet to be determined (i.e., phones and services are TBD and therefore details of these system components are unknown). In addition, it should be noted that for any group of field users, the end user devices could be different phones with different service plans.

a) VDOT SSP Officers

End User Device
Camera Phone & Service: TBD
- Type 1 (phone & service)
- Type 2 (phone & service)
- and/or Type 3 (pho ne & service

b) VSP Officers

End User Device
Camera Phone & Service: TBD
- Type 1 (phone & service)
- Type 2 (phone & service)
- and/or Type 3 (pho ne & service)

c) Towing Company A Drivers

End User Device
- Camera Phone & Service: TBD
  - Type 1 (phone & service)
  - Type 2 (phone & service)
  - and/or Type 3 (pho ne & service

d) Towing Company B Drivers

End User Device
- Camera Phone & Service: TBD
  - Type 1 (phone & service)
  - Type 2 (phone & service)
  - and/or Type 3 (phone & service

e) Towing Company C Drivers

End User Device
- Camera Phone & Service: TBD
  - Type 1 (phone & service)
  - Type 2 (phone & service)
  - and/or Type 3 (phone & service)

2. Fixed Center UsersFixed Center Users rely on existing infrastructure at their respective locations. The following information is based upon initial discussions and meetings with the respective organizations, and may not reflect the detailed specifics or the current status of the organizational centers (due to changes in infrastructure and/or changes in Internet security policy).

a) VDOT STC

Infrastructure
- Internet Service: Yes (ISP and speed unknown)
- Internet Email Server: Unknown (may be in-house or ISP-based)
End User Device
- Desktop PC: Yes (unknown hardware and email client)

b) VSP Division 7 Dispatch Center

Infrastructure
- Internet Service: No (building has connectivity, however dispatch center is barred due to organizational security policies)
- Internet Email Server: None accessible from center network
End User device
- Desktop PC: Yes, but cannot access the network (nor can it be connected to any wireless network due to security policies)
See Mobile Center Users, below. VSP D7D could be a Mobile Center User if there is no Internet access/service available for use.

c) Tow Company A Dispatch

Infrastructure
- Internet Service: Yes (ISP and speed unknown)
- Internet Email Server: Unknown (probably ISP-based)
End User device
- Desktop PC: Yes (unknown hardware and email client)

d) Tow Company B Dispatch

Infrastructure
- Internet Service: Yes (ISP and speed unknown)
- Internet Email Server: Unknown (probably ISP-based)
End User device
- Desktop PC: Yes (unknown hardware and email client)

e) Tow Company C Dispatch

Infrastructure
- Internet Service: No (open to the possibility of getting Internet connectivity for the center)
- Internet Email Server: None (will probably be ISP-based if center gets Internet service)
End User device
- Desktop PC: Yes, but does not have Internet connectivity (unknown hardware)
See Mobile Center Users, below. One towing company may be a Mobile Center User if there is no Internet access/service available for use.

3. Mobile Center Users

Mobile Center Users rely on CMRS to provide Internet connectivity. Connectivity will depend on signal strength within the center of issue.

a) VSP Division 7 Dispatch Center

Infrastructure
- Internet Service: Yes (via CMRS, data rate determined by device and service)
- Internet Email Server: Yes (CMRS -based
End User Device
- PDA: Specific device TBD (If PDA can do MMS directly, it operates like a camera phone – otherwise, it works like a desktop utilizing an email server]
  - Can potentially sync with desktop in order to transfer (and view) image on desktop’s larger screen – however, security policy may prohibit such a connection.
  See Fixed Center Users, above. VSP D7D could be a Fixed Center User if there is Internet access/service available for use.

b) Towing Company C Dispatch

Infrastructure
- Internet Service: Yes (via CMRS, speed determined by device and service)
- Internet Email Server: Yes (CMRS -bas
End User Device
- PDA: Specific device TBD(If PDA can do MMS directly, it operates like a camera phone – otherwise, it works like a desktop utilizing an email server)
See Fixed Center Users, above. The Towing Company without Internet service may have service installed, and therefore would become a Fixed Center User.

B. Project Specific Message Composition

This section describes the specific message composition of MMS messages to be used during this project.

1. Message Content / Payload

Each message will include text indicating the location of the incident. This text could be located above or below any image within the message, or in the subject line of the message.

Each message should include at least one image. While some devices/carriers can include multiple images per message, these multi-image messages may not display correctly on other devices and/or may involve additional viewing procedures, and so should be avoided for the purposes of this phase of the project. In addition, while it is possible to send a message that does not include any image (or multimedia attachment – i.e. just send text), this should only be done as a follow-up to a previous message that included an image incident.

Note:Follow-up messages should be sent upon request. Secondary messaging that is not requested, or messaging that occurs too frequently, may disrupt or confuse the dispatch process.

2. Message Destination / Group Lists

Each message will be addressed to a single destination, which will be an address book entry programmed within the device and/or with the device’s carrier. This entry may be a list of destination addresses – stored on the device or with the carrier. This entry also may be a single email address for a mailing list hosted on an Internet Email Server. Sending to this entry will distribute the message to all the devices in the project.

While different sub-groups may be created within the distribution lists (e.g. VSP Users, Towing Company B Users, VSP Commanders, Verizon Users, etc.), this is beyond the scope of Phase I of the project – the core scenario is the sending of each message to all devices.

3. Composition Process

The composition process will vary with the selected devices and carrier service offerings. Details of the process will be identified in the Operational Procedures Document.

C. Project Specific Message Flow

This section describes the specific message flow of MMS messages utilized during this project. Definitions and associations previously outlined in the document help provide a mapping between the project-specific entities.

Table SD-1 outlines the message exchange for all users in the project-specific system – based upon initial discussions and estimates. As the user devices and carriers are still TDB, the information within this table is preliminary.

Message Exchange: A = intrA-provider, E = intEr-provider P = Phone-to-computer, C = Computer-to-phone, I = Internet-Only
	*Field Users*					*Center Users*
	VDOT SSP	VSP Ofc.	TowA Drvr	TowB Drvr	TowC Drvr	VDOT STC	VSP D7D	TowA Disp.	TowB Disp.	TowC Disp.
VDOT SSP	AE	AE	AE	AE	AE	P	AE	P	P	AE
VSP Officers	AE	AE	AE	AE	AE	P	AE	P	P	AE
TowingA Drivers	AE	AE	AE	AE	AE	P	AE	P	P	AE
TowingB Drivers	AE	AE	AE	AE	AE	P	AE	P	P	AE
TowingC Drivers	AE	AE	AE	AE	AE	P	AE	P	P	AE
VDOT STC	C	C	C	C	C	*	C	I	I	C
VSP D7 Dispatch	AE	AE	AE	AE	AE	P	*	P	P	AE
TowingA Dispatch	C	C	C	C	C	I	C	*	I	C
TowingB Dispatch	C	C	C	C	C	I	C	I	*	C
TowingC Dispatch	AE	AE	AE	AE	AE	P	AE	P	P	*

Table SD-1, Project-Specific Message Exchange

We can examine how Table SD-1 applies to the “Enhanced Operations – VSP Field User” scenario depicted in Figure SD-2. Utilizing a camera phone, the VSP Officer transmits an MMS message to three locations. For the first destination, VSP Division 7 Dispatch (a PDA Phone), the MMS message is exchanged via either the Intra-Provider scenario (“A”) or Inter-Provider scenario (“E”). For the second destination, the VDOT STC, the MMS message is exchanged via the Phone-to-computer scenario (“P”). For the third destination, TowingA Dispatch, the MMS message is exchanged via the Phone-to-computer scenario (“P”).

D. Future Plans

Phase I of this study relies on provider resources (e.g. MMSC, Email Servers, etc.), for many message handling functions, and therefore many message handling capabilities (send, store, distribute) are limited to the provider’s implementation. Based upon the results of this current phase, Phase II might involve the development and use of messaging servers (such as an MMSC) owned and operated by CapWIN in order to optimize and customize message handling.

Table or Contents | Previous | Next

System Description Document - Phase 1 (Final)

Table of Contents

I. INTRODUCTION

A. PURPOSE & SCOPE