ETSI TS 170 016 V3.1.1 (2009-02)
Project MESA; Technical Specification Group - System; Functional Requirements Definition
Project MESA; Technical Specification Group - System; Functional Requirements Definition
DTS/MESA-SYS0070016v311
General Information
Standards Content (Sample)
Technical Specification
Project MESA;
Technical Specification Group - System;
Functional Requirements Definition
2 ETSI TS 170 016 V3.1.1 (2009-02)
Reference
DTS/MESA-SYS0070016v311
Keywords
application, interoperability, network,
performance, security, service, TMN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 170 016 V3.1.1 (2009-02)
Contents
Intellectual Property Rights.4
Foreword.4
Introduction .4
1 Scope.5
2 References.5
2.1 Normative references.5
2.2 Informative references.5
3 Definitions and abbreviations.5
3.1 Definitions.5
3.2 Abbreviations for Requirement Identification.7
4 Functional Requirements.7
4.1 Core Functional Requirements.8
4.2 Other Requirements.20
History .21
ETSI
4 ETSI TS 170 016 V3.1.1 (2009-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by Public Safety Partnership Project (MESA).
The contents of the present document are subject to continuing work within the Specification Group (SG) and may
change following formal SG approval. Should the SG modify the contents of the present document, it will be re-
released by the SG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to SG for information;
2 presented to SG for approval;
3 or greater indicates SG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
The functional requirements in the present document were captured through a series of collaborative workshops over
several months that involved members of the Public Safety community as represented by the MESA Service
Specifications Group (SSG), and infrastructure vendors and operators in the wireless industry as represented by the
MESA Technical Specifications group. Using the Statement of Requirements (TS 170 001 [1]) developed by the MESA
SSG and using the MESA Network Architecture (MESA 70.015 [i.1]) as a guide, the MESA group derived the
functional requirements found in the present document.
ETSI
5 ETSI TS 170 016 V3.1.1 (2009-02)
1 Scope
The present document give guidelines for the functional requirements required for a MESA system that is consistent
with the Service Specification Group's Statement of Requirements (TS 170 001 [1]) and the Technical Specification
Groups Network Architecture (MESA 70.015 [i.1]). The present document is intended to be the input into a gap
analysis of existing standards and technologies with an ultimate goal to update the existing standards and technologies
to be fully compliant with the functional requirements in the present document.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TS 170 001: "Project MESA; Service Specification Group - Services and Applications;
Statement of Requirements", MESA TS 70.001.
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] MESA 70.015: " Project MESA; Technical Specification Group - System; System and Network
Architecture ".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
airlink resources: available throughput (voice and data) for a given location that can be shared across all users
ETSI
6 ETSI TS 170 016 V3.1.1 (2009-02)
authorized principal: principal with permissions to perform specific action(s) or receive specific information (Source
OMA Dictionary)
bandwidth: amount of spectrum required for the system
NOTE: See also Channel Bandwidth, Radio Bandwidth.
channel bandwidth: amount of spectrum required for a single channel of the system
components: individual parts that together make up the entire system, generally inclusive of devices
NOTE: See also Nodes, Network Elements.
cooperative use: system able to operate overlapped with another system with the components of each system
cooperating, not interfering
dynamic bandwidth: allows bandwidth to be changed to allow more capacity for priority users
effective user data rate: effective throughput (voice and data) as perceived by an end user
forward compatibility: ability for a system to operate with future protocols of itself
logical networks: AWN, EAN, JAN, IAN, and PAN as described in the MESA System and Network Architecture
Document
MESA system: complete set of integrated components that provide full communication functionality meeting the
MESA Statement of Requirements
network elements: individual parts, that together, make up the entire system, excluding devices or clients
NOTE: See also Components, Nodes.
network functions: user transparent functions of the system, such as authentication proxying for single sign on,
mobility support, policy enforcement, etc.
nodes: individual parts that together make up the entire system inclusive of devices and clients
NOTE: See also, Components, Network Elements.
Off-Net: "Off Network", meaning the user does not have access to fixed network services, and access to services is
restricted to those that reside in the device or functioning wireless transmitters (vehicle or wireless site)
On-Net: "On Network", meaning the user has access to the fixed network services that reside in data or switching
centers
peer-to-peer: service within a device that communicates directly with other devices, and does not communicate with
any network component
NOTE: Note that this does not preclude the communication from being carried by the network, only that
application level messaging is originated and terminated by services resident on the device.
principal: an entity that has an identity, that is capable of providing consent and other data, and to which authenticated
actions are done on its behalf
EXAMPLE: Examples of principals include an individual user, a group of individuals, a corporation, service
enablers/applications, system entities and other legal entities. (Source OMA Dictionary).
radio bandwidth: amount of spectrum required for the system (inclusive of all channels used)
run-time: commands are executed as they are given
single sign on: ability for the user to provide authentication credentials once to the system, and the system proxies those
credentials to any application or services requiring credentials
system: unless otherwise specified, system refers to the MESA system
ETSI
7 ETSI TS 170 016 V3.1.1 (2009-02)
untrusted connections: connections where the connecting parties have not conducted prior mutual authentication and
authorization
3.2 Abbreviations for Requirement Identification
Requirement format is of the form: xx-xxx-nnn (where x are letters, and n are numbers). The format structure consists
of a requirement classification, which is a two letter prefix identifying how the requirement will be documented;
followed by three letters identifying functional categorizations of the requirements; followed by a three digit number
that allows each requirement to be uniquely identified.
For the purposes of identifying requirements, the following requirement abbreviations apply:
Requirement Classification (first two letter identifiers):
DR Documentation Requirement
DC Design Consideration Requirement
IR Implementation Requirement (Requirement is incumbent upon the entities implementing the
technology)
FR Functional Requirement
LMR Land Mobile Radio
Requirement Functional Categorization (middle three letter identifiers):
ASC (xx-ASC-xxx) Requirement originating from the team looking at Applications and Services
implications and interactions
AWN (xx-AWN-xxx) Requirements originating from the team looking at Ancillary Wireless Network
implications and interactions
EUD (xx-EUD-xxx) Requirements originating from the team looking at End User Device implications and
interactions Implementation Requirement (Requirement is incumbent upon the entities
implementing the technology)
IOP (xx-IOP-xxx) Requirements originating from the team looking at interoperability implications and
interactions
JRA (xx-JRA-xxx) Requirements generated from the first round of Joint Reviews
LOG (xx-LOG-xxx) Requirements originating from the team looking at Logical Networks implications and
interactions
NMC (xx-NMC-xxx) Requirements Generated by team looking at Network Control and Network
Management implications and interactions
Sxx (xx-Sxx-xxx) Requirements originating from the team looking at Security implications and
interactions
Security Subsections Categorization (xx of the Sxx identifier):
SAU Authentication
SAV Availability
SCO Confidentiality
SGE General Security
SIN Integrity
SMA Management
SNR Non-repudiation
STR Traceability
4 Functional Requirements
The following tables capture the Functional Requirements for the Project MESA system.
ETSI
8 ETSI TS 170 016 V3.1.1 (2009-02)
4.1 Core Functional Requirements
Table 1 consists of the functional requirements that would apply to developing standards and specifications for a MESA
system.
Table 1: Functional Requirements
Functional Req. ID Associated Mesa Associated User
Functional Requirement Text
No. SoR Sections Seq IDs
Authorized principals shall be able to add, modify, or create and store
in real-time, via an application or service, new data in database(s), files
FR-ASC-001 MesaSoR.5.54 282
and automated systems, needed to successfully execute the
application or service.
Authorized principals shall be able to retrieve in real-time, via an
application or service, any data from database(s), files and automated
FR-ASC-002 MesaSoR.5.54 283
systems, needed to successfully execute the application or service, by
the authorized principals.
Authorized principals shall be able to modify in real-time, via an
application or service, any data in database(s), files and automated
FR-ASC-003 MesaSoR.5.54 284
systems, needed to successfully execute the application or service, by
the authorized principals.
Authorized principals shall be able to add, modify or delete in real-time,
via an application or service, any data in database(s), files and
FR-ASC-004
MesaSoR.5.54 285
automated systems, needed to be removed in order to successfully
execute the application or service, by the authorized principals.
Authorized principals shall be able to monitor and control features and
FR-ASC-005 functions of remote devices such as robotic devices, unmanned units, MesaSoR.5.54 286
including but not limited to, via an application or service.
The applications and services that involve database transactions, file
downloads, file uploads, remote control, including but not limited to,
FR-ASC-006 shall function on the logical network, transparently to and irrespective MesaSoR.5.54 287
of the different layer protocols of the logical network, below the
application layer.
1. Applications and services shall be designed in such way that they
can be distributed to allow access from any end user devices.
FR-ASC-007 MesaSoR.5.54 288
2. Interoperable Applications and services should have a well-defined
subset of mandatory features.
The user access to applications and services (which may vary based
on client and device type) should allow the applications and services to
FR-ASC-008 MesaSoR.5.54 289
be clearly identifiable, easy to access, and available for use by any
authorized user.
Applications and services provided by the home network should be
available to users in a visited network, subject to user's SLA,
FR-ASC-009 authorization policies provisioned in both the visited network and the MesaSoR.5.54 290
home network and the jurisdiction agreements, and while maintaining
confidentiality and integrity, once a user has been authenticated.
Application and services provided by the visited network should be
available to users in a visited network, subject to user's SLA,
FR-ASC-010 MesaSoR.5.54 291
authorization policies provisioned in the visited network, and the
jurisdiction agreements.
To allow the sharing of data between agencies, applications and
FR-ASC-011 services shall support data exchanges via direct connections and/or MesaSoR.5.54 292
via intermediary logical network resources.
1. Application and services shall support the assignment of roles
(e.g. administrator, manager, delegate, user), rights (e.g. scope of
accessible information, priority, authorization levels) and
FR-ASC-012 MesaSoR.5.54 293
responsibilities (e.g. obligations).
2. Roles, rights and responsibilities may be assigned to various
principals (e.g. individual users, groups of users, or applications).
ETSI
9 ETSI TS 170 016 V3.1.1 (2009-02)
Functional Req. ID Associated Mesa Associated User
Functional Requirement Text
No. SoR Sections Seq IDs
Any applications and services shall implement standards that include
mechanisms for initiating requests towards other resources in the
FR-ASC-020 MesaSoR.5.58 307
logical network, and accepting responses from the same and/or other
resources in the logical network.
Any applications and services shall implement standards that include
mechanisms for subscribing to external events produced in or
FR-ASC-021 transmitted by other resources in the logical network, and mechanisms MesaSoR.5.58 308
that allow them to receive notifications of events they have subscribed
to.
Applications and services should be able to adapt the manner in which
information is presented, accepted and transmitted in either direction,
FR-ASC-022 by the capability of the device or system that the user has access to MesaSoR.5.58 309
(e.g. data terminals, subscriber radio, computer equipment) and the
portability of the device or system (e.g. vehicle-mounted or hand-held).
Access to applications and services shall be allowed only to
authenticated users, authorized for the use for specific applications
FR-ASC-023 MesaSoR.5.58 310
and services, and/or specific features of such applications and
services.
Once authenticated, a user should be able to access other services for
FR-ASC-024 MesaSoR.5.58 311
which he/she is authorized, without the need to re-authenticate.
Applications and services should be designed to allow devices and/or
FR-ASC-040 MesaSoR.5.52(b) 263
systems to use their maximum capabilities.
The applications and services should include, where applicable, the
capability to process and/or accept, transcode, and transmit data in
different media formats (e.g. voice, infrared video, text) with
FR-ASC-041 MesaSoR.5.52(b) 264
low-latency, and provide the end-user with the best possible user
experience when accepting from and/or presenting the data to the
user.
The applications and services should support peer-to-peer
communications between resources in the logical network, including
FR-ASC-042 MesaSoR.5.52(b) 265
user-to-user communications, using a variety of media formats
(e.g. voice, infrared video, text).
Applications and services that initiate and/or accept transmission of
FR-ASC-043 data in multiple media formats, while taking advantage of MesaSoR.5.52(b) 266
broadcast/multicast capabilities, shall be available.
Services should include the support for simultaneous instantiation and
execution of applications that may access, process, present or transmit
FR-ASC-044 MesaSoR.5.52(b) 267
data in different media formats (voice, data, video), if the devices and
systems they use have such capabilities.
Applications and/or services should be able to access and use a
device's local capability to indicate its geographical position, in order to
FR-ASC-060 MesaSoR.5.56 300
be able to process, transmit and present the device's location to
authorized principals.
Applications and services should be able to have a choice in obtaining
a user's position from the user's device or from a central resource
FR-ASC-061 MesaSoR.5.56 301
available in the logical network (a location server) or from a central
resource in a different associated logical network.
Location based applications and/or services should allow end-users to
FR-ASC-062 MesaSoR.5.56 302
register for (subscribe to) location information of other end-users.
Location based applications and/or services should include capabilities
to determine and communicate a device's geographical location
FR-ASC-063 information, including altitude, and/or its relative position to identifiable MesaSoR.5.56 303
points of reference, even in the case of an in-building located device
deprived of access to satellite communications.
Application and services should facilitate user access to information, by
FR-ASC-080 using the device and logical network capabilities available at any given MesaSoR.5.30 45
moment in time.
Application and services should support information store-and-forward
(at any time on the local device, and. when on-net, in a different
FR-ASC-081 MesaSoR.5.30 46
resource in the logical network), in order to handle situations in which
information may not be able to immediately be transmitted to the
destination (e.g. the transmitting or the receiving device is off-net).
Applications and services should support on demand retrieval of
FR-ASC-082 information that has been cached on the user's device for the user's MesaSoR.5.30 47
consumption.
ETSI
10 ETSI TS 170 016 V3.1.1 (2009-02)
Functional Req. ID Associated Mesa Associated User
Functional Requirement Text
No. SoR Sections Seq IDs
Applications and services should support retrieval of information that
has been cached on a resource in the logical network, to support the
FR-ASC-083 MesaSoR.5.30 48
case when the device the user is using was off-net, and is later
reversing to an on-net situation.
Applications and services should be able to facilitate the advertisement
FR-ASC-084 of the presence, availability, and status of a user (e.g. in the midst of MesaSoR.5.30 49
an action, in transit, in a communication exchange, in a meeting).
Applications and services should be able to discover the advertisement
FR-ASC-085 of the presence, availability and status of a user (e.g. in the midst of an MesaSoR.5.30 50
action, in transit, in a communication exchange, in a meeting).
Application and services should use device and logical network
FR-ASC-100 capabilities of point-to-point and point-to-multipoint voice MesaSoR.5.32 55
communications.
Applications and services that use point-to-multipoint communication
capabilities should include features for control for an authorized
principal, if several of the points that are taking part in the application
FR-ASC-101 MesaSoR.5.32 56
or service are capable of initiating communications to other points
(e.g. users).
NOTE: This feature is the equivalent of a moderator in a meeting.
Applications and services that use point-to-point and/or point-to-
multipoint communication capabilities should include features allowing
FR-ASC-102 MesaSoR.5.32 57
an authorized principal to add and/or remove communication points to
an existing group of communication points (e.g. users).
Applications and services that use point-to-point and/or point-to-
multipoint communication capabilities should include features allowing
FR-ASC-103 MesaSoR.5.32 58
a member of a group of communication points to indicate their
availability to participate in communications.
Applications and services that use point-to-point and/or point-to-
multipoint communication capabilities should include features allowing
FR-ASC-104 a member of a group of communication points to discover their MesaSoR.5.32 59
availability of other members of the group to participate in
communications.
Applications and services that use point-to-point and/or point-to-
multipoint communication capabilities should include features allowing
FR-ASC-105 MesaSoR.5.32 60
members of a group of communication points to initiate and use data
transfer channels, simultaneous with their communication channels.
Applications and services should be able to detect and act upon the
FR-ASC-120 MesaSoR.5.52(a) 255
activation of a panic button (local panic button activation).
Applications and services should be able to detect and act upon a
notification triggered by the activation of a panic button that was
FR-ASC-121 activated from a device or resource in the logical network different than MesaSoR.5.52(a) 256
the device used in the execution of the application (remote panic
button activation).
Applications and services should be able to execute, without any user
FR-ASC-122 intervention, policy rules included in a policy associated with the MesaSoR.5.52(a) 257
activation of the panic activation button.
The actions triggered by a Panic Button activation should be
configurable to cover different possible situations. Note: Policy rules
could be provided to include evaluation of condition and context, and
execution of actions based on the results of the evaluation, such as
FR-ASC-123 re-prioritizing resources on the used device, relinquishing resources in MesaSoR.5.52(a) 258
the logical network that the application was using, saving and/or
immediately relaying critical data cached, switching to different
communication channels or from point-to-point to point-to-mulitpoint
voice communication.
Applications and services should rely on nationally or internationally
FR-ASC-140 mobile applications and services enabler recognized standards, MesaSoR.5.4 110
wherever possible.
1. Applications should be developed independent of underlying layers
protocols, while supporting multiple realizations depending on the
specifics of the physical network they will be deployed on.
FR-ASC-141 MesaSoR.5.4 111
2. When multiple protocols are supported, the choice of the appropriate
protocol should be based on optimizing the performance of the
application, without end-user involvement.
ETSI
11 ETSI TS 170 016 V3.1.1 (2009-02)
Functional Req. ID Associated Mesa Associated User
Functional Requirement Text
No. SoR Sections Seq IDs
Application and services shall conform to the security policies and
FR-ASC-161 requirements imposed by the logical networks in which they perform, MesaSoR.5.45 187
and/or by the entities that are involved in the service.
Enabling and disabling tracing capabilities at all tracing-capable MESA
FR-ASC-163 MesaSoR.5.45 189
components should be supported.
Secure authorized applications shall be able to trigger service-level
tracing, which will result in tracing being performed at all MESA
FR-ASC-164 MesaSoR.5.45 190
components that the service is traversing, which have been previously
enabled for tracing.
FR-AWN-001 The AWN shall transport end user voice and data communications. MesaSoR.5.29 32
MesaSoR.5.29 33
FR-AWN-002 The AWN shall support IP-based data communications.
MesaSoR.5.8 364
FR-AWN-003 The AWN Core shall be able to interface to the JAN core network. MesaSoR.5.29 34
The AWN should be able to provide backhaul for the IAN when/if the
FR-AWN-004 MesaSoR.5.29 35
JAN is unavailable.
The AWN shall interface to the IAN in a manner that is transparent to
FR-AWN-005 MesaSoR.5.25 30
end user IP applications.
The AWN airlinks and the AWN core networks should support Public
Safety QoS and SLA parameters, so that public safety applications are
FR-AWN-006 MesaSoR.5.25 31
supported transparently and public safety users can be prioritized
across all networks.
The AWN should be based on a nationally or internationally recognized
FR-AWN-008 MesaSoR.5.4 103
wireless system standards and equipment.
The device shall be capable of authenticating itself in the logical
FR-EUD-001 MesaSoR.5.8 312
network(s) being accessed.
The device shall be capable of authorizing the user in the logical
FR-EUD-002 MesaSoR.5.8 313
network(s) being accessed.
The device shall not allow access to the capabilities to be supported
FR-EUD-003 MesaSoR.5.8 314
without authentication and authorization.
The device shall be capable of identifying the core network of the
FR-EUD-005 MesaSoR.5.8 315
logical network being accessed and operate accordingly.
The device shall be capable of accessing the services of external
FR-EUD-006 MesaSoR.5.8 316
networks (such as, but not limited to: P25, TETRA, and AWN).
The device shall be capable of inter-working and interoperating with
FR-EUD-007 appropriate external networks (such as, but not limited to: P25, MesaSoR.5.8 317
TETRA, and AWN).
The device shall be capable of interfacing with inter-working and
FR-EUD-008 MesaSoR.5.8 318
interoperability nodes deployed in the network.
The device shall be capable of determining its geographical location.
FR-EUD-009 The accuracy should be within 1 meter, but shall be at least as MesaSoR.5.56 296
accurate as existing E911 solutions.
The device shall provide its geographical position location information
FR-EUD-010 to the authorized location based services within the Project MESA MesaSoR.5.56 297
system.
The device shall be capable of determining geographical position
FR-EUD-011 location information from associated networks for supporting the MesaSoR.5.56 298
location based services.
The device shall be able to determine its location inside buildings along
FR-EUD-012 MesaSoR.5.56 299
with the altitude component in future.
The device shall be able to access logical network(s) supported in the
FR-EUD-013 MesaSoR.5.8 319
device.
The device shall be able to access services and applications supported
FR-EUD-014 MesaSoR.5.30 40
by the accessible logical and external networks.
FR-EUD-015 The device shall support point-to-point communications. MesaSoR.5.32 52
FR-EUD-016 The device shall support point-to-multipoint communications. MesaSoR.5.32 53
FR-EUD-017 The device shall provide the use with ability to declare panic situation. MesaSoR.5.52(a) 251
The device shall notify the service and/or network of panic situation
FR-EUD-018 MesaSoR.5.52(a) 253
declaration from the user.
The device shall prioritize and manage the resources during the panic
FR-EUD-019 MesaSoR.5.52(a) 254
situation.
The device shall be compliant to the regulations that apply to the
FR-EUD-022 MesaSoR.5.17 11
physical network(s) being accessed.
The device shall comply with applicable and relevant emission limits for
FR-EUD-024 MesaSoR.5.18 13
its band of operation.
FR-EUD-026 The device shall comply with applicable RF safety regulations. MesaSoR.5.18 16
ETSI
12 ETSI TS 170 016 V3.1.1 (2009-02)
Functional Req. ID Associated Mesa Associated User
Functional Requirement Text
No. SoR Sections Seq IDs
The device shall recognize transmission delays introduced in the
FR-EUD-027 network and treat the information according to determined classes of MesaSoR.5.57 304
service.
The device shall be capable of accessing all services authorized to the
FR-EUD-028 MesaSoR.5.8 320
user and upon successful authentication.
The device shall be able to establish a network with other peer devices
FR-EUD-032 MesaSoR.5.30 41
and utilize services and applications available to that peer network.
The device shall be compliant to the regional safety standards such as
FR-EUD-036 MesaSoR.5.18 17
European Commission or Underwriters Laboratory.
The device shall be able to select the most efficient logical network for
FR-EUD-039 communication and transparently switch to more effective logical MesaSoR.5.8 321
network.
The device shall allow the user to select logical network access by
FR-EUD-042 MesaSoR.5.8 322
overriding the automatic selection procedure.
The device shall support administration functions initiated by the
FR-EUD-043 MesaSoR.5.8 323
network, end user or the device itself.
The device shall collect and report errors to the service or
FR-EUD-044 MesaSoR.5.8 324
administration control.
The MESA systems shall use IP (Internet Protocol) as the common
layer 3 interface. Physical and Link Layer interconnections between
FR-IOP-001 MesaSoR.5.4 104
network components (excluding wireless components) shall be based
on the 802.3 (Ethernet) standards.
The network must support the ability to add new infrastructure
components (with minimal configuration or setup required) into the
FR-IOP-003 MesaSoR.5.7 327
existing infrastructure and become operational with little to no
configuration or setup required.
The network shall be capable of dynamically scaling to accommodate a
growing number of users. This scaling shall not sacrifice any mission-
FR-IOP-004 MesaSoR.5.7 328
critical services, applications or network functionality, and should not
sacrifice any services, applications or network functionality.
Common layer 1-2 interface specifications shall be developed. If more
FR-IOP-005 than one such specification is implemented in a user device, the MesaSoR.5.9 365
infrastructure must also accommodate multiple modes.
The common layer 1-2 interface shall allow for infrastructureless
FR-IOP-006 MesaSoR.5.9 366
communications between user devices.
Project MESA specifications shall provide network interfaces to legacy
FR-IOP-008 systems that provide backwards compatibility between MESA devices MesaSoR.5.20 23
and legacy devices.
Project MESA specifications must provide forward compatibility
FR-IOP-009 (including network components, applications and services, and devices MesaSoR.5.21 27
used on the network).
Project MESA specifications shall provide a nonproprietary, publicly
FR-IOP-010 available interface through which non-Project MESA compliant MesaSoR.5.21 28
systems can connect.
A public safety user shall be authenticated before accessing network
FR-IOP-011 MesaSoR.5.44 162
resources.
A public safety user shall be able to authenticate from any portion of
FR-IOP-012 MesaSoR.5.44 163
the network.
A public safety user shall be authorized to use specified network
FR-IOP-013 MesaSoR.5.44 164
resources once authenticated.
A public safety user shall be able to gain authorization from any portion
FR-IOP-014 MesaSoR.5.44 165
of the network.
Access to (seeing the contents of) traffic traversing the network or
FR-IOP-015 public safety segments of shared networks shall be limited to MesaSoR.5.44 166
authorized recipients based upon their need and right to know.
The traffic traversing the network shall be immune to attacks against its
FR-IOP-016 MesaSoR.5.44 167
integrity.
Authentication, authorization, and other security attributes shall be
FR-IOP-017 decoupled (independent of each other and the transport) such that a MesaSoR.5.44 168
federated approach to security is possible.
Security specifications shall be capable of scaling to its appropriate
FR-IOP-018 context, i.e. local, county, state, regional, federal, etc., such that MesaSoR.5.44 169
performance of the security specifications is not compromised.
The MESA system shall facilitate the sharing of spectrum with other
FR-JRA-001 MesaSoR.5.15 7
radio technologies.
ETSI
13 ETSI TS 170 016 V3.1.1 (2009-02)
Functional Req. ID Associated Mesa Associated User
Functional Requirement Text
No. SoR Sections Seq IDs
The MESA system shall provide data interoperability with data systems
FR-JRA-002 based on legacy public safety standards (such as, but not limited to: MesaSoR.5.20 25
Tetra and P25).
The MESA system shall provide voice interoperability with voice
systems based on legacy public safety standards (such as, but not
FR-JRA-003 limited to: Tetra and P25). Due to the mission critical nature of voice MesaSoR.5.20 26
services on legacy systems, this interoperability cannot impede or
negatively affect the voice services on the legacy networks.
The system shall be able to be configured such that user application
data that is undelivered due to system connectivity issues (such as, but
FR-JRA-004 MesaSoR.5.57 305
not limited to coverage holes and outages) can be cached and
delivered when connectivity is restored.
The end user shall have access to all authorized services supported by
FR-JRA-005 MesaSoR.5.30 42
the level of connectivity to the logical networks, both on-net and off-net.
The device may bridge authorized communications across logical
networks. For example, a JAN communication may be relayed by a
FR-JRA-006 device with both JAN and Ad Hoc iAN peer to peer connectivity to MesaSoR.5.30 43
another device that does not have JAN connectivity but does have Ad
Hoc IAN connectivity.
The system shall only pre-empt if network conditions become so
FR-JRA-007 MesaSoR.5.38 99
degraded as to affect the service.
The system shall provide mechanisms for authenticated and
FR-JRA-009 authorized users (such as an administrator or supervisor) to manage, MesaSoR.5.52(a) 252
clear and/or override the panic situation.
The network's geographic coverage shall be able to scale efficiently
FR-JRA-010
MesaSoR.5.7 325
and cost effectively.
The network shall be able to scale with usage efficiently and cost
FR-JRA-011 MesaSoR.5.7 326
effectively.
The system should be capable for continuous operation at maximum
FR-JRA-012 MesaSoR.5.52 250
utilization and maximum throughput.
The device specifications and compliance information should be
available and linked with databases of devices in use in the network
FR-JRA-013 MesaSoR.5.18 15
and allow authorized users to query compliance information for all
devices under their control.
The device should have the ability to make available information that
FR-JRA-014 MesaSoR.5.18 19
will allow retrieval of compliance and conformance information.
Services provided by the system shall be consistent throughout the
FR-JRA-016 MesaSoR.5.10 3
coverage area, including in-building and in-vehicle.
The system and its components shall allow for single service dedicated
FR-JRA-017 MesaSoR.5.31 51
sessions as well as multiple simultaneous service sessions.
The logical network being accessed shall authenticate the device prior
FR-LOG-001 MesaSoR.5.50 229
to allowing use of network services requiring such authentication.
The logical network being accessed shall authenticate the device prior
FR-LOG-001 MesaSoR.5.7 329
to allowing use of network services requiring such authentication.
The logical network being accessed shall authorize the end user prior
FR-LOG-002 MesaSoR.5.50 230
to allowing use of network services requiring such authorization.
The logical network being accessed shall authorize the end user prior
FR-LOG-002 MesaSoR.5.7 330
to allowing use of network services requiring such authorization.
The logical network shall re-authenticate the device prior to allowing
FR-LOG-003 use of network services requiring such authentication when the device MesaSoR.5.50 231
is being transparently transferred to a different logical network.
The logical network shall re-authenticate the device prior to allowing
FR-LOG-003 use of network services requiring such authentication when the device MesaSoR.5.7 331
is being transparently transferred to a different logical network.
The logical network shall reauthorize the end user prior to allowing use
FR-LOG-004 of network services requiring such authorization when the device is MesaSoR.5.7 332
being transparently transferred to a different logical network.
The logical network shall reauthorize the end user prior to allowing use
FR-LOG-004 of network services requiring such authorization when the device is MesaSoR.5.50 232
being transparently transferred to a different logical network.
The logical network shall allow authorized users access to authorized
FR-LOG-005 MesaSoR.5.54 275
database(s) in real-time.
The logical network shall allow authorized users access to modify
FR-LOG-006 MesaSoR.5.54 276
specified authorized database(s) in real-time.
ETSI
14 ETSI TS 170 016 V3.1.1 (2009-02)
Functional Req. ID Associated Mesa Associated User
Functional Requirement Text
No. SoR Sections Seq IDs
The logical network shall allow the user access to monitor and control
FR-LOG-007 features and functions of remote devices such as, but not limited to, MesaSoR.5.54 277
robotic devices and unmanned units.
The logical network shall allow authorized users access to automated
FR-LOG-008 MesaSoR.5.54 278
systems and files.
The logical network(s) being accessed shall include transparent
FR-LOG-010 interfaces such that the user services rendered are uniform across MesaSoR.5.29 36
logical networks.
The logical network(s) shall support access from users belonging to
FR-LOG-012 MesaSoR.5.7 333
multiple agencies.
The logical network(s) shall support access to multiple services from
FR-LOG-013 MesaSoR.5.7 334
users.
The logical network(s) shall support access to multiple network
FR-LOG-014 MesaSoR.5.7 335
functions by device clients.
The logical network(s) shall provide simultaneous access to multiple
FR-LOG-016 MesaSoR.5.37 92
applications (e.g. host computer) from the same user.
The logical network(s) shall provide simultaneous access to multiple
FR-LOG-017 MesaSoR.5.37 93
users to the same application (e.g. host computer).
The logical network(s) shall support simultaneous transfer of voice and
FR-LOG-018 MesaSoR.5.52(b) 259
data between user and services platforms.
The logical network(s) shall support simultaneous transfer of voice and
FR-LOG-019 MesaSoR.5.52(b) 260
data between users.
The logical network(s) shall transparently support application layer MesaSoR.5.54 279
FR-LOG-020 protocols, such as (but not limited to) data base transactions, file
MesaSoR.5.29 37
download, file uploads, and remote control.
The logical network(s) shall support the capability to interface with
FR-LOG-021 MesaSoR.5.7 336
external services belonging to multiple agencies.
The logical network(s) being accessed shall be capable of interfacing
FR-LOG-028 MesaSoR.5.7 337
with inter-working and interoperability nodes deployed in the network.
The logical network(s) being accessed shall be capable of inter-
working and interoperation with external networks (such as, but not
FR-LOG-029 MesaSoR.5.7 338
limited to, AWN, P25, and TETRA). Interoperating should be a
configuration option.
The public safety network shall accommodate logical networks as
FR-LOG-030 MesaSoR.5.7 339
defined in the Public Safety Network - High Level Architecture.
The logical network(s
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...