Patent Application
20110261726
The invention relates to emergency calls in radio systems.
Emergency calls are made in case of extreme urgency. Consequently, reliability of emergency calls should be high: connection times should be as short as possible, and call drop-off rates should be quite low, for example. In summary, emergency call implementation into a radio system requires utmost care.
The present invention seeks to provide improved emergency call processing in apparatuses, methods, and computer programs.
According to an aspect of the present invention, there is provided an apparatus as specified in claim 1.
According to another aspect of the present invention, there is provided another apparatus as specified in claim 8.
According to another aspect of the present invention, there is provided a method as specified in claim 16.
According to another aspect of the present invention, there is provided a computer program as specified in claim 22.
According to another aspect of the present invention, there is provided another method as specified in claim 23.
According to another aspect of the present invention, there is provided another computer program as specified in claim 30.
According to another aspect of the present invention, there is provided a computer program on a carrier as specified in claim 31.
According to another aspect of the present invention, there is provided another computer program on a carrier as specified in claim 32.
According to another aspect of the present invention, there is provided another apparatus as specified in claim 33.
According to another aspect of the present invention, there is provided another apparatus as specified in claim 34.
Embodiments of the present invention are described below, by way of example only, with reference to the accompanying drawings, in which
The following embodiments are exemplary. Although the specification may refer to an embodiment or embodiments in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. The present invention is applicable to any radio system that supports the functionality that will be described in the following. The protocols and specifications of radio systems develop rapidly. Such development may require extra changes to an embodiment. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment.
A ‘terminal’ 100 refers to a user terminal operating with or without a subscriber identification module (SIM). Such a terminal 100 may be portable, or, in certain cases it may be fixed to a certain location (within a house, for example) or an object (a car-mounted terminal, for example). The terminal 100 may also be known by the following names, for example: a mobile station, a mobile phone, a smartphone, a personal digital assistant (PDA), user equipment (UE), and a subscriber terminal. The terminal 100 is configured to associate the terminal and its user with a subscription, and to allow the user to interact with the radio system 168. The terminal 100 presents information to the user and allows the user to input information. In other words, the terminal 100 may be any terminal capable of receiving information from and/or transmitting information to the network 166 and connectable to the network 166 wirelessly.
The ‘network’ 166 refers to the fixed network infrastructure of the radio system. The network 166 may be operated by the network operator. The network 166 may also be known by the following names, for example: a cellular radio network, and a mobile network. The network 166 comprises a number of system elements. Three such system elements are illustrated in
The radio interface 172 is implemented by radio transceivers 130, 160 operating both in the terminal 100 and in the base station 132. In the LTE, for example, the downlink radio interface 172 is implemented with OFDMA (Orthogonal Frequency-Division Multiple Access), and the uplink radio interface 172 is implemented with SC-FDMA (Single-carrier Frequency-Division Multiple Access).
As illustrated in
The electronic circuit(s) may comprise logic components, standard integrated circuits, and/or application-specific integrated circuits (ASIC).
The microprocessor implements functions of a central processing unit (CPU) on an integrated circuit. The CPU is a logic machine executing a computer program which comprises program instructions. The program instructions may be coded as a computer program using a programming language, which may be a high-level programming language, such as C, or Java, or a low-level programming language, such as a machine language, or an assembler. The CPU may comprise a set of registers, an arithmetic logic unit (ALU), and a control unit. The control unit is controlled by a sequence of program instructions transferred to the CPU from a program memory. The control unit may contain a number of microinstructions for basic operations. The implementation of the microinstructions may vary, depending on the CPU design. The microprocessor may also have an operating system (a dedicated operating system of an embedded system, or a real-time operating system), which may provide system services to the computer program.
The processor 200 of the terminal 100 is configured to have a packet-switched (PS) radio resource control (RRC) connection 170 with the network 166 (or, more specifically, with the base station 132). Furthermore, the processor 200 of the terminal 100 is configured to make an emergency call through the network 166 while continuing to have the packet-switched radio resource control connection 170 with the network 166.
Correspondingly, the processor 206 of the base station 132 is configured to have a packet-switched radio resource control connection 170 with the terminal 100, and to perform an emergency call originated by the terminal 100 while continuing to have the packet-switched radio resource control connection 170 with the terminal 100.
The radio resource control connection 170 may refer to a point-to-point bidirectional connection between the RRC control entities 110, 136 on the terminal 100 and the base station 132.
In principle, it could be possible to drop the existing packet-switched radio resource control connection 170, and establish a new packet-switched radio resource control connection. However, such action would cause severe problems in emergency call situations: an emergency caller cannot continue to use existing services or at least they will be affected. This is a really unwanted situation. The emergency call system has not yet been fully defined for the LTE. It is planned to be agreed in 3GPP release 9. It may become a mandatory part for the LTE systems, when handheld terminals with voice calls are implemented. In the LTE system, many terminals may have always on connections, and they may be in the radio resource connection connected state. LTE is also a PS only system, and the current 3G CS emergency call procedures do not solve the emergency call prioritization. Another problem is that some networks may support emergency VoIP calls and some networks may deploy a CS domain for emergency calls. The emergency call needs to be correctly handled for a given single terminal 100 in both network types. It is also complex to update the service strategy in the network 166, because the current mechanisms require that the terminal 100 and/or the network 166 need to be updated as a result of the radio access and/or core network changes in the used network.
Next, some use cases relating to an emergency call will be presented.
Use case 1: An IMS- or VoIP-based emergency call. IMS (Internet Protocol Multimedia Subsystem) refers to the provision of Internet Protocol multimedia to mobile users. VoIP (Voice over Internet Protocol) refers to the delivery of voice communications over the Internet (or other packet-switched networks). Other, synonymous terms for VoIP may also be used, such as IP telephony and Internet telephony, voice over broadband, broadband telephony, and broadband phone. Let us suppose that the terminal 100 is using a default bearer for SIP (Session Initiation Protocol, used for setting up and tearing down voice and video calls over the Internet) signalling. If the terminal 100 needs to send SIP signalling to the network 166 in an overload situation, the terminal 100 may not be able to send even the first SIP signalling message towards the network, if the terminal 100 is not prioritized. Because of that, the packet-switched radio resource control connection 170 needs to be updated before the network 166 even tries to guarantee that the terminal 100 can send the first SIP signalling message to create the emergency call.
Use case 2: A young girl has hurt herself and calls her mother for help. The mother wants to keep the call with her daughter ongoing (in order to calm her, to check her location, or to see the situation provided that the call is a video call), while at the same time calling an emergency centre. Another alternative is to put the call with the daughter on hold. Even in that situation, it is beneficial to keep the packet-switched radio resource control connection 170 active all the time. The call between the mother and daughter may even be a proprietary (such as a Skype call) or IMS/VoIP call. If the packet-switched radio resource control connection 170 was dropped, the call between the mother and daughter would also be dropped.
Use case 3: A man is driving the car and an accident happens. He does not know his location. He uses a map application in his terminal 100 to see his location, because he wants to make the accident location known to the emergency centre. The dropping of the packet-switched radio resource control connection 170 would either drop the map application or at least make its operation much slower.
Use case 4: A user is using multiple services at the same time, and suddenly there is a need to make an emergency call. If the packet-switched radio resource control connection 170 was dropped, the used applications would notice that and start to send multiple messages to check whether the connection is in order. This would lead to excessive messaging, creating unwanted load both to the terminal 100 and the network 166 just when the emergency call is to be made. Keeping the existing packet-switched radio resource control connection 170 working all the time results in that the task of the terminal 100 during the emergency call becomes much easier. The terminal 100 does not need to check whether the packet-switched radio resource control connection 170 needs to be dropped or not, neither does it need to implement specific handling (what to do if the packet-switched radio resource control connection is dropped due to an emergency call) for every application. The terminal 100 may always merely update the packet-switched radio resource control connection 170, whereupon the base station 132 may allocate resources (more scheduling resources to guarantee that the terminal can make the actual emergency call, for example) to that terminal 100. Dropping the packet-switched radio resource control connection 170 can also cause that the base station 132 will drop the terminal 100 (LTE-IDLE) and also drop the EPS (Evolved Packet Systems) bearer. This can happen especially in the overload situation, or if the network operator wants to minimize the EPS bearer usage (if the pricing model between the network vendor and the operator is partly based on the number of EPS bearers, for example). This will lead to unnecessary signalling and problems for the existing services. The additional signalling will also take more time (especially in an overload situation) and increase the risk that an emergency call cannot be made at all.
In the embodiment of
The control plane protocol stack 108, 134 has the following layers:
In a protocol stack, a lower layer provides services for an upper layer. For the sake of clarity, only a logical connection 170 between the RRC layer 110 of the terminal 100 and the RRC layer 136 of the base station 132 has been illustrated, but other layers also have such connections: 112<->138, 114<->140, and 116<->142. When the logical connection 170 exists, it may be said that the terminal 100 is in an RRC connected state.
The user plane protocol stack 118, 144 has the following layers:
Again, for the sake of clarity, only a logical connection 174 between the PDCP layer 120 of the terminal 100 and the PDCP layer 146 of the base station 132 has been illustrated.
In the embodiment of
Correspondingly, in the embodiment of
Next, various embodiments are described with reference to
In an embodiment, illustrated in
In an embodiment, also referred to in the use cases, the processor 206 of the base station 132 is further configured to prioritize the packet-switched radio resource control connection 170 due to the request 302. Both processors 200, 206, may be configured to perform the signalling of the emergency call with the prioritized packet-switched radio resource control connection 170.
As can be seen from
The request 302 may be implemented as a new RRC connection update message, and the reply 304 may be implemented as a new RRC connection update acknowledgement message. The RRC connection update 302 may be a logical message to update an RRC connection, and it may be a separate new/existing message, or it may be integrated to existing and/or new messages, and the values in the message(s) may be new, updated, or existing. The RRC connection update acknowledgement 304 may be an optional logical acknowledgement message to update the RRC connection, and it may be a separate new/existing message, or it may be integrated to the existing/new messages, and the values in the message(s) may be new, updated, or existing.
A VoIP emergency call has been defined for the LTE, as illustrated in
The CS fallback enables the provisioning of voice and other CS-domain services by reuse of CS infrastructure when the terminal 100 is served by EUTRAN (Evolved Universal Terrestrial Radio Access) of the LTE. A CS fallback enabled terminal 100 may use GERAN (GSM EDGE Radio Access Network) or UTRAN (Universal Mobile Telecommunications System Terrestrial Radio Access Network) to establish one or more CS-domain services.
A CS fallback (CSFB) solution has been defined for the LTE, as illustrated in
As illustrated in
Next, the use of the RRC connection update 302 is examined.
RRC Connection Update Usage—VoIP/CS Call
RRC connection update 302 provides means to correctly handle emergency calls for the terminal: if CSFB is to be deployed for emergency calls, this may be indicated in the RRC connection update acknowledgement message 304. If emergency VoIP is to be deployed, the RRC connection update procedure is only utilized for increasing the priority of the RRC connection 170. This removes the burden from the terminal 100 for making a decision on what kind of emergency call should be initiated in each network, and the network 166 becomes responsible for this in a controlled way without stating an additional requirement for the terminal 100 implementation, and allowing smooth evolution towards emergency VoIP (i.e. initially the RRC connection update is utilized for indicating a need for CSFB, but later this indication may be removed, when emergency VoIP is supported).
RRC Connection Update Usage—Radio Access Network Updates
Currently, the terminal 100 needs to select the used radio access before sending a service request to the base station 132. This leads to a situation where the terminal 100 needs to know the access strategy for voice calls (including emergency calls). This leads to a situation where it is complex to update a voice strategy, i.e. what access (e.g. LTE/2G) to use. This is even more complex in roaming cases, but a similar problem exists even in the home network. This leads to a situation where the terminal 100 needs to be updated in order to change its behaviour, when the operator wants to start to prioritize calls (voice/emergency).
RRC Connection Update Usage—Roaming Users (Emergency Call)
It is difficult for the MME 164 to know, what the terminal 100 should do (what access to use) in the visited network. It requires constant updates between the home and visited networks concerning the used access network. The described embodiments allow the update of the visited network structure without constant updates between the home and visited networks.
In short, the RRC connection update 302 provides means to correctly handle emergency calls for the terminal 100: if CSFB is to be deployed for emergency calls, this may be indicated in the RRC connection update acknowledgement message 304. If emergency VOIP is to be deployed, the RRC connection update procedure may only be utilized for increasing the priority of the RRC connection 170.
Next, two methods will be described with reference to
The method of
In 902, there is a packet-switched radio resource control connection with a network.
Optionally, in 904, a request may be transmitted to the network to prioritize the packet-switched radio resource control connection due to the emergency call. The request may be an RRC connection update message.
Optionally, in 906, a reply to the request may be received. The reply may be an RRC connection update acknowledgement message.
Optionally, in 908, a control point is defined: whether emergency VoIP session establishment over the prioritized RRC connection takes place or whether a CSFB procedure shall be deployed for an emergency call. This may be decided by studying a received RRC connection update acknowledgement message.
In an embodiment, the signalling of the emergency call may be performed with the prioritized packet-switched radio resource control connection. This means that both the signalling of the emergency call for a circuit-switched fallback and the signalling of the emergency call for a voice over Internet Protocol session may be performed with the prioritized packet-switched resource control connection.
In an embodiment, a service request for the emergency call may be transmitted with the prioritized packet-switched radio resource control connection.
Optionally, in 910, a reply is received from the network, indicating that the signalling of the emergency call is to be performed for a circuit-switched fallback.
Optionally, in 912, a reply is received from the network, indicating that the signalling of the emergency call is to be performed for a voice over Internet Protocol session.
In 914, an emergency call is made through the network while continuing to have the packet-switched radio resource control connection with the network.
The method ends in 916.
The method of
In 1002, there is a packet-switched radio resource control connection with a terminal.
Optionally, in 1004, a request is received from the terminal to prioritize the packet-switched radio resource control connection due to the emergency call.
Optionally, in 1006, the packet-switched radio resource control connection is prioritized due to the request.
Optionally, in 1010, it is decided whether emergency VoIP session establishment over the prioritized RRC connection takes place, or whether a CSFB procedure shall be deployed for an emergency call.
In an embodiment, the signalling of the emergency call is performed with the prioritized packet-switched radio resource control connection.
In an embodiment, a service request for the emergency call may be received with the prioritized packet-switched radio resource control connection.
Optionally, in 1014, a reply is transmitted to the terminal indicating that the signalling of the emergency call is to be performed for a voice over Internet Protocol session.
Optionally, in 1012, a reply is transmitted to the terminal indicating that the signalling of the emergency call is to be performed for a circuit-switched fallback.
In 1016, an emergency call originated by the terminal is performed while continuing to have the packet-switched radio resource control connection with the terminal.
The base station may perform the needed processing alone, or other system elements may also be involved.
The method ends in 1018.
It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2008/065132 | 11/7/2008 | WO | 00 | 7/5/2011 |
