YD/T 3711-2020 PDF English
US$290.00 · In stock · Download in 9 secondsYD/T 3711-2020: Technical requirement of IMS based vehicle eCall system based on public telecommunication network Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See step-by-step procedureStatus: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivery | Name of Chinese Standard | Status |
| YD/T 3711-2020 | English | 290 |
Add to Cart
|
0-9 seconds. Auto-delivery
|
Technical requirement of IMS based vehicle eCall system based on public telecommunication network
| Valid |
Excerpted PDFs (Download full copy in 9 seconds upon purchase)PDF Preview: YD/T 3711-2020
YD/T 3711-2020: Technical requirement of IMS based vehicle eCall system based on public telecommunication network
---This is an excerpt. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.), auto-downloaded/delivered in 9 seconds, can be purchased online: https://www.ChineseStandard.net/PDF.aspx/YDT3711-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 & 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 upper layer to establish NG-eCall, the terminal
shall enter the EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH state. The
terminal UE shall select EMM and ESM processes to establish NG-eCALL at the earliest
opportunity.;
--- If the terminal receives a request from the upper layer to establish a call to the HPLMN
for testing and reconfiguration services other than MSISDN or URI, the terminal shall
enter the EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH state. Once the
attachment process is completed, the terminal UE shall perform related EMM and ESM
processes to establish non-emergency calls.
The eCall inactivity process is only applicable to UEs configured in eCallonly mode. This
process is initiated when the following conditions are met:
--- If the UE is in any EMM-REGISTERED substate other than EMM-
REGISTERED.PLMN-SEARCH or EMM-REGISTERED.NO-CELL-AVAILABLE
substate:
--- If the UE is in EMM-IDLE mode and any of the following conditions apply:
• Timer T3444 times out or has timed out, and timer T3445 is not running;
• Timer T3445 times out or is found to have timed out, and timer T3444 is not running
or:
• Timers T3444 and T3445 time out or are found to have timed out.
The terminal UE shall perform the following processes:
--- Stop other running timers (such as T3411 and T3412);
--- If the terminal UE is currently registered for EPS services only, perform the detach
procedure for EPS services;
--- If the terminal is currently registered for both EPS services and non-EPS services,
perform a joint detach for EPS services and non-EPS services:
--- Delete any GUTI, TAI list, last visited registered TAI, equivalent PLNM list and KSI;
and enter EMM-DEREGISTERED.eCALL-INACTIVE state.
6.6 Test and reconfiguration URI
The USIM card provides two numbers or URIs for the eCall feature, one for the test number or
URI and the other for the reconfiguration number or URI. When service indication item n°89
or service indication item n°112 is available, the USIM indicates support for eCall in the service
list.
The USIM card can be modified by reconfiguration, changing from only supporting eCall to
supporting both eCall and normal calls, or from supporting eCall and normal calls to supporting
only eCall. This reconfiguration can be done by modifying the contents of the USIM service
table, or by modifying the contents of EFEST. The terminal shall use any of the following modes
to notify these changes using the REFRESHproactive command:
--- USIM initialization and file modification notification;
--- USIM initialization and full file modification notification;
--- UICC reset;
--- USIM application reset;
--- 3G session reset.
For support requirements for eCallonly, see 3GPPTS31.1025.3.40.1.
For support requirements for eCall and normal calls, see 3GPPTS31.1025.3.40.2.
6.7 Gm interface
The Gm interface is located between the UE and P-CSCF and shall support all signaling
interactions between the UE and the IMS network, including emergency call signaling. This
interface adopts SIP and shall also meet the requirements of 4.2.1 in YD/T 1522.5-2010; and
shall be able to carry vehicle emergency call indications and MSD in call signaling.
6.8 Mw interface
The Mw interface is located between P-CSCF and E-CSCF\S-CSCF; and mainly exchanges
emergency call signaling information. This interface uses the SIP protocol and shall meet the
requirements of 4.2.2 in YD/T 1522.5-2010; and can carry vehicle emergency call indications
and MSD in call signaling.
6.9 Mm/Mx interface
The Mm/Mx interface is located between the E-CSCF and the PSAP in the IMS domain/IP
domain. The E-CSCF shall route the emergency call to the nearest PSAP in the IMS domain/IP
domain through this interface according to the routing information provided by the external
LRF or the built-in LRF. This interface uses the SIP protocol and shall meet the requirements
of 4.2.1 in YD/T 1522.5-2010; and can carry vehicle emergency call indications and MSD in
call signaling.
6.10 Mi/Mj interface
The Mi/Mj interface is located between the E-CSCF and the BGCF/MGCF; and mainly
implements the IMS domain emergency call request and the connection with the PSAP in the
fixed soft switch network/PSTN/PLMN. The interface uses the SIP protocol and shall meet the
requirements of 4.2.3 in YD/T 1522.5-2010; and can carry the vehicle emergency call indication
and MSD in the call signaling.
7 Equipment Requirements
7.1 Terminal
To support NG-eCall emergency call service, the terminal shall support the following functions:
The terminal shall support the terminal functions specified in 8.1 of Technical Requirements for
Emergency Call Service of Voice Call Solution Based on LTE (VoLTE): It shall support judging
whether the cell it is located in supports NG-eCall according to the "eCallOverIMS-Support"
field of SystemInformationBlock1:
The terminal shall support setting the Request-URI to "urn:service:sos.ecall.automatic" or
"urn:service:sos.ecall.manual" in the SIPINVITE request;
The terminal shall support carrying the "application/emergencyCallData.eCall.MSD+xml"
MIME message body in the SIPINVITE, including an MSD of no more than 140 bytes; and
performing binary ASN.1 encoding according to the method specified in CEN EN15722: 2015:
The terminal shall support carrying the "application/emergencyCallData.eCall.MSD+xml"
MIME message body in the SIPINFO, including an MSD of no more than 140 bytes, and
performing binary ASN.1 encoding according to the method specified in CENEN15722:2015.
The terminal shall support the SIP signaling extension specified in IETFRFC 8147:
The terminal shall have an available UICC card. If the terminal does not have an IMSI, a valid
GUTI or a valid P-TMSI, the terminal shall not carry the IMEI in the attach message:
NOTE: This requirement is used when the terminal does not have a UICC card. YD/T XXXX Technical
Requirements for Emergency Call Services Based on LTE Voice Call Solutions (VoLTE) 8.1 stipulates
that "If the terminal does not have an IMSI, a valid GUTI or a valid P-TMSI, the terminal carries the
IMEI in the attach request message." It is not applicable to NG-eCall services.
The terminal shall support eCallonly mode.
The terminal is recommended to support establishing calls to non-emergency MSISDN and
URI for eCall testing and reconfiguration.
The terminal shall support the following audio codec standards and meet the listed coding rate
functions on the basis of the original EPS emergency call service function:
In the NAS message ATTACH ACCEPT message, the Emergency Number List needs to add
two eCall types. For details, refer to 6.3 on the requirements of NAS messages.
7.4 HSS
In accordance with the requirements of the Technical Requirements for Emergency Call
Services Based on LTE Voice Solutions (VoLTE), there is no need to expand the existing
functions of HSS.
7.5 S-GW/P-GW
According to the requirements of Technical Requirements for Emergency Call Services of Voice
Solutions Based on LTE (VoLTE), no extension is required.
7.6 MSC
According to the requirements of Technical Requirements for Emergency Call Services of Voice
Solutions Based on LTE (VoLTE), no extension of MSC is required.
For MSC and SRVCC-IWF network elements, there are no special requirements, which are
consistent with the requirements for IMS-based VoLTE emergency calls. For MGCF network
elements, it is necessary to have the ability to serve as a gateway device between E-CSCF and
PSAP, support simultaneous connection with FG-PSAP and NG-PSAP, and be able to flexibly
route according to PSAP number/URI.
7.7 IMS network equipment
7.7.1 Proxy Call Session Control Function (P-CSCF)
Based on the requirements of IMS-based VoLTE emergency calls, add:
--- Support eCall URN identification;
--- Support MSD information transmission and update process;
--- Anonymize MSD information in device signaling tracking, that is, the original MSD
information cannot be presented and saved in signaling tracking.
7.7.2 Emergency Call Session Control Function (E-CSCF)
Based on the requirements of IMS-based VoLTE emergency calls, add:
--- Support eCall URN identification;
--- Support MSD information transmission and update process;
......
Source: Above contents are excerpted from the full-copy PDF -- translated/reviewed by: www.ChineseStandard.net / Wayne Zheng et al.
|