Академический Документы
Профессиональный Документы
Культура Документы
Issue 01
Date 2016-03-07
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com
Contents
5 Related Features...........................................................................................................................22
6 Network Impact........................................................................................................................... 23
7 Engineering Guidelines............................................................................................................. 24
7.1 When to Use Emergency Call.......................................................................................................................................24
7.2 Required Information................................................................................................................................................... 24
7.3 Network Planning......................................................................................................................................................... 24
7.4 Deployment (CSFB-based Emergency Call)................................................................................................................24
7.4.1 Requirements............................................................................................................................................................. 24
7.4.2 Data Preparation and Feature Activation...................................................................................................................24
7.4.2.1 Data Preparation..................................................................................................................................................... 24
7.4.2.2 Using the CME....................................................................................................................................................... 25
7.4.2.3 Using MML Commands......................................................................................................................................... 25
7.4.3 Precautions.................................................................................................................................................................26
7.4.4 Activation Observation..............................................................................................................................................26
7.4.5 Deactivation...............................................................................................................................................................26
7.4.5.1 Using the CME....................................................................................................................................................... 26
7.4.5.2 Using MML Commands......................................................................................................................................... 26
7.5 Deployment (IMS-based Emergency Call).................................................................................................................. 26
7.5.1 Requirements............................................................................................................................................................. 27
7.5.2 Data Preparation and Feature Activation...................................................................................................................27
7.5.2.1 Data Preparation..................................................................................................................................................... 27
7.5.2.2 Using the CME....................................................................................................................................................... 30
7.5.2.3 Using MML Commands......................................................................................................................................... 30
7.5.3 Precautions.................................................................................................................................................................30
7.5.4 Activation Observation..............................................................................................................................................31
7.5.5 Deactivation...............................................................................................................................................................32
7.5.5.1 Using the CME....................................................................................................................................................... 33
7.5.5.2 Using MML Commands......................................................................................................................................... 33
7.6 Performance Monitoring...............................................................................................................................................33
7.6.1 CSFB-based Emergency Calls...................................................................................................................................33
7.6.2 IMS-based Emergency Calls..................................................................................................................................... 34
7.7 Parameter Optimization................................................................................................................................................ 35
7.8 Troubleshooting............................................................................................................................................................ 35
8 Parameters..................................................................................................................................... 36
9 Counters........................................................................................................................................ 39
10 Glossary....................................................................................................................................... 44
11 Reference Documents............................................................................................................... 45
1.1 Scope
This document describes LBFD-002028 Emergency Call, including its technical principles,
related features, network impact, and engineering guidelines.
This document applies to the following types of eNodeBs.
Micro BTS3202E
BTS3911E
BTS3203E
Any managed objects (MOs), parameters, alarms, or counters described herein correspond to
the software release delivered with this document. Any future updates will be described in the
product documentation delivered with future software releases.
This document applies only to LTE FDD. Any "LTE" in this document refers to LTE FDD,
and "eNodeB" refers to LTE FDD eNodeB.
eRAN11.1 01 (2016-03-07)
This issue does not include any changes.
2.1 Background
An emergency call is a voice service initiated by user equipment (UE) in emergencies. The
emergency telephone number may differ from country to country. It is typically a nationwide
fixed number, for example, 911 in the United States. An emergency telephone number can be
a default number saved in a UE or a number sent by the serving network.
In scenarios of terrorism, medical urgency, fire and other natural disasters, people can dial
emergency telephone numbers for help. A UE can initiate an emergency call without a
Subscriber Identity Module (SIM), Universal SIM (USIM), or IM SIM (ISIM).
In some areas or countries, the operators are ruled to support the emergency call service.
2.2 Introduction
Emergency calls refer to voice services between UEs and the emergency center in emergency
scenarios.
Compared with other services, emergency calls have the following characters:
l High requirement of access success rate. That is, the emergency call service takes
priority over other types of services.
l High requirement of service continuity. That is, emergency UEs enjoy privileges in
terms of mobility management.
l High requirement of positioning precision. That is, the precise position of the UE can
be obtained by the network. The standard precision stipulated by Federal
Communications Commission (FCC) is 50 m to 300 m.
According to section 4.3.12.1 of 3GPP TS 23.401 V10.6.0, an emergency call is generally
made by the following types of users:
l Common user: a normal user who has a valid subscription and can get access to services
normally.
l Common limited user: a normal user who has a valid subscription but cannot get access
to services normally for reasons like the user is not in service areas or the telephone bill
is overdue.
l Limited user with a SIM card: a user whose SIM card fails the authentication. This
type of user makes an emergency call by using the international mobile equipment
identity (IMEI).
l Limited user without a SIM card: a user who does not have a SIM card. This type of
user makes an emergency call by using the IMEI.
2.3 Benefits
This feature enables UEs even without SIMs preferentially to contact with related emergency
centers.
2.4 Architecture
In the LTE system, a call can be an IMS-based VoIP call or a CSFB-based call. IMS, VoIP,
and CSFB are short forms of IP multimedia subsystem, voice over IP, and Circuit Switched
Fallback, respectively. Similarly, an emergency call can be a CSFB-based emergency call or
an IMS-based VoIP emergency call (referred to as IMS-based emergency call in this
document).
In an emergency call, the network elements (NEs) shown in Figure 2-1 provide the following
functions:
l UE
Supports attach, tracking area update (TAU), and detach of emergency calls.
l E-UTRAN
Supports the identification of emergency UEs.
Performs special processing on the admission and mobility management of
emergency UEs.
Participates in the positioning of emergency UEs.
l MME
Supports attach, TAU, and detach of emergency calls.
Supports IMEI-based attach and detach.
Supports the selection of the emergency PDN gateway (P-GW) based on the P-GW
identity, for example, select the local P-GW rather than the home P-GW of the UE.
Assigns a high priority to emergency call bearer setups. For example, the number of
access point name (APN) connections is not limited and no restriction is applied on
the bearer setup.
l P-GW
Sends requests to the PCRF for policy control and transfers the APN provided by the
MME to the PCRF.
l PCRF
Identifies an IP-connectivity access network (IP-CAN) session as the IMS-based
emergency call service based on the APN and then delivers the policy and charging
control (PCC) rules and authentication of emergency calls, ensuring that the
resources are not occupied by other services. For emergency-call APN-related IP
addresses, no subscription data check is performed and the authentication and rules
are delivered according to the operator's local policies.
Controls emergency call bearers, and supports the setup, modification, and deletion
of IP-CAN sessions for the emergency call service by adopting special quality of
service (QoS) policies.
l IMS
Identifies an emergency call based on the destination IP address contained in a
session request and lifts restrictions on the emergency call service.
Controls Session Initiation Protocol (SIP) sessions, and emergency calls, and routes
emergency calls to the correct emergency call center.
NOTE
If an emergency call is successfully made, a positioning procedure may be initiated by the evolved packet
core (EPC) to acquire the location of the UE. The location of emergency UEs is not provided in this
document.
This document describes only the differences between the IMS-based emergency call
procedure and the normal call procedure, the emergency call-related eNodeB functions, and
related parameters. For details, see 4 IMS-based Emergency Call.
This chapter describes the CSFB-based emergency call procedure and the differences on the
eNodeB for implementing emergency calls and normal calls.
Figure 3-2 CS call request in E-UTRAN and call in GERAN or UTRAN without PS HO
This document describes only CSFB to GERAN or UTRAN. For details about CSFB to
CDMA2000 1xRTT, see LTE-CDMA2000 CS Service Interworking Feature Parameter
Description
NOTE
If PS handovers are used for CSFB to UTRAN, the eNodeB sends the radio network controller (RNC) a
handover request with CS Fallback High Priority. This request informs the RNC that this CSFB
procedure is triggered by an emergency call so that the RNC preferentially processes this call.
To increase the admission success rate of emergency UEs initiating CSFB procedures, the
ARP value for bearers of such UEs can increase. The
CsFallbackPolicyCfg.CsfbUserArpCfgSwitch parameter determines whether to set the ARP
value for emergency UEs initiating CSFB procedures. When this parameter is set to ON(On),
the IEs contained in the ARP values of default bearers for emergency UEs initiating CSFB
procedures are configured as follows:
l Priority Level
The value of this IE is 1.
l Pre-emption Capability
The value of this IE is may trigger pre-emption, indicating that the UEs can preempt
resources of other low-priority UEs.
l Pre-emption Vulnerability
The value of this IE is not pre-emptable, indicating that resources of the UEs cannot be
preempted by other UEs.
Compared with common UEs, emergency UEs have higher priorities. This chapter describes
special processes of emergency calls on the eNodeB. The special processes ensure preferential
admission of emergency UEs and service continuity of emergency calls.
Emergency call services require the support from the EPC. eNodeBs identify emergency call
services and perform special processing such as assigning higher priorities to emergency call
services. If an emergency call is initiated, a default bearer and a dedicated bearer are set up for
special use of this emergency call. The bearers for emergency calls are associated with
emergency APNs.
4.1.1 Indicators
A UE must be notified of whether a network supports IMS-based emergency calls so that the
UE can determine whether to initiate an IMS-based emergency call or initiate a CSFB-based
emergency call in emergencies. During the attach procedure, if the UE detects that the
accessed network does not support emergency calls, the UE select another network supporting
emergency calls to access.
Whether a network supports emergency calls is determined by the local regulations and
operating policies of the operator.
Normal Attach
A UE in the normal service state attaches to the network normally after initiating an
emergency call. For details about procedures for normal attach, see Idle Mode Management
Feature Parameter Description.
Emergency Attach
A UE enters the limited service state if the UE encounters a failure of normal attach or TAU,
or the UE does not initiate attach attempts (for example, the UE is universal integrated circuit
card-less [UICC-less]). A UE in the limited service state performs emergency attach when it
initiates an emergency call. The emergency attach allows the UE to skip the authentication
procedure with the EPC, ensuring successful attach.
According to section 5.3.2 of 3GPP TS 23.401 V10.6.0, the emergency attach procedure is
based on a normal attach procedure but includes the following special processing.
l An emergency attach indicator is contained in the Attach Request message. Based on this
indicator, the MME performs such special processing as authentication cancellation.
l If the IMSI is unavailable or invalid, as in the case of a UICC-less UE or subscription-
expired UE, the IMEI of the emergency UE is contained in the Attach Request message
for the network to identify the UE.
l The authentication procedure can be skipped for UEs in the limited service state if local
regulations permit.
For details on emergency configuration data, see section 5.7.2 of 3GPP TS 23.401 V10.7.0.
The MME indicates the allowed and rejected services to eNodeBs. In the S1-
AP:OVERLOAD START message, the MME specifies the requests that the eNodeB should
accept or reject. For example, the eNodeB may be required to:
l Reject RRC connection setup requests for non-emergency mobile-originated data
transfer.
l Reject RRC connection setup requests for signaling services.
l Allow RRC connection setup requests for only emergency calls (mobile-originated or
mobile-terminated).
l Allow RRC connection setup requests for high-priority calls (with the RRC
establishment cause value "highPriorityAccess") and mobile-terminated calls (with the
RRC establishment cause value "mt-Access").
l Reject RRC connection setup requests for delay-tolerant services (with the RRC
establishment cause value "delayTolerantAcess")
mechanisms are applied on this E-RAB. For example, this bearer can set up in scenarios of
limited resources, and high ARP is set for this bearer.
The eNodeB can perform admission control on an EPS bearer for an emergency call based on
QoS parameters and the EPC allocates the reserved ARP for the bearer. If the eNodeB has
insufficient resources, the ARP ensures that an emergency UE can preempt the resources of
low-priority UEs.
After an emergency call is initiated, a default E-RAB and a dedicated E-RAB are set up for
specific use of this emergency call.
l The default E-RAB, different from the one set up during the normal attach procedure, is
exclusively used by the emergency call.
l The dedicated E-RAB is used to carry the VoIP session for the emergency call.
Currently, one Huawei eNodeB can be shared by multiple operators. This function is known
as RAN sharing. In RAN sharing scenarios, to enable operators sharing one eNodeB to adopt
different emergency call strategies, parameters Emc.EmcDefaultBearerARP and
Emc.EmcDedicatedBearerARP specify ARP values for the default E-RABs and dedicated E-
RABs for emergency calls, respectively.
4.1.5.1 Reselection
For a UE in the limited service state, the mobility of the UE in RRC_IDLE mode is
determined by the emergency call indicators described in 4.1.1 Indicators. If information in
SIB1 indicates that the cell does not support IMS-based emergency calls, the UE selects or
reselects to a cell supporting IMS-based emergency calls in any RAT to camp on.
4.1.5.2 TAU
The EPC uses an explicit context that is a special ARP to indicate an ongoing emergency call.
The TAU procedure defined in section 5.3.3 of 3GPP TS 23.401 V10.6.0 uses special
mechanisms for emergency UEs. If the network supports emergency UEs in the limited
service state, the TAU must succeed in case of emergency calls.
According to the description of NAS in section 8.2.26.1 of 3GPP TS 24.301 V10.6.1 and
3GPP TS 24.008 V10.6.1, the MME delivers a local emergency call number list to the UE
that is performing TAU, and then the list is saved by the UE. In this way, the UE can obtain
local emergency call numbers when roaming to a different area. This helps the UE identify
emergency calls. The preceding function depends on the capabilities of UEs and MMEs.
4.1.5.3 Handover
A mobility restriction function is introduced to the E-UTRAN. If a UE is in
RRC_CONNECTED mode, the EPC provides a handover restriction list (HRL) to the E-
UTRAN. In addition, the E-UTRAN and the EPC enable the mobility restriction function to
prevent the UE being handed over to an area listed in the HRL. To prevent the interruption of
emergency calls and to ensure the successful handover to an area listed in the HRL, special
mechanisms are applied, with which only emergency calls are allowed to be handed over to
the areas listed in the HRL.
Coverage-based Handovers
Coverage-based handovers are fundamental to ensuring service continuity of moving UEs. As
a basic function, coverage-based handovers are classified as intra-frequency, inter-frequency,
and inter-RAT handovers.
Emergency UEs have the highest priority. Therefore, to ensure the stability and continuity of
emergency calls, emergency UEs can be handed over to any cells without restrictions. For
example, they can be handed over to the neighboring cells such as cells with NoHoFlag set to
FORBID_HO_ENUM(Forbid Ho), blacklisted neighboring cells and neighboring cells in an
area listed in the HRL. For details, see Overview of Mobility Management in Connected Mode
Feature Parameter Description.
Load-based Handovers
Load-based handovers are effective in ensuring service continuity when the local cell is
heavily loaded (or even congested) but the neighboring cells are lightly loaded. By requesting
lightly loaded neighboring cells to take away a proportion of UEs through negotiation, the
local cell transfers part of its load to its neighboring cells. Thereby, the inter-cell loads are
balanced and the resource utilization is maximized.
However, load-based handovers often induce a high probability of service drops. To ensure
the stability and continuity of emergency calls, the eNodeB will not apply load-based
handovers to emergency UEs.
SRVCC-based Handovers
The single radio voice call continuity (SRVCC) procedure ensures the continuity between
IMS-based VoIP calls and CS voice calls. For details, see 3GPP TS 23.216 V10.3.0.
According to 3GPP specifications, eNodeBs process the SRVCC procedure for emergency
calls in the same way as that for normal calls. Therefore, this document does not describe the
implementation of the SRVCC procedure for emergence calls.
Figure 4-3 shows the SRVCC procedure.
Figure 4-3 SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support
During the E-UTRAN-initiated SRVCC procedure for emergency calls, the MME identifies
bearers for emergency calls based on the ARP value and then sends an indicator to the MSC.
The MSC initiates an IMS service continuity procedure using an emergency session transfer
number for SRVCC (E-STN-SR) to the served IMS. For details about the E-STN-SR, see
section 6c.2 of 3GPP TS 23.237 V10.9.0. When the emergency UE is handed over, the MME
initiates a positioning continuity procedure that is defined in 3GPP TS 23.271 V10.2.0.
Compared with the normal SRVCC procedure, the special processing of emergency calls in
the SRVCC procedure for emergency is as follows:
is set to ON(On)), the eNodeB sets the IE ims-EmergencySupport value to true. To prevent
UEs in the limited service state from accessing PLMNs that do not support emergency calls,
the Emc.EmcEnableInLimitedMode parameter value for all operators must be the same.
eNodeBs process emergency calls based on the PLMNs selected by UEs.
5 Related Features
Prerequisite Features
Feature ID Feature or Function Description
Name
Impacted Features
Feature ID Feature or Function Description
Name
N/A TM2 transmission mode To improve the access success rate and
and semi-persistent ensure service stability for emergency
scheduling UEs, the eNodeB uses the TM2
transmission mode and does not
configure semi-persistent scheduling.
6 Network Impact
System Capacity
No impact.
Network Performance
No impact.
7 Engineering Guidelines
If an operator has the IMS network deployed, the IMS-based emergency call is recommended.
7.4.1 Requirements
If CSFB-based emergency call is enabled, UEs must support CSFB and related CSFB features
must be enabled on the eNodeB. For details about how to enable CSFB features, see CS
Fallback Feature Parameter Description.
l Network plan (negotiation not required): parameter values planned and set by the
operator
l Network plan (negotiation required): parameter values planned by the operator and
negotiated with the EPC or peer transmission equipment
l User-defined: parameter values set by users
(Optional) The following table describes the parameter that must be set in the
CsFallbackPolicyCfg MO to configure the ARP values of bearers for emergency UEs
initiating CSFB procedures.
When the number of UEs requesting to access the eNodeB reaches the licensed number of
UEs, the following parameter can be set to ensure a high priority for emergency UEs initiating
CSFB procedures.
7.4.3 Precautions
None
7.4.5 Deactivation
The following table provides the parameter used to deactivate this feature.
7.5.1 Requirements
Before deploying IMS-based emergency call, ensure that UEs, the EPC, and IMS support
IMS-based emergency call.
l Network plan (negotiation not required): parameter values planned and set by the
operator
l Network plan (negotiation required): parameter values planned by the operator and
negotiated with the EPC or peer transmission equipment
l User-defined: parameter values set by users
The following table describes the parameters that must be set in an Emc MO to configure the
IMS-based emergency call strategy for an operator of the eNodeB.
The ARP Emc.EmcDedi Engineering This parameter specifies the ARP value of
of EMC catedBearerA design the dedicated bearers for emergency calls.
dedicated RP The setting of this parameter must be
bearer consistent with the configuration of the
EPC.
This ARP value is reserved by the operator.
The ARP value of the dedicated bearers for
emergency calls can be the same as that of
the default bearers for emergency calls.
It is recommended that the ARP value of
the default bearer assigned during
subscription not be the same as that of the
default or dedicated bearer for emergency
calls; otherwise, all services of the user will
be considered and processed as emergency
calls.
The ARP Emc.EmcDef Engineering This parameter specifies the ARP value of
of EMC aultBearerAR design the default bearers for emergency calls. The
default P setting of this parameter must be consistent
bearer with the configuration of the EPC.
This ARP value is reserved by the operator.
The ARP value of the default bearers for
emergency calls can be the same as that of
the dedicated bearers for emergency calls.
It is recommended that the ARP value of
the default bearer assigned during
subscription not be the same as that of the
default or dedicated bearer for emergency
calls; otherwise, all services of the user will
be considered and processed as emergency
calls.
(Optional) The following table describes the parameter that must be set in the TACALG MO
to configure the preferential admission switch for emergency UEs under transport-resource-
based admission control.
If the TACALG.EMCTACPSW parameter is set to ON(On) and uplink and downlink
transmission admission control algorithms are enabled in scenarios where transmission
bandwidth is limited, the admission success rate of emergency UEs increases.
(Optional) The following table describes the parameter that must be set in the CellRacThd
MO to configure the preferential admission switch for privileged UEs under UE-number-
reservation-based admission control. When the maximum number of UEs supported by the
cell is limited, UE numbers are reserved for emergency UEs. This ensures that emergency
calls are successfully connected and resources of admitted UEs performing voice services are
not preempted by emergency UEs.
7.5.3 Precautions
The settings of emergency call-related parameters must be consistent with the configurations
on the EPC; otherwise, emergency call services are affected. Table 7-3 describes the impacts
on emergency call services due to inconsistent parameter settings on the eNodeB and EPC.
Step 1 On the U2000 client, choose Monitor > Signaling Trace > Signaling Trace Management.
Step 2 In the navigation tree on the left of the Signaling Trace Management tab page, double-click
Uu Interface Trace under LTE > Application Layer.
Step 3 Create and start a Uu interface tracing task.
Step 4 View the tracing result. If the value of the IE ims-EmergencySupport-r9 is true(0) in SIB1,
the emergency call feature has been activated.
----End
7.5.5 Deactivation
The following table provides the parameters used to deactivate this feature.
l
If KPIs in a cell do not meet requirements, check the cell status and perform network
optimization.
7.8 Troubleshooting
None
8 Parameters
Emc EmcEna MOD LBFD-0 Emerge Meaning: Indicates whether the operator supports
bleInLi EMC 02028 / ncy Call emergency calls initiated by UEs in the limited service
mitedM LST TDLBF state.
ode EMC D-00202 GUI Value Range: OFF(Off), ON(On)
8
Unit: None
Actual Value Range: OFF, ON
Default Value: OFF(Off)
Emc EmcDef MOD LBFD-0 Emerge Meaning: Indicates the Allocation and Retention
aultBear EMC 02028 / ncy Call Priority (ARP) value of the default emergency call
erARP LST TDLBF bearer.
EMC D-00202 GUI Value Range: 1~15
8
Unit: None
Actual Value Range: 1~15
Default Value: 1
Emc EmcDed MOD LBFD-0 Emerge Meaning: Indicates the Allocation and Retention
icatedBe EMC 02028 / ncy Call Priority (ARP) value of the dedicated emergency call
arerARP LST TDLBF bearer.
EMC D-00202 GUI Value Range: 1~15
8
Unit: None
Actual Value Range: 1~15
Default Value: 1
TACAL EMCTA SET LOFD-0 Transpo Meaning: Indicates the switch that is used to
G CPSW TACAL 0301101 rt preferentially admit emergency calls. When this
G / Overboo parameter is set to ON, transmission admission
LST TDLOF king control is not performed for emergency calls and
TACAL D-00301 Emerge emergency calls will be successfully admitted. When
G 101 ncy Call this parameter is set to OFF and the transmission
LBFD-0 admission algorithm switch is turned on, transmission
02028 / admission control is performed for emergency calls.
TDLBF When this parameter is set to OFF and the
D-00202 transmission admission algorithm switch is turned off,
8 transmission admission control is not performed for
emergency calls.
GUI Value Range: OFF(Off), ON(On)
Unit: None
Actual Value Range: OFF, ON
Default Value: OFF(Off)
CellRac AcReser MOD LBFD-0 Admissi Meaning: Indicates the UE numbers reserved for UEs
Thd vedUser CELLR 02023 / on initiating emergency calls and high-priority UEs. If
Number ACTHD TDLBF Control this parameter is set to 0, no UE number is reserved
LST D-00202 for UEs initiating emergency calls and high-priority
CELLR 3 UEs. A non-zero value of this parameter represents
ACTHD the maximum UE number reserved for UEs initiating
emergency calls and high-priority UEs.
GUI Value Range: 0~30
Unit: None
Actual Value Range: 0~30
Default Value: 0
Emc CnOper LST LOFD-0 RAN Meaning: Indicates the id of the operator.
atorId EMC 01036 / Sharing GUI Value Range: 0~5
MOD TDLOF with
D-00103 Commo Unit: None
EMC
6 n Actual Value Range: 0~5
LOFD-0 Carrier Default Value: None
01037 / RAN
TDLOF Sharing
D-00103 with
7 Dedicate
d
Carrier
Emc EmcEna MOD LBFD-0 Emerge Meaning: Indicates whether to enable or disable
ble EMC 02028 / ncy Call emergency calls. It is recommended that this
LST TDLBF parameter be set to a value in accordance with the
EMC D-00202 actual emergency call capability of the operator.
8 GUI Value Range: OFF(Off), ON(On)
Unit: None
Actual Value Range: OFF, ON
Default Value: OFF(Off)
9 Counters
10 Glossary
11 Reference Documents