ETSI TS 170 016 V3.1.1 (2009-02)

Project MESA; Technical Specification Group - System; Functional Requirements Definition

DTS/MESA-SYS0070016v311

General Information

• Status: Published
• Publication Date: 16-Feb-2009
• Technical Committee: MESA SYS - MESA System
• Current Stage: 12 - Completion
• Due Date: 10-Feb-2009
• Completion Date: 17-Feb-2009

Standards Content (Sample)

ETSI TS 170 016 V3.1.1 (2009-02)
Technical Specification


Project MESA;
Technical Specification Group - System;
Functional Requirements Definition

---------------------- Page: 1 ----------------------
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.: [phone]  Fax: [phone]

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

---------------------- Page: 2 ----------------------
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

---------------------- Page: 3 ----------------------
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

---------------------- Page: 4 ----------------------
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

---------------------- Page: 5 ----------------------
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

---------------------- Page: 6 ----------------------
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

---------------------- Page: 7 ----------------------
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

---------------------- Page: 8 ----------------------
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

---------------------- Page: 9 ----------------------
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

---------------------- Page: 10 ----------------------
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 A
...