5 Service requirements
22.3463GPPIsolated Evolved Universal Terrestrial Radio Access Network (E-UTRAN) operation for public safetyRelease 17Stage 1TS
5.1 General requirements
Isolated E-UTRAN operation shall not impact either GSM or UMTS.
The use of Isolated E-UTRAN operation shall be authorized by the operator. The network controls the use of E-UTRAN resources used for Isolated E-UTRAN operation.
When a Public Safety UE communicates within the Isolated E-UTRAN, the PLMN operator shall be able to collect accounting data for this communication.
5.2 Subscriber and service management requirements
5.2.1 Introduction (informative)
In order to provide efficient Isolated E-UTRAN operation it is necessary that eNBs (and NeNBs) capable of forming and joining an Isolated E-UTRAN are able to support certain functions locally thereby providing services of importance to the Public Safety community.
5.2.2 Requirements
Public Safety Ues served only by an Isolated E-UTRAN will not possess user plane connectivity to an external IP network due to the absence of backhaul connectivity to the Mobile Operator Network. The Isolated E-UTRAN may support Selected IP Traffic Offload at the Local Network, compatible with the service principles defined in [2], in order to provide connectivity to external IP networks (e.g. internet) when a backhaul connection (limited or otherwise) is present.
The Isolated E-UTRAN shall be able to make use of a limited backhaul connection to exchange control plane signalling with the EPC.
The Isolated E-UTRAN may use the limited backhaul connection to exchange user plane data with the EPC.
NOTE: There is no quality of service expectations for user plane data.
The Isolated E-UTRAN shall support mobility for Public Safety Ues between the eNBs comprising the Isolated E-UTRAN.
The Isolated E-UTRAN shall be able to establish ‘local routing’ and ProSe Group Communication for the Public Safety Ues in coverage of the Isolated E-UTRAN.
The Isolated E-UTRAN shall be able to provide voice and data communications services to all Public Safety Ues and groups under the coverage of the Isolated E-UTRAN.
The Isolated E-UTRAN shall allow Public Safety Ues under its coverage to initiate and maintain voice and data communications with other Public Safety Ues and groups under the coverage of the Isolated E-UTRAN.
The Isolated E-UTRAN shall be capable of informing served Public Safety Ues about which other Public Safety Ues the Isolated E-UTRAN is serving. The Isolated E-UTRAN shall support restrictions upon the provision of this information according to security policy.
NOTE: For example, information on users within a served user’s organization could be sent to that served user, and information on users could be provided to other users within the same group. Lists of served users and/or served groups could be obtained from the network or could be compiled from information collected from the Ues served by the isolated system.
5.2.3 Interoperability with MCPTT
The following requirements define a minimal set of MCPTT capabilities that are needed to provide MCPTT support under Isolated E-UTRAN operation. These requirements apply only to users under coverage of the same Isolated E-UTRAN.
These requirements apply to (N)eNBs which support MCPTT communications when not operating in an Isolated E-UTRAN.
A mechanism to pre-provision group membership, including MCPTT Emergency Group membership, shall be supported.
NOTE: Groups may be pre-provisioned on an organization basis or may cross organizational boundaries.
A Public Safety user shall be able to initiate an MCPTT Emergency Group call that reaches the following, when preconfigured as affiliated Group Members:
– a dispatcher (the dispatcher may be connected directly to the (N)eNB or via a UE)
– members of the group under the coverage of the Isolated E-UTRAN and/or;
– all Ues under the coverage of the Isolated E-UTRAN.
During Isolated E-UTRAN operation each group shall be able to initiate at least one MCPTT voice group communication that all the group’s authorized members are allowed to join, up to the limit of available radio resources.
MCPTT voice group communication shall be able to pre-empt video communications or other data services.
5.3 Requirements for initiation of Isolated E-UTRAN operation
5.3.1 Introduction (informative)
The initiation of Isolated E-UTRAN operation occurs in the event an eNB determines that there is an interruption to normal backhaul connectivity. At this point the eNB can determine if it still has connectivity to other eNBs. It is necessary for services to be set up and a limited backhaul, that might be present, needs to be taken into consideration. The Isolated E-UTRAN needs to inform the UE that it is now working in an Isolated E-UTRAN and an indication to this effect is passed on to the Public Safety user.
5.3.2 Requirements
An eNB supporting Isolated E-UTRAN operation shall be able to detect a loss of backhaul connection and shall be able to initiate Isolated E-UTRAN operation.
An (N)eNB shall be informed by O&M procedures if its backhaul connection is of limited bandwidth (e.g. a temporary nomadic backhaul deployment or a replacement backhaul in a disaster situation).
Under operator control an NeNB shall be able to initiate Isolated E-UTRAN operation.
When an eNB enters Isolated E-UTRAN operation it shall be able to, if permitted by operator policy, minimize disruption to existing established services between those Public Safety Ues served by the eNB. The eNB shall terminate services that cannot be supported locally by the Isolated E-UTRAN or by the limited backhaul service if that is available.
When an (N)eNB enters Isolated E-UTRAN operation services shall be supported for all Public Safety Ues under the coverage of the Isolated E-UTRAN.
An Isolated E-UTRAN may comprise one or more (N)eNBs.
An (N)eNB supporting Isolated E-UTRAN operation which has initiated Isolated E-UTRAN operation shall attempt to communicate with known peer (N)eNBs for the purpose of commencing Isolated E-UTRAN joint operation.
(N)eNBs engaged in Isolated E-UTRAN joint operation shall be able to exchange user traffic and signalling with other (N)eNBs belonging to the same Isolated E-UTRAN.
An Isolated E-UTRAN shall provide an indication to Public Safety Ues within the coverage area regarding whether limited bandwidth backhaul services are available or whether support is available for local services only. An Isolated E-UTRAN shall be capable of continuing to provide this indication until the Isolated E-UTRAN operation is terminated.
A Public Safety UE served by an Isolated E-UTRAN shall provide an indication to the user that the user is communicating within an Isolated E-UTRAN and whether a limited backhaul service is available or whether support is available for local services only.
5.4 Requirements for ongoing Isolated E-UTRAN operation
5.4.1 Introduction (informative)
It is necessary to manage the potentially dynamic ongoing operation of an Isolated E-UTRAN where:
– Public Safety Ues join and leave the Isolated E-UTRAN.
– eNBs join and leave the Isolated E-UTRAN.
– NeNBs join and leave the Isolated E-UTRAN.
– Isolated E-UTRANs may be combined to form larger Isolated E-UTRANs or may be split up in smaller Isolated E-UTRANs.
The EPS should monitor the status of a disconnected or limited bandwidth backhaul with the intention of re-establishing a normal connection between the Isolated E-UTRAN and the EPC.
5.4.2 Requirements
The EPS shall monitor the status of a disconnected backhaul with the intention of re-establishing a connection to the EPC.
The EPS shall monitor the status of a limited bandwidth backhaul connection with the intention of re-establishing normal operation with the EPC.
The Isolated E-UTRAN shall admit Public Safety Ues to the Isolated E-UTRAN.
The Isolated E-UTRAN shall manage Public Safety UE mobility between (N)eNBs within the Isolate E-UTRAN.
The Isolated E-UTRAN shall possess the ability to add (N)eNBs to the Isolated E-UTRAN.
NOTE: An (N)eNB added to the Isolated E-UTRAN may be an (N)eNB which possess a limited backhaul connection. Furthermore the (N)eNB with a limited backhaul connection admitted to the Isolated E-UTRAN may be the only (N)eNB in the Isolated E-UTRAN that possesses a limited backhaul connection.
The Isolated E-UTRAN shall support the ability to combine with another Isolated E-UTRAN to form a larger combined Isolated E-UTRAN.
No disruption shall be caused to local services within the remaining Isolated E-UTRAN due to an (N)eNB leaving the Isolated E-UTRAN
NOTE: The (N)eNB leaving the Isolated E-UTRAN may be the only (N)eNB in the Isolated E-UTRAN which possess a limited backhaul connection.
No disruption shall be caused to local services within the remaining Isolated E-UTRANs due to an Isolated E-UTRAN being subdivided.
5.5 Requirements for termination of an Isolated E-UTRAN
5.5.1 Introduction (informative)
In the event that the EPS detects a restored backhaul it attempts to re-establish a connection between the EPC and (N)eNB. On successful re-establishment of a connection to the EPC the (N)eNB reverts to the normal EPC connected mode of operation. While reverting to the EPC connected mode of operation the (N)eNB will transition all Public Safety Ues with active contexts to operation under the control of the EPC.
When the connection to the EPC is restored, Public Safety Ues, which were served by the (N)eNB as part of the Isolated E-UTRAN can indicate to the Public Safety user that EPC connected services are once again available.
5.5.2 Requirements
If the Isolated E-UTRAN is operating without any backhaul connection the EPS shall on detection of a restored backhaul attempt to re-establish a connection between the EPC and (N)eNB.
If the Isolated E-UTRAN is operating with a limited bandwidth backhaul connection the EPS shall on detection of a restored full bandwidth backhaul attempt to re-establish normal operation between the EPC and (N)eNB.
While re-establishing a connection to the EPC, or normal operation with the EPC, the EPS shall be able to manage, for all Ues with active contexts, the transition, where appropriate, of local services provided by the Isolated E-UTRAN to equivalent services provided via the EPC.
Having re-established control plane and user plane connections to the EPC, which are not restricted by a limited backhaul capability, the (N)eNB shall cease to provide the local services and routing which characterized Isolated E-UTRAN operation.
When an (N)eNB ceases Isolated E-UTRAN operation the (N)eNB shall cease to provide any indications, to Public Safety Ues within its coverage area, regarding the availability of only limited bandwidth backhaul services and/or whether support is available only for local services. Public Safety Ues served by the (N)eNB shall be able to indicate to the user the cessation of the restricted Isolated E-UTRAN mode of operation and/or the availability of normal EPC connected services.
5.6 Requirements for security aspects of Isolated E-UTRAN operation
5.6.1 Introduction (informative)
The Isolated E-UTRAN is expected to provide for the authentication of participating entities and for the confidentiality and integrity of communications. Provision of these security features is required for:
– UE to (N)eNB communication;
– (N)eNB to (N)eNB communication;
– UE to UE communication, i.e. for the case of ProSe operation within the Isolated E-UTRAN.
5.6.2 Requirements
The Isolated E-UTRAN shall support the following requirements for security, authorization and privacy in each of the three IOPS backhaul scenarios (see scenarios 1-3 in Table 4.1-1).
The Isolated E-UTRAN shall ensure the confidentiality and integrity of both user data and network signalling to a level comparable with that provided by the existing 3GPP system. This requirement applies to any communication between two Public Safety Ues communicating via the Isolated E-UTRAN and between an (N)eNB providing locally connected services and a Public Safety UE connected to the Isolated E-UTRAN.
A mechanism shall be provided to ensure the confidentiality and integrity of user data and signalling over the radio communication paths and over any inter-(N)eNB communication paths of an Isolated E-UTRAN.
Existing 3GPP security mechanisms (including, but not necessarily limited to, ProSe security mechanisms) shall be reused whenever possible and appropriate.
The Isolated E-UTRAN shall provide mechanism(s) to ensure mutual authentication between an Isolated E-UTRAN and (N)eNBs, or other Isolated E-UTRANs, joining the Isolated E-UTRAN.
The Isolated E-UTRAN shall provide mechanism(s) to ensure mutual authentication between an Isolated E-UTRAN and Ues connecting to the Isolated E-UTRAN.
The security mechanism(s) supported by an Isolated E-UTRAN shall be consistent with the dynamic nature of an Isolated E-UTRAN. The security of credentials shall not be compromised by solutions for Isolated E-UTRAN operation.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
05-2014 |
First draft |
0.1.0 |
|||||
|
08-2014 |
Presentation to SA#65 |
0.1.0 |
0.2.0 |
||||
|
09-2014 |
SA#65 |
SP-140506 |
MCC clean-up for presentation to SA#65 for one-step approval |
0.2.0 |
1.0.0 |
||
|
09-2014 |
SA#65 |
Raised to v.13.0.0 following SA’s one-step-approval |
1.0.0 |
13.0.0 |
|||
|
03-2017 |
SA#75 |
Updated to rel-14 by MCC |
13.0.0 |
14.0.0 |
|||
|
2018-06 |
– |
– |
– |
Updated to Rel-15 by MCC |
14.0.0 |
15.0.0 |
|
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2020-07 |
SA#88e |
– |
– |
– |
– |
Updated to Rel-16 by MCC |
16.0.0 |
|
2022-03 |
SA#95e |
– |
– |
– |
– |
Updated to Rel-17 by MCC |
17.0.0 |