YD/T 3711-2020 English PDF (YDT3711-2020)

Delivery: 3 seconds. Download true-PDF + Invoice.
Get Quotation: Click YD/T 3711-2020 (Self-service in 1-minute)
Historical versions (Master-website): YD/T 3711-2020
Preview True-PDF (Reload/Scroll-down if blank)

YD/T 3711-2020:Technical requirement of IMS based vehicle eCall system based on public telecommunication network
YD/T 3711-2020
YD
COMMUNICATION INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 33.060
M 36
Technical Requirement of IMS Based Vehicle eCall
System Based on Public Telecommunication Network
ISSUED ON: APRIL 16, 2020
IMPLEMENTED ON: JULY 1, 2020
Issued by: Ministry of Industry and Information Technology of the People’s
Republic of China
Table of Contents
Foreword ... 3
1 Scope ... 4
2 Normative References ... 4
3 Terms, Definitions and Abbreviations ... 5
3.1 Terms and Definitions ... 5
3.2 Abbreviations ... 6
4 System Overview ... 7
4.1 Service function ... 7
4.2 System architecture ... 7
5 Service Process Requirements ... 9
5.1 Overview ... 9
5.2 Initial MSD transmission ... 11
5.3 MSD update ... 14
5.4 Domain selection ... 15
5.5 eCall only mode ... 16
5.6 SRVCC requirements ... 16
6 Interface Parameters and Processes ... 18
6.1 SIP signaling for MSD transmission ... 18
6.2 PLMN selection ... 20
6.3 NAS message ... 20
6.4 RRC message ... 20
6.5 eCall-INACTIVE substate ... 21
6.6 Test and reconfiguration URI ... 22
6.7 Gm interface ... 23
6.8 Mw interface ... 23
6.9 Mm/Mx interface ... 23
6.10 Mi/Mj interface ... 24
7 Equipment Requirements ... 24
7.1 Terminal ... 24
7.2 eNodeB ... 25
7.3 MME ... 25
7.4 HSS ... 26
7.5 S-GW/P-GW ... 26
7.6 MSC ... 26
7.7 IMS network equipment ... 26
Technical Requirement of IMS Based Vehicle eCall
System Based on Public Telecommunication Network
1 Scope
This Standard specifies the technical requirements for IMS-based data transmission in the
vehicle emergency call system based on the public telecommunication network, mainly
including the call process of eCall, MSD transmission and update process, and the equipment
functions and interface parameters involved in the LTE and IMS networks.
This Standard is applicable to VoLTE networks, terminal vehicle equipment, wireless
subsystem equipment, MSC, EPC core network and IMS network system equipment that
provide IMS-based vehicle emergency call services.
2 Normative References
The following documents are essential to the application of this Document. For the dated
documents, only the versions with the dates indicated are applicable to this Document; for the
undated documents, only the latest version (including all the amendments) is applicable to this
Document.
YD/T 1522.5-2010 Technical requirements for session initiation protocol (SIP) - Part 5:
Session initiation protocol based on the unified IMS
Technical requirements for emergency call services based on Voice over LTE (VoLET)
3GPPTS22.101 Technical specification group services and system aspects; service aspects;
service principles
3GPP TS23.167IMS (IP Multimedia Subsystem (IMS) emergency sessions)
3GPPTS 24.008 (Mobile radio interface layer 3 specification; Core network protocols;
Stage 3)
3GPPTS 24.301 (Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);
Stage 3)
3GPP TS 26.071 (Mandatory speech CODEC speech processing functions; AMR speech
Codec; General description)
3GPP TS 26.093 (Mandatory speech codec speech processing functions Adaptive Multi-
Rate (AMR) speech codec; Source controlled rate operation)
3GPP TS 26.171 (Speech codec speech processing functions; Adaptive Multi-Rate –
Wideband (AMR-WB) speech codec; General description)
3GPP TS 26.193 (Speech codec speech processing functions; Adaptive Multi-Rate –
Wideband (AMR-WB) speech codec; Source controlled rate operation)
3GPP TS 26.267 (eCall data transfer; In-band modem solution; General description)
3GPP TS 31.102 (Characteristics of the Universal Subscriber Identity Module (USIM)
application)
IETF RFC 8147 (Next-Generation Pan-European eCall)
CEN EN 15722 (2011 Intelligent transport system – eSafety – eCall minimum set of data
(MSD))
3 Terms, Definitions and Abbreviations
3.1 Terms and Definitions
For the purposes of this Document, the following terms and definitions apply.
3.1.1 Public safety answering point
A physical location that can receive public calls, such as a public safety answering station or an
emergency command center/interaction platform.
3.1.2 eCall
An emergency call initiated manually or automatically from a vehicle (Circuit and Emergency
Call or IMS Emergency Call) and carrying the emergency-related Minimum Set of Data (MSD).
3.1.3 Minimum set of data
The minimum set of data sent by a vehicle for rescue purposes, see CEN EN 15722 eCall
minimum set of data.
3.1.4 Restrictive state
The user data is valid and available, and a cell has been selected. It is known that the cell cannot
provide ordinary services, and only emergency services can be provided. At this time, the user
is in a service state.
3.1.5 eCall only mode
Steps 4~5:
a) If the IMS emergency call eSRVCC process is deployed: E-CSCF anchors the emergency
call signaling to EATF, parses the eCall URN of the Request-URI in the emergency call
request and the UE access location information in the P-Access-Network-Info header
domain; and searches the E-CSCF built-in or external LRF based on this information to
determine the number of the emergency call center PSAP; and routes the emergency call
to the MGCF or ISBC; and then to the corresponding emergency call center PSAP.
b) If the IMS emergency call eSRVCC process is not deployed: EATF network elements do
not need to be deployed; and emergency call signaling does not need to pass through
EATF network elements. Other processes are the same as the IMS emergency call process
with eSRVCC deployed.
Steps 6~9:
After receiving the INVITE request, the PSAP rings, responds to the 180 message, and passes
it to the UE through the IMS core.
Step 10:
The PSAP goes off-hook and responds to the 200OK message. PSAP supports INVITE request
to carry MSD information. In the returned 200OK, it carries the
application/emergencyCallData.control type message body to confirm the receipt of MSD
information.
Steps 11 ~ 13:
E-CSCF/P-CSCF/SBC forwards 200OK message to UE. UE confirms the successful
transmission of MSD information based on 200OK information.
Steps 14 ~ 17:
UE responds with ACK and passes it to PSAP through IMS core.
eCall emergency call is established successfully, media channel is created successfully, and
initial MSD transmission and confirmation are completed.
5.2.2 Transmit MSD to PSAP that does not support NG-eCall during session
establishment
When the UE detects that packet services are available, but does not detect that the network
supports NG-eCall and no circuit domain services are available, the UE can initiate a normal
IMS-based emergency call. The specific process is shown in 3GPP TS 23.167.
When the UE detects that the network supports NG-eCall services, but the PSAP does not
support NG-eCall, the UE shall transmit MSD in the manner specified in 7.7.2 of 3GPP TS
F No --- --- If CS is available, access CS None
a Indicated by the network NG-eCall capability in SIB1, see 6.4
5.5 eCall only mode
A terminal configured in eCallonly mode shall remain in the EMM-DEREGISTERED state.
The terminal UE shall reside in an available network cell; but shall avoid any mobility
management and other signaling interactions with the network. The terminal UE may initiate
mobility management and connection management procedures to establish, maintain and
release an NG-eCall session or a session connected to a non-emergency MSISDN or URI
configured by the UICC for testing and terminal reconfiguration purposes.
With the release of any session, the terminal UE starts a timer whose value depends on the type
of session (e.g., either an eCall or a session to a non-emergency MSISDN or URI). While the
timer is valid, the terminal UE shall perform normal mobility management and allow responses
to paging messages to receive and establish an incoming session (e.g., from an emergency
handling center, PSAP or HPLMN operator). When the timer expires, if the terminal UE is still
in the attached state, the terminal shall initiate a detach procedure and enter the EMM-
DEREGISTERED state.
NOTE 1: The HPLMN operator may modify the eCallonly mode configuration status of the terminal UE
recorded in the UICC. The HPLMN operator may add, modify or delete a non-emergency MSISDN or
URI configured in the UICC for testing and reconfiguration. This behavior may be after the UE calls a
non-emergency MSISDN or URI for reconfiguration. When the eCallonly mode configuration is deleted,
the UE behaves like a normal UE and can support NG-eCall.
NOTE 2: Test and reconfiguration calls can be treated as normal (non-emergency) calls by the serving
PLMN and can use normal charging rules according to the operator's policy.
NOTE 3: The MSISDN configured in the UICC for NG-eCall testing and terminal reconfiguration can
be different from the MSISDN configured in the CS domain for testing.
For a terminal UE configured for eCallonly, when attached to EPS using E-UTRAN access, the
terminal shall not indicate support for other RAT wireless access technologies to access the PS
domain.
NOTE 4: For a terminal UE configured in eCallonly mode to access the PS domain, only E-UTRAN
wireless technology is supported in the current version.
5.6 SRVCC requirements
If the operator network supports the IMS emergency call SRVCC process, then the IMS-based
eCall process shall support the SRVCC handover process shown in Figure 7.
6 Interface Parameters and Processes
6.1 SIP signaling for MSD transmission
6.1.1 SIPINVITE
UE initiates an IMS-based eCall and sends an INVITE request. Based on the requirements for
IMS-based VoLTE emergency calls, the following requirements are added:
Request-URI value of INVITE:
--- If the user manually triggers the eCall, it is urn:service:sos.ecall.manual;
--- If the sensor automatically triggers the eCall, it is urn:service:sos.ecall.automatic.
The Accept header carries application/emergencyCallData.control+xml, indicating that the UE
can accept this type of message body.
The Recv-Info header carries emergencyCallData.eCall.MSD, indicating that the INFO request
carrying MSD information can be received.
The value of the message body Content-Type corresponding to the MSD information is
application/emergencyCallData.eCall.MSD. The MSD information is carried in the message
body of the application/emergencyCallData.eCall.MSD type; the MSD information uses binary
ASN.1 PER in accordance with the CEN EN 15722 encoding format, which does not exceed
140 bytes.
The MSD message body needs to carry the Content-ID header field, whose value is an ID that
can uniquely identify the MSD information.
For more requirements on INVITE requests, see IETF RFC8147.
6.1.2 SIP 200 response (INVITE)
After receiving the initial INVITE request carrying MSD information, the PSAP verifies the
MSD information, confirms that the MSD information is correct, and returns 200OK after the
PSAP goes off-hook. The requirements are as follows:
The value of the message body Content-Type corresponding to the MSD control information is
application/emergencyCallData.control+xml, and the MSD control information is carried in the
message body of the application/emergencyCallData.control type. Thereof, the "received"
attribute of the ack element is set to "true", and the "ref" attribute is set to the value of the
Content-ID corresponding to the MSD message body sent by the UE.
For more requirements on the 200 response, see IETF RFC8147.
--- The Content-type header field takes the value of
application/emergencyCallData.control+xml corresponding to the message body; the
"ref" parameter of the ack element is set to the Content-ID corresponding to the
message body "application/emergencyCallData.control+xml" in the INFO request
received by the UE; the "success" attribute of the "actionResult" sub-element takes
the value "false"; the "action" attribute takes the value "send-data"; and the "reason"
attribute selects a suitable value according to IETF RFC8147.
--- The MSD message body needs to carry the Content-Disposition header field, with the
value By-Reference.
For more requirements on INFO requests and responses, refer to IETF RFC8147.
6.2 PLMN selection
If the terminal UE is not in eCallonly mode, the PLMN selection method is the same as the
normal PLMN selection.
If the terminal UE is in eCallonly mode, the terminal UE shall try to stay in an appropriate cell
and then enter the eCall inactive state. If the terminal cannot find an appropriate cell, the
terminal UE shall try to stay in an acceptable cell in the restrictive state and then enter the eCall
inactive state. In the restrictive state, the available and allowed PLMNs shall be searched like
ordinary UEs.
The UE selects the PLMN according to the normal priority. The terminal UE shall not consider
PLMNs that do not support NG-eCall unless the PLMN supports UTRAN or GERANCS access.
If no PLMN is available, the terminal UE shall be allowed to make a second PLMN selection,
but there is no restriction on NG-eCall or CS support.
Cell selection and PLMN selection at the access layer have no effect on NG-eCall.
6.3 NAS message
During the LTE system registration process of the terminal, the network side needs to add two
identifiers supporting eCall, "manually initiated eCall" and "automatically initiated eCall", in
the IE "Emergency Number List" item in the Attach Accept message. For details, see 3GPPTS
24.301 and 3GPP TS 24.008.
6.4 RRC message
The E-UTRAN cell sends the "eCallOverIMS-Support" field to indicate whether the cell
supports NG-eCall. The "eCallOverIMS-Support" field is transmitted in
SystemInfomationBlock1. If SystemInformationblock1 does not carry this field, it means that
the network does not support NG-eCall.
After receiving the "eCallOverIMS-Support" field, the terminal UE shall process the
--- If the user instructs the terminal to deactivate (such as shutting down), the terminal UE
shall enter EMM-NULL;
--- If the terminal receives a request from the up...