WO2015119556A1

WO2015119556A1 - Managing emergency traffic in wireless communication systems

Info

Publication number: WO2015119556A1
Application number: PCT/SE2015/050057
Authority: WO
Inventors: Mattias TAN BERGSTRÖM; Magnus Stattin
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-02-10
Filing date: 2015-01-21
Publication date: 2015-08-13

Abstract

There is provided a method of operating a terminal device in a first network that is operating according to a first radio access technology, RAT,the terminal device being capable of operating in a second network that is operating according to a second RAT, the method comprising determining which of the first network and second network to use for emergency traffic that is to be sent by and/or received at the terminal device (601); and establishing a connection to the determined one of the first network and second network for sending and/or receiving the emergency traffic (603).

Description

MANAGING EMERGENCY TRAFFIC IN WIRELESS COM MUNICATION SYSTEMS

Technical Field

The present disclosure relates generally to wireless communication systems and is more particularly related to techniques for managing emergency calls or other emergency traffic for terminal devices that are capable of operating according to multiple radio access technologies, RATs, such as one or more wide area communication technologies standardised by the 3^rd Generation Partnership Project (3GPP) and a wireless local area network (WLAN) technology.

Background

The wireless local-area network (WLAN) technology known as "Wi-Fi" has been standardised by IEEE in the 802.11 series of specifications (i.e., as "IEEE Standard for Information technology— Telecommunications and information exchange between systems. Local and metropolitan area networks— Specific requirements. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications'). As currently specified, Wi-Fi systems are primarily operated in the 2.4 GHz and 5 GHz bands. The terms "Wi-Fi" and "WLAN" are used interchangeably throughout this application.

Recently, Wi-Fi has been subject to increased interest from cellular network operators, who are studying the possibility of using Wi-Fi for purposes beyond its conventional role as an extension to fixed broadband access. These operators are responding to the ever-increasing market demands for wireless bandwidth, and are interested in using Wi-Fi technology as an extension of, or alternative to, cellular radio access network technologies. Cellular operators that are currently serving mobile users with, for example, any of the technologies standardised by the 3rd-Generation Partnership Project (3GPP), including the radio-access technologies known as Long-Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS)/Wideband Code-Division Multiple Access (WCDMA), High Speed Packet Access (HSPA) and Global System for Mobile Communications (GSM), see Wi-Fi as a wireless technology that can provide good additional support for users in their regular cellular networks.

Many of today's portable terminal devices (also referred to herein as "user equipments" or "UEs" or mobile devices or communication devices) support Wi-Fi in addition to one or several 3GPP cellular technologies. In many cases, however, these terminal devices essentially behave as two separate devices from a radio access perspective.

3GPP is currently working on specifying a feature or mechanism for WLAN/3GPP radio interworking which improves the control over how a terminal device (UE) steers traffic (e.g. data sessions, voice calls, etc.) between 3GPP radio access networks, RANs (i.e. cellular radio access networks operating according to a 3GPP-specified radio access technology) and WLANs belonging to the operator or its partners. Possible methods to support traffic steering from 3GPP to WLAN

Two alternatives for performing traffic steering between two radio access technologies (RATs), such as a 3GPP RAT and Wi-Fi, are described here. A first alternative is based on conditions and thresholds provided to the terminal device by a first RAT (e.g. a network operating according to a first RAT, such as a 3GPP-specified RAT or WLAN). The conditions and thresholds dictate the situations in which the terminal device should steer traffic from/to a second RAT (e.g. a network operating according to a second RAT, such as another 3GPP-specified RAT or WLAN).

In a second alternative, a first RAT, e.g. a 3GPP RAT (a network operating according to a 3GPP RAT), controls a terminal device's connection to a second RAT, e.g., a WLAN, by sending traffic steering commands that order the terminal device to steer traffic from/to the second RAT.

Threshold based approach - In this alternative for performing traffic steering between 3GPP and WLAN, the 3GPP network provides the UE with conditions and thresholds which are used by the terminal device in one or more rules that determine when the terminal device should steer traffic from one network (i.e. the 3GPP RAT) to the other (i.e. WLAN). For example, the rule could take the form of Example 1 below where threshold^ threshold2, threshold3 and threshold4 are provided to the terminal device by the 3GPP network. if (3GPP signal < threshold^*!) && (WLAN signal > threshold2) {

steerTrafficToWLANO;

} else if (3GPP signal > threshold3) || (WLAN signal < threshold^ { steerTrafficTo3gpp();

}

Example 1

If the 3GPP signal measured by the terminal device is below thresholdl and the WLAN signal measured by the terminal device is above threshold2, this rule provides that the terminal device should steer traffic to WLAN. Otherwise, if the 3GPP signal is above threshold3 and the WLAN signal is below threshold^ the rule provides that the terminal device shall steer traffic to 3GPP.

Traffic steering command based approach - An alternative procedure for performing traffic steering between 3GPP and WLAN networks is described below. In short, this procedure is based on three messages and some associated procedures that allow the 3GPP network to determine when a terminal device should associate with a WLAN or, more generally, to a network operating according to a second (possibly different) radio access technology (RAT). The procedure is illustrated in Figure 1. The first message, a reporting configuration message (message 1), is sent from the 3GPP network (3GPP radio access network (RAN) 10) to the terminal device 12 and configures the terminal device 12 with a set of criteria for enabling, detecting, or performing measurements over the second network (WLAN 14). One possible set of criteria contained in one possible reporting configuration message is as follows:

Received signal strength indicator (RSSI) in WLAN > X

Reference signal received power (RSRP) in 3GPP < Y and/or

BSS load < Z

The terminal device 12 subsequently sends a terminal report, message 2, to the 3GPP network 10, when the criteria given in the first message (message 1) have been fulfilled. The 3GPP network 10 evaluates the content of the terminal report, along with any other reports or information that the network 10 may have available, such as backhaul congestion, delay, subscription information and interference, and determines whether or not to steer the terminal device's traffic to WLAN 14. The third message (message 3), a traffic steering message, is an indicator sent from the 3GPP network 10 to the terminal device 12 that the terminal device 12 should steer all or a subset of its traffic to WLAN 14. The traffic steering message may indicate a specific target access point (AP) in the WLAN 14, or it could just be a command telling the terminal device 12 to steer its traffic to WLAN 14 and the terminal device 12 and WLAN 14 determine which particular AP should be used. Access Network Discovery and Selection Function

The Access Network Discovery and Selection Function (ANDSF) is an entity defined by 3GPP for providing access discovery information as well as mobility and routing policies to the UE. ANDSF is a new entity added to the 3GPP architecture in Release 8 of 3GPP TS 23.402 (See "Architecture Enhancements for non-3GPP Accesses," 3GPP TS 23.402, v. 11.4.0 (Sept. 2012), available at www.3gpp.org). A simplified ANDSF architecture is depicted in Figure 2. As shown in the figure, the ANDSF server 40 is provided that is added to a 3GPP network (that comprises one or more eNodeBs (eNBs) 42 and a gateway (GW) 44) and is only connected to the UE 46, and its main goal is to provide the UE 46 with access network information in a resource efficient and secure manner. The communication between the UE 46 and the ANDSF server 40 is defined as an IP-based S14-interface 48. A Wi-Fi AP 50 is also shown in Figure 2, with the AP 50 being connected to the GW 44.

By supplying information about both available 3GPP and non-3GPP access networks to the UE 46, the ANDSF server 40 enables an energy-efficient mechanism of network discovery, where the UE 46 can avoid continuous and energy-consuming background scanning. Furthermore, the ANDSF provides the mobile operators with a tool for the implementation of flexible and efficient UE steering of access mechanisms, where policy control can guide UEs 46 to select one particular radio access network (RAN) over another.

The ANDSF supplies three types of information - discovery information, inter-system mobility policies (ISMP) and inter-system routing policies (ISRP). All these are summarized and implemented via ANDSF managed objects (MO), which are communicated to the UE 46 via an over-the-top (OTT) signalling channel.

The discovery information provides the UE with information regarding the availability of different RATs in the UE's vicinity. This helps the UE to discover available (3GPP and non-3GPP) access networks without the burden of continuous background scanning. Inter-System Mobility Policies (ISMP) are policies which guide the UE to select the most preferable 3GPP or non-3GPP access. The ISMP are used for UEs that access a single access network (3GPP or Wi-Fi) at a time. The ISMP information specifies the behaviour of UEs that can be connected to only one access network at a given time (either 3GPP, WLAN, Worldwide Interoperability for Microwave Access (WiMAX), etc). If the UE, however, supports connection to several access networks at the same time, the operator can use the third type of information, ISRP, to increase the granularity of the RAN selection. In that case, the UEs will be provided with policies that specify how the traffic flows should be distributed over the different RAN. For example, voice might be only allowed to be carried over 3GPP radio access (RA), while Internet video streaming and best-effort traffic can be routed via WLAN.

Summary

Emergency calls are calls made to for example the police, fire brigade, ambulance, etc using a dedicated emergency phone number such as 999 or 91 1. Even though it may be possible to make an emergency call over different types of network, each type of network may not always be suitable for carrying this type of call. In some cases particular requirements are put on the network over which these types of calls are carried. Example requirements could be that the call drop rate is below a threshold, that the emergency call is prioritised over non-emergency calls, that call back is supported which enables, for example, the police to call the user back after the call has terminated.

In LTE, to acquire emergency call service a terminal device indicates to the network the need to establish an emergency call. The network controls in which network an emergency call shall be established. If the network supports provisioning of emergency calls it can provide necessary functionality and initiate procedures needed to provision/establish the emergency call service. If the network does not support provisioning of emergency calls or determines it would be better to handle it in another network, the network initiates and controls a procedure in which the UE is transferred, by handover or by redirection, to a preferred network in which emergency call service is provisioned.

Current mechanisms for access selection and traffic steering between different networks, such as those described above, provide a means to steer traffic between 3GPP and WLAN. However some types of traffic are not suitable to be carried over a RAT that does not meet certain requirements. For example, it may be that due to the requirements associated with emergency calls, these types of calls are not suitable to be carried over some or all WLAN networks; e.g., would there be for instance positioning or call back requirements which cannot be met.

This means that if a terminal device, according to some access selection and traffic steering mechanisms, steers voice traffic over a WLAN, then the terminal device may also steer emergency traffic over the WLAN, which may not be suitable.

Various embodiments described herein provide means to handle emergency traffic/calls in a different way to other, non-emergency, traffic/calls when making use of a network interworking feature that enables access selection and traffic steering.

Unlike current solutions for emergency calls which are network controlled and assume that the network has at least the capability of recognising requests for establishing emergency calls, the embodiments described herein provide terminal device-centric solutions enabling proper handling of emergency calls in the context of networks lacking said capability.

According to a first specific embodiment, there is provided a method of operating a terminal device in a first network that is operating according to a first radio access technology, RAT, the terminal device being capable of operating in a second network that is operating according to a second RAT, the method comprising determining which of the first network and second network to use for emergency traffic that is to be sent by and/or received at the terminal device; and establishing a connection to the determined one of the first network and second network for sending and/or receiving the emergency traffic.

According to a second specific embodiment, there is provided a terminal device for use in a first network that is operating according to a first radio access technology, RAT, and a second network operating according to a second RAT, the terminal device comprising a processing circuit and transceiver circuitry that are configured to determine which of the first network and second network to use for emergency traffic that is to be sent by and/or received at the terminal device; and establish a connection to the determined one of the first network and second network for sending and/or receiving the emergency traffic. According to a third specific embodiment, there is provided a method of operating a network node in a first network that is operating according to a first radio access technology, RAT, the method comprising sending information to a terminal device that is operating in the first network, the information being for use by the terminal device in determining which of the first network and a second network that is operating according to a second RAT to use for emergency traffic that is to be sent by and/or received at the terminal device.

According to a fourth specific embodiment, there is provided a network node for use in a first network that is operating according to a first radio access technology, RAT, the network node comprising a processing circuit and interface circuitry that are configured to send information to a terminal device that is operating in the first network, the information being for use by the terminal device in determining which of the first network and a second network that is operating according to a second RAT to use for emergency traffic that is to be sent by and/or received at the terminal device.

According to a fifth specific embodiment, there is provided a computer program product having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable processing circuit or computer, the processing circuit or computer is caused to perform any of the method embodiments described.

Brief Description of the Drawings

Features, objects and advantages of the presently disclosed techniques will become apparent to those skilled in the art by reading the following detailed description where references will be made to the appended figures in which:

Figure 1 is a diagram illustrating one example of a network interworking feature; Figure 2 is a block diagram of a simplified ANDSF architecture;

Figure 3 is a diagram illustrating the overall architecture of an LTE network;

Figure 4 illustrates part of an LTE network and a Wi-Fi network; Figure 5 is a block diagram of an exemplary terminal device according to several embodiments;

Figure 6 is a block diagram of an exemplary network node according to several embodiments;

Figure 7 is a flow chart illustrating a method of operating a terminal device according to various embodiments; and Figure 8 is a flow chart illustrating a method of operating a network node according to various embodiments.

Detailed Description

In the discussion that follows, specific details of particular embodiments of the present teaching are set forth for purposes of explanation and not limitation. It will be appreciated by those skilled in the art that other embodiments may be employed apart from these specific details. Furthermore, in some instances detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or in several nodes. Some or all of the functions described may be implemented using hardware circuitry, such as analog and/or discrete logic gates interconnected to perform a specialized function, application-specific integrated circuits (ASICs), programmable logic arrays (PLAs), digital signal processors (DSPs), reduced instruction set processors, field programmable gate arrays (FPGAs), state machines capable of performing such functions, etc. Likewise, some or all of the functions may be implemented using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Where nodes that communicate using the air interface are described, it will be appreciated that those nodes also have suitable radio communications circuitry. Moreover, the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, including non- transitory embodiments such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. Hardware implementations of the present teachings may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer, processor, and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term "processor" or "controller" also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.

The discussion that follows frequently refers to "terminal devices", although other generally equivalent terms such as "mobile devices", "communication devices", "mobile stations" and particularly "UEs" - which is a 3GPP term for end user wireless devices - may also be used. It should be appreciated, however, that the techniques and apparatus described herein are not limited to 3GPP UEs (i.e. UEs or terminal devices that are capable of operating according to one or more 3GPP standardised technologies), but are more generally applicable to end user wireless devices (e.g., portable cellular telephones, smartphones, wireless-enabled tablet computers, etc.) that are useable in cellular systems and that are capable of communicating with a radio access network (RAN) using one or multiple carriers or cells (e.g. known as a carrier aggregation (CA) mode in LTE). It should also be noted that the current disclosure relates to end user terminal devices that support one or more wide-area cellular technologies, such as any of the wide-area radio access standards maintained by 3GPP, and a wireless local area network (WLAN) technology, such as one or more of the IEEE 802.11 standards. End user devices are referred to in Wi-Fi documents as "stations," or "STA" - it should be appreciated that the term "UE" or "terminal device" as used herein should be understood to refer to a STA, and vice-versa, unless the context clearly indicates otherwise. It should also be noted that the current disclosure also relates to end user wireless devices that support both a wide-area cellular technology, such as any of the wide-area radio access standards maintained by 3GPP, and a non- 3GPP standardized RAT, for which improvements in the management of emergency calls or other emergency traffic are desired. As used herein, a "base station" comprises in a general sense any node transmitting radio signals in the downlink (DL) to a terminal device and/or receiving radio signals in the uplink (UL) from the terminal device. Some example base stations are eNodeB, eNB, Node B, macro-/micro-/pico-/femto-cell radio base station, home eNodeB (also known as a femtocell base station), relay, repeater, sensor, transmitting-only radio nodes or receiving-only radio nodes. A base station may operate or at least perform measurements in one or more frequencies, carrier frequencies or frequency bands and may itself be capable of carrier aggregation. It may also be a single-radio access technology (RAT), multi-RAT, or multi-standard node, e.g., using the same or different base band modules for different RATs.

The signalling between the terminal devices and the network nodes (e.g. a base station or another node in the RAN or core network) described below is either via direct links or logical links (e.g. via higher layer protocols and/or via one or more other network nodes). For example, signalling from a coordinating node may pass another network node, e.g., a radio node.

Overall E-UTRAN architecture - An exemplary Evolved UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network (E-UTRAN) architecture is shown in Figure 3. The E-UTRAN architecture 210 consists of base stations 220, 230, 240 called enhanced NodeBs (eNBs or eNodeBs), which provide the E-UTRA user plane and control plane protocol terminations towards the User Equipment (UE). The eNBs 220, 230, 240 are interconnected with each other by means of the X2 interface 250, 252, 254. The eNBs 220, 230, 240 are also connected by means of the S1 interface 260, 262, 264, 266 to the EPC 270 (Evolved Packet Core), more specifically to the MME 280, 290 (Mobility Management Entity), by means of the S1-MME interface, and to the Serving Gateway 280, 290 (S-GW) by means of the S1-U interface. The S1 interface supports many-to-many relations between MMEs / S-GWs and eNBs. The eNB 220, 230, 240 hosts functionalities such as Radio Resource Management (RRM), radio bearer control, admission control, header compression of user plane data towards the UE, and routing of user plane data towards the serving gateway. The MME 280, 290 is the control node that processes the signalling between the UE and the core network 270. The main functions of the MME 280, 290 are related to connection management and bearer management, which are handled via Non Access Stratum (NAS) protocols. The S-GW 280, 290 is the anchor point for UE mobility, and also includes other functionalities such as temporary downlink data buffering while the UE is being paged, packet routing and forwarding the right eNB 220, 230, 240, gathering of information for charging and lawful interception. The PDN (Packet Data Network) Gateway (P-GW - not shown in Figure 3) is the node responsible for UE IP address allocation, as well as Quality of Service (QoS) enforcement. The 3GPP document "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall Description; Stage 2," 3GPP TS 36.300, v. 1 1.3.0 (Sept. 2012), available at www.3gpp.org, and the references therein provide details of the functionalities of the different nodes shown in Figure 3.

Figure 4 illustrates a network where the LTE radio access parts (eNBs) 320, 322 and a Wi-Fi wireless access point 310 are both connected to the same P-GW 340. In the case of the LTE radio access parts, the eNBs 320, 322 are connected to the P-GW 340 via an S-GW 330. A UE 300 is shown that is capable of being served both from the Wi-Fi Access Point 310 and the LTE eNBs 320, 322. Arrows 350 and 352 illustrate the uplink (UL) and downlink (DL) transmissions between the UE 300 and the Wi-Fi AP 310 respectively and arrows 360 and 362 illustrate the uplink (UL) and downlink (DL) transmissions between the UE 300 and the eNBs respectively. Figure 4 illustrates one possible way of connecting a Wi-Fi access network 302 to the same core network as the 3GPP-specified access network 304. The gateways (Trusted Wireless Access Gateway, TWAG, evolved Packet Data Gateway, ePDG, etc) between Wi-Fi AP and P- GW are omitted for simplicity. It should be noted that the presently disclosed techniques are not restricted to scenarios where the Wi-Fi access network 302 is connected in this way; the techniques can be applied to scenarios where the networks are more or completely separate.

Hardware Implementations - Several of the techniques and methods described below may be implemented using radio circuitry and electronic data processing circuitry provided in a terminal device. Figure 5 illustrates features of an example terminal device 400 according to several embodiments. Terminal device 400, which may be a UE configured for operation with an LTE network (E-UTRAN) and that also supports Wi-Fi, for example, comprises a transceiver unit 420 for communicating with one or more base stations (eNBs) as well as a processing circuit 410 for processing the signals transmitted and received by the transceiver unit 420. Transceiver unit 420 includes a transmitter 425 coupled to one or more transmit antennas 428 and receiver 430 coupled to one or more receiver antennas 433. The same antenna(s) 428 and 433 may be used for both transmission and reception. Receiver 430 and transmitter 425 use known radio processing and signal processing components and techniques, typically according to a particular telecommunications standard such as the 3GPP standards for LTE. Note also that transmitter unit 420 may comprise separate radio and/or baseband circuitry for each of two or more different types of radio access network, such as radio/baseband circuitry adapted for E-UTRAN access and separate radio/baseband circuitry adapted for Wi-Fi access. The same applies to the antennas - while in some cases one or more antennas may be used for accessing multiple types of networks, in other cases one or more antennas may be specifically adapted to a particular radio access network or networks. Because the various details and engineering tradeoffs associated with the design and implementation of such circuitry are well known and are unnecessary to a full understanding of the techniques described herein, additional details are not shown here.

Processing circuit 410 comprises one or more processors 440 coupled to one or more memory devices 450 that make up a data storage memory 455 and a program storage memory 460. Processor 440, identified as CPU 440 in Figure 5, may be a microprocessor, microcontroller, or digital signal processor, in some embodiments. More generally, processing circuit 410 may comprise a processor/firmware combination, or specialized digital hardware, or a combination thereof. Memory 450 may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Because terminal device 400 supports multiple radio access technologies, processing circuit 410 may include separate processing resources dedicated to one or several radio access technologies, in some embodiments. Again, because the various details and engineering tradeoffs associated with the design of baseband processing circuitry for mobile devices are well known and are unnecessary to a full understanding of the techniques described herein, additional details are not shown here. Typical functions of the processing circuit 410 include modulation and coding of transmitted signals and the demodulation and decoding of received signals. In several embodiments, processing circuit 410 is adapted, using suitable program code stored in program storage memory 460, for example, to carry out any of the embodiments described below. Of course, it will be appreciated that not all of the steps of these embodiments are necessarily performed in a single microprocessor or even in a single module.

Similarly, several of the techniques and processes described above can be implemented in a network node, such as an eNodeB or other node in a 3GPP network. Figure 6 is a schematic illustration of a node 500 in which a method embodying any of the presently described network-based techniques can be implemented. A computer program for controlling the node 500 to carry out a method according to any of the relevant embodiments is stored in a program storage 530, which comprises one or several memory devices. Data used during the performance of a method according to the embodiments is stored in a data storage 520, which also comprises one or more memory devices. During performance of a method embodying the present techniques, program steps are fetched from the program storage 530 and executed by a Central Processing Unit (CPU) 510, retrieving data as required from the data storage 520. Output information resulting from performance of a method embodying the presently- described techniques can be stored back in the data storage 520, or sent to an Input/Output (I/O) interface 540, which includes a network interface for sending and receiving data to and from other network nodes and which may also include a radio transceiver for communicating with one or more terminal devices.

Accordingly, in various embodiments, processing circuits, such as the CPU 510 in Figure 6, are configured to carry out one or more of the techniques described in detail below. Likewise, other embodiments include radio network controllers including one or more such processing circuits. In some cases, these processing circuits are configured with appropriate program code, stored in one or more suitable memory devices, to implement one or more of the techniques described herein. Of course, it will be appreciated that not all of the steps of these techniques are necessarily performed in a single microprocessor or even in a single module. As noted above, the teaching of the present disclosure relates to the management of emergency calls or other emergency traffic by a terminal device. It should be understood that it will be mentioned herein that "a network cannot carry emergency traffic a network does not support emergency traffic a network is not suitable for emergency traffic'Vetc, and it should be appreciated that this does not necessarily mean that it is technically impossible to carry emergency traffic in such a network, but it may be unsuitable for reliability reasons. For consistency herein, networks are described as being capable of emergency calls or not being capable of emergency calls. The present disclosure discusses how emergency calls are handled differently compared to other (non-emergency) calls. It should however be appreciated that the present disclosure is also applicable to other types of traffic of an emergency-type. For example, it may be that in an emergency situation, such as a natural disaster, a terminal device needs to download information from a server about locations of secure locations, hospitals, etc. Such emergency traffic is also the subject of the present disclosure.

The flow chart in Figure 7 illustrates a method of operating a terminal device according to various embodiments. In step 601 , the terminal device, which is configured to operate in at least a first network that operates according to a first radio access technology, RAT (e.g. a 3GPP RAT) and a second network that operates according to a second, different, RAT (e.g. WLAN or another type of 3GPP RAT), determines which network should be used by the terminal device for sending and/or receiving emergency traffic. Various implementations of step 601 are described in more detail below.

Then, when emergency traffic is to be sent or received by the terminal device, the terminal device establishes a connected to the determined network (step 603).

It will be appreciated that the 3GPP RATs include any one or more of the technologies standardised by the 3rd-Generation Partnership Project (3GPP), including the radio- access technologies known as Long-Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS)/Wideband Code-Division Multiple Access (WCDMA), High Speed Packet Access (HSPA) and Global System for Mobile Communications (GSM). The flow chart in Figure 8 illustrates a method of operating a network node (such as a base station or eNB) according to various embodiments. The method in the network node comprises a step 701 in which the network node sends information to the terminal device that is to be used by the terminal device to determine which of a plurality of networks operating according to different RATs should be used for emergency traffic. Examples of the types of information that can be sent to the terminal device are described in more detail below.

In one embodiment, step 601 comprises the terminal device determining which access network to route an emergency call over based on a set of routing restrictions and/or constraints, and then routing the traffic over such an access network (step 603). In one implementation of this embodiment the routing restrictions and/or constraints may indicate that the terminal device should route emergency calls over a first RAT, e.g. LTE, but not over a second RAT, e.g. WLAN. The routing restrictions and/or constraints may positively indicate which networks or RATs are suitable for emergency traffic, and/or they may positively indicate which networks or RATs are not suitable for emergency traffic. In the latter case, an indication in the routing restrictions and/or constraints that, for example, WLAN is not suitable for emergency traffic, implicitly indicates that the 3GPP network is suitable for emergency traffic.

The routing restrictions and/or constraints is one embodiment of the information provided to the terminal device by a network node (e.g. a serving base station) in step 701 above. In other embodiments, the terminal device can be preconfigured with the routing restrictions and/or constraints.

The use of such routing restrictions and/or constraints may result in the terminal device deviating from a policy, rule, command and/or some other criteria (e.g. an ANDSF policy or the result of evaluating another network interworking feature) which determines access selection and traffic steering. For example, as noted above, access selection and traffic steering rules are being discussed in 3GPP which dictate when the terminal device shall connect to and/or steer traffic to WLAN/3GPP. One example of such a rule was described in Example 1. According to the rule in Example 1 the terminal device shall steer traffic to WLAN when the 3GPP signal is below thresholdl and when the WLAN signal measured by the terminal device is above threshold2. However, as explained above, when the terminal device performs an emergency call, it is not always suitable for the terminal device to perform the call over WLAN. Two example implementations of the rule applied by the terminal device for traffic steering according to this embodiment are shown in Examples 2 and 3 below. if (measured_metricA < threshold 1) && (measured_metricB > threshold2) {

steerNonEmergencyTrafficToWLANO;

} else if (measured_metricA > threshold3) || (measured_metricB < threshold4) {

steerTrafficTo3gpp();

}

Example 2 if (emergencyCallNotOngoing) {

if (measured_metricA < threshold 1) && (measured_metricB > threshold2) {

steerTrafficToWLANO;

} else if (measured_metricA > threshold3) || (measured_metricB < threshold4) {

steerTrafficTo3gpp();

}

} else {

steerTrafficTo3gpp();

}

Example 3

For the traffic steering command based mechanism and the ANDSF policy mechanism described above, the implementation of this embodiment could be different. For example, for the traffic steering command based mechanism the terminal device may ignore a traffic steering command received from the network for traffic associated with emergency calls. In one embodiment, where the terminal device deviates from a traffic steering command for emergency traffic, the terminal device will indicate this to the network. This indication from the terminal device is useful because it is often important that terminal device behaviour is predictable from the network point of view. This embodiment allows for the network to be aware of the reason why the terminal device did not apply a traffic steering command (at least for the traffic associated with the emergency call). In one possible implementation of this embodiment, when the terminal device has an ongoing emergency call, the terminal device can respond to a received traffic steering command with an indication that the terminal device did not apply the traffic steering command. The indication may for example be a negative acknowledgment message (usually called "NACK"). In this case the network may implicitly know that the reason the terminal device did not apply the traffic steering command was due to an ongoing emergency call. Alternatively, it is possible for the terminal device to explicitly indicate to the network that the reason for not applying the traffic steering command was due to an emergency call.

In some embodiments, the information provided by the network in step 701 indicates to the terminal device whether or not the terminal device is allowed to deviate from a policy/rule/traffic steering command for emergency calls. This information can be taken into account by the terminal device when determining which network to use for emergency calls in step 601. The network may be aware of the access network to which the terminal device would connect to due to the policy/rule/traffic steering command (referred here to as the "target access network"), and if the network determines that it is suitable to steer emergency calls over the target access network then the network can indicate to the terminal device that the terminal device is not allowed to deviate from the policy/rule/traffic steering command. For example, if a base station is aware that a particular WLAN is capable of carrying emergency traffic then the base station could, in the traffic steering command, indicate that the terminal device should not deviate from the traffic steering command even in the case of an emergency call.

In some embodiments, when the terminal device moves an emergency call to another access network, the terminal device may be configured to also move other ongoing, non-emergency, traffic to the other access network as well to avoid the terminal device from having ongoing traffic in multiple networks at the same time. For example in a situation where the terminal device has ongoing file transfer protocol (FTP) downloads in WLAN and an emergency call is initiated, the terminal device may (according to some other embodiments herein) route the emergency call to LTE. The terminal device would then also steer the FTP traffic to LTE.

Multiple emergency call capable networks

It may be the case that emergency calls can be routed through multiple different networks that are supported by the terminal device. For example, the terminal device may support GSM, LTE, UMTS and WLAN, out of which GSM, LTE and UMTS may all be suitable for carrying emergency traffic. In one embodiment the terminal device may move the emergency traffic to any of the networks in which emergency traffic can be carried. In another embodiment the network may indicate to the terminal device (in step 701) on which networks emergency calls can be carried. In some implementations this may be realised by the network node sending an indication to the terminal device of the network(s) or RAT(s) that emergency calls cannot be established in. In other implementations the indication sent to the terminal device may indicate the network(s) or RAT(s) that emergency calls can be established in. For example an LTE network may indicate that emergency calls can be carried out in LTE and UMTS, which implicitly means that emergency calls cannot be carried out in any other RAT supported by the terminal device. The indication may be provided in a number of different ways:

By Radio Access Technology family or class - The network may indicate to the terminal device that emergency traffic can or cannot be carried through a certain family or class of Radio Access Technologies (RATs). For example a 3GPP network (e.g., comprising GSM EDGE Radio Access Network (GERAN), UTRAN and E-UTRAN) may indicate to the terminal device that WLAN (e.g., comprising IEEE 802.1 1 b, 802.1 1 g, 802.1 1a and 802.11 η) is not suitable for emergency calls. Positive logic may be used instead, i.e. that the 3GPP network indicates that the 3GPP network is suitable for emergency calls, which implicitly means that other RAT families or classes are not suitable for emergency calls, or at least judged by the 3GPP network to not be suitable for emergency calls.

By Radio Access Technology - The network may indicate to the terminal device that emergency traffic can or cannot be carried through a certain Radio Access Technology (RAT). For example an LTE network may indicate to the terminal device that WLAN is not suitable for emergency calls. Positive logic may alternatively be used, i.e. that the LTE network indicates that LTE and UMTS are suitable for emergency calls which implicitly means that no other RAT is suitable for emergency calls. By Radio Access Network - The network may indicate to the terminal device that emergency calls may be carried out in the indicated networks. For example the network may indicate that emergency calls may only be carried out in LTE network X, LTE network Y and UMTS network Y.

By a particular network node in a network - The network may indicate to the terminal device that emergency calls may be carried out when the terminal device is connected to a particular node or nodes in a network (for example nodes that have the required functionality to carry emergency calls). This could, for example, be an indication that emergency calls can or cannot be carried out through a certain WLAN AP, a certain LTE eNB, etc.

In some embodiments, a suitable RAT family/class, RAT, RAN and/or network node may be indicated (e.g., by a rule) in a standard specification or may be preconfigured in the terminal device instead of being signalled from a network.

In some embodiments the information sent from the network in step 701 can comprise a set of requirements or conditions that are to be met or must be true in order to allow/disallow emergency calls over said RATs, RANs or nodes. For example, the indication or rule could indicate that an emergency call is allowed over a RAT, RAN or node if it supports, e.g., positioning or a certain positioning accuracy, voice call continuity and/or emergency call-back. Requirements or conditions may be evaluated and properties determined based on information acquired from, e.g., standard specifications, a configuration of the terminal device, or signalling from the network.

Depending on e.g., location, deployment and/or the terminal device and/or the network implementation, the information could comprise an empty set.

In some embodiments, the terminal device may, upon handover between network nodes, evaluate whether the network node to which the handover was carried out (this node/cell is often referred to as the "target") supports emergency calls, and if not, the terminal device can move the emergency call to a different network. Different terms may be used for "handover", however what is meant here is that a handover is the procedure in which the terminal device changes the network node with which it is associated. For example, in LTE the terminal device executes handovers from one cell (source cell) to another cell (target cell). If the terminal device has ongoing emergency traffic through a first network node but the node to which a handover is performed does not support emergency traffic, then the terminal device may move traffic to an alternative network. In another example of this embodiment, the terminal device may be associated with a WLAN AP which supports emergency calls, but a handover to a WLAN AP which does not support emergency traffic is performed which would trigger the terminal device to move the emergency traffic to another network, for example to an LTE network which supports emergency traffic.

A benefit of the above embodiment is that where a particular network is initially not suitable for emergency calls (e.g. when the network is first deployed), for example due to the network not supporting some required and/or beneficial features for emergency calls, the network operator could then indicate in the information sent to the terminal device that this network is not suitable for emergency calls. However, if at a later stage the network is upgraded (or for some other reason) the network becomes suitable for emergency traffic, the network can then indicate that emergency calls can be carried out in that network. As one specific example, WLAN networks are currently not considered suitable for emergency calls due to their low reliability. However if in the future the reliability of WLAN networks improves it could be so that they are considered reliable enough for emergency calls, this can be indicated in the information sent to the terminal device.

In some embodiments, when a terminal device tries to establish a connection to a particular network for emergency traffic (e.g. as in step 603), the network (e.g. the network node to which the terminal device is trying to establish the connection) may determine that the terminal device is trying to steer emergency traffic through the network, and the network may evaluate whether it is capable of carrying emergency traffic or that it is suitable to route emergency traffic over that network. If it is determined that the network is capable of carrying emergency traffic the network will admit that traffic (i.e. accept the connection), otherwise the network will not admit that traffic (e.g. by rejecting the connection). Admitting or not admitting can be achieved by allowing or not allowing that particular traffic to be carried over the network (for example by allowing or not allowing the setup of a communication channel such as a bearer for that traffic). Admitting or not admitting could also be achieved by allowing or not allowing any access to the terminal device (e.g. the network may not accept an access attempt by the terminal device). However, it will be appreciated that this embodiment may require the network to know that the terminal device has an alternative network available over which the traffic can be routed. As one example, a WLAN AP may receive an access attempt by a terminal device and the terminal device tries to initiate an emergency call. The WLAN network could reject this terminal device assuming or knowing that the terminal device will instead route the traffic over a 3GPP network (which can be considered more suitable for emergency traffic).

There is therefore provided various ways of managing emergency calls or other emergency traffic for terminal devices that are capable of operating according to multiple radio access technologies that ensure the emergency traffic is routed over a suitable network.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the teaching of the present application. For example, it will be readily appreciated that although the above embodiments are described with reference to parts of a 3GPP network, embodiments will also be applicable to like networks, such as a successor of any current 3GPP network, having like functional components. Therefore, in particular, the terms 3GPP and associated or related terms used in the above description and in the enclosed drawings now or in the future are to be interpreted accordingly.

Examples of several embodiments have been described in detail above, with reference to the attached illustrations of specific embodiments. Because it is not possible, of course, to describe every conceivable combination of components or techniques, those skilled in the art will appreciate that the present techniques can be implemented in other ways than those specifically set forth herein, without departing from essential characteristics of the teaching of this application. The present embodiments are thus to be considered in all respects as illustrative and not restrictive.

Claims

1. A method of operating a terminal device in a first network that is operating according to a first radio access technology, RAT, the terminal device being capable of operating in a second network that is operating according to a second RAT, the method comprising:

determining which of the first network and second network to use for emergency traffic that is to be sent by and/or received at the terminal device (601); and

establishing a connection to the determined one of the first network and second network for sending and/or receiving the emergency traffic (603).

2. A method as defined in claim 1 , wherein the step of determining (601) comprises: evaluating a set of routing restrictions and/or constraints for emergency traffic.

3. A method as defined in claim 2, wherein the set of routing restrictions and/or constraints indicate which of the first network and second network are suitable and/or unsuitable for emergency traffic.

4. A method as defined in claim 2, wherein the set of routing restrictions and/or constraints for emergency traffic override a network selection decision taken according to a network interworking feature that enables and controls interworking between the first network and the second network.

5. A method as defined in claim 1 , wherein the step of determining (601) comprises determining which of the first network and second network to use for emergency traffic using a network interworking feature that enables and controls interworking between the first network and the second network.

6. A method as defined in claim 5, wherein the step of determining which of the first network and second network to use for emergency traffic using a network interworking feature comprises evaluating a rule that determines which network or networks the terminal device should use to send and/or receive non-emergency traffic and/or emergency traffic.

7. A method as defined in claim 6, wherein the rule determines which network or networks the terminal device should use to send and/or receive non-emergency traffic, and the method further comprises the step of receiving an indication from the first network indicating whether the terminal device is permitted to deviate from the rule for emergency traffic.

8. A method as defined in claim 5, wherein the step of determining which of the first network and second network to use for emergency traffic using a network interworking feature comprises applying a command received from the first network relating to a network to use for traffic.

9. A method as defined in claim 5, wherein the step of determining which of the first network and second network to use for emergency traffic using a network interworking feature comprises deviating from a command received from the first network relating to a network to use for non-emergency traffic.

10. A method as defined in claim 9, wherein the method further comprises the step of sending an indication to the first network that the terminal device is deviating from the command received from the first network for emergency traffic.

1 1. A method as defined in claim 9, wherein the method further comprises receiving an indication from the first network that indicates whether the terminal device is permitted to deviate from the command received from the first network relating to the network to use for non-emergency traffic.

12. A method as defined in claim 1 , wherein the step of determining (601) comprises determining which of the first network and second network to use for emergency traffic according to information that indicates the suitability or unsuitability of one or both of the first network and the second network for emergency traffic.

13. A method as defined in claim 12, wherein the information indicates one or more RATs or one or more families or classes of RAT that are suitable or unsuitable for emergency traffic.

14. A method as defined in claim 12, wherein the information indicates one or more network nodes in the first network and/or the second network that are suitable or unsuitable for emergency traffic.

15. A method as defined in claim 12, 13 or 14, wherein the information is received from the first network.

16. A method as defined in claim 12, 13 or 14, wherein the information is preconfigured in the terminal device.

17. A method as defined in claim 1 , wherein the step of determining comprises determining which of the first network and second network to use for emergency traffic by evaluating the first network and/or second network against one or more requirements and/or conditions in order for emergency traffic to be sent and/or received using that network.

18. A method as defined in any preceding claim, wherein the method further comprises the step of:

using the connection to the determined one of the first network and second network to send and/or receive the emergency traffic.

19. A method as defined in claim 18, the method further comprising the step of:

using the connection to the determined one of the first network and second network to send and/or receive any non-emergency traffic that is to be sent by and/or received at the terminal device.

20. A method as defined in any preceding claim, wherein the step of determining (601) is performed on handover between cells in the first network.

21. A method as defined in any preceding claim, wherein the method further comprises:

if the connection to the determined one of the first network and second network for sending and/or receiving the emergency traffic is refused or not allowed by the determined one of the first network and second network, determining an alternative one of the first network and second network to use for emergency traffic that is to be sent by and/or received at the terminal device; and

establishing a connection to the determined alternative one of the first network and second network for sending and/or receiving the emergency traffic.

22. A method as defined in any preceding claim wherein the emergency traffic comprises a voice call to an emergency number.

23. A method as defined in any preceding claim, wherein the first RAT and the second RAT are any of: a 3^rd-Generation Partnership Project (3GPP) standardised RAT, such as Long-Term Evolution (LTE), Universal Mobile Telecommunications System (UMTSyWideband Code-Division Multiple Access (WCDMA), High Speed Packet Access (HSPA) and Global System for Mobile Communications (GSM) and WLAN.

24. A terminal device (400) for use in a first network that is operating according to a first radio access technology, RAT, and a second network operating according to a second RAT, the terminal device comprising:

a processing circuit (410) and transceiver circuitry (420) that are configured to: determine which of the first network and second network to use for emergency traffic that is to be sent by and/or received at the terminal device; and establish a connection to the determined one of the first network and second network for sending and/or receiving the emergency traffic.

25. A terminal device (400) as defined in claim 24, wherein the processing circuit (410) and transceiver circuitry (420) are configured to determine which of the first network and second network to use for emergency traffic by:

evaluating a set of routing restrictions and/or constraints for emergency traffic.

26. A terminal device (400) as defined in claim 25, wherein the set of routing restrictions and/or constraints indicate which of the first network and second network are suitable and/or unsuitable for emergency traffic.

27. A terminal device (400) as defined in claim 25, wherein the set of routing restrictions and/or constraints for emergency traffic override a network selection decision taken according to a network interworking feature that enables and controls interworking between the first network and the second network.

28. A terminal device (400) as defined in claim 24, wherein the processing circuit (410) and transceiver circuitry (420) are configured to determine which of the first network and second network to use for emergency traffic by using a network interworking feature that enables and controls interworking between the first network and the second network.

29. A terminal device (400) as defined in claim 28, wherein the processing circuit (410) and transceiver circuitry (420) are configured to use a network interworking feature by evaluating a rule that determines which network or networks the terminal device should use to send and/or receive non-emergency traffic and/or emergency traffic.

30. A terminal device (400) as defined in claim 29, wherein the rule determines which network or networks the terminal device should use to send and/or receive nonemergency traffic, and the processing circuit (410) and transceiver circuitry (420) are further configured to receive an indication from the first network indicating whether the terminal device is permitted to deviate from the rule for emergency traffic.

31. A terminal device (400) as defined in claim 28, wherein the processing circuit (410) and transceiver circuitry (420) are configured to use a network interworking feature by applying a command received from the first network relating to a network to use for traffic.

32. A terminal device (400) as defined in claim 28, wherein the processing circuit (410) and transceiver circuitry (420) are configured to use a network interworking feature by deviating from a command received from the first network relating to a network to use for non-emergency traffic.

33. A terminal device (400) as defined in claim 32, wherein the processing circuit (410) and transceiver circuitry (420) are further configured to send an indication to the first network that the terminal device is deviating from the command received from the first network for emergency traffic.

34. A terminal device (400) as defined in claim 32, wherein the processing circuit (410) and transceiver circuitry (420) are further configured to receive an indication from the first network that indicates whether the terminal device is permitted to deviate from the command received from the first network relating to the network to use for nonemergency traffic.

35. A terminal device (400) as defined in claim 24, wherein the processing circuit (410) and transceiver circuitry (420) are configured to determine which of the first network and second network to use for emergency traffic according to information that indicates the suitability or unsuitability of one or both of the first network and the second network for emergency traffic.

36. A terminal device (400) as defined in claim 35, wherein the information indicates one or more RATs or one or more families or classes of RAT that are suitable or unsuitable for emergency traffic.

37. A terminal device (400) as defined in claim 35, wherein the information indicates one or more network nodes in the first network and/or the second network that are suitable or unsuitable for emergency traffic.

38. A terminal device (400) as defined in claim 35, 36 or 37, wherein the information is received from the first network.

39. A terminal device (400) as defined in claim 35, 36 or 37, wherein the information is preconfigured in the terminal device.

40. A terminal device (400) as defined in claim 24, wherein the processing circuit (410) and transceiver circuitry (420) are configured to determine which of the first network and second network to use for emergency traffic by evaluating the first network and/or second network against one or more requirements and/or conditions in order for emergency traffic to be sent and/or received using that network.

41. A terminal device (400) as defined in any of claims 24-40, wherein the processing circuit (410) and transceiver circuitry (420) are further configured to use the connection to the determined one of the first network and second network to send and/or receive the emergency traffic.

42. A terminal device (400) as defined in claim 41 , wherein the processing circuit (410) and transceiver circuitry (420) are further configured to use the connection to the determined one of the first network and second network to send and/or receive any non-emergency traffic that is to be sent by and/or received at the terminal device.

43. A terminal device (400) as defined in any of claims 24-42, wherein the step of determining is performed on handover between cells in the first network.

44. A terminal device (400) as defined in any of claims 24-43, wherein the processing circuit (410) and transceiver circuitry (420) are further configured to:

determine an alternative one of the first network and second network to use for emergency traffic that is to be sent by and/or received at the terminal device if the connection to the determined one of the first network and second network for sending and/or receiving the emergency traffic is refused or not allowed by the determined one of the first network and second network; and

establish a connection to the determined alternative one of the first network and second network for sending and/or receiving the emergency traffic.

45. A terminal device (400) as defined in any of claims 24-44, wherein the emergency traffic comprises a voice call to an emergency number.

46. A terminal device (400) as defined in any of claims 24-45, wherein the first RAT and the second RAT are any of: a 3^rd-Generation Partnership Project (3GPP) standardised RAT, such as Long-Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS)/Wideband Code-Division Multiple Access (WCDMA), High Speed Packet Access (HSPA) and Global System for Mobile Communications (GSM) and WLAN.

47. A method of operating a network node in a first network that is operating according to a first radio access technology, RAT, the method comprising:

sending information to a terminal device that is operating in the first network, the information being for use by the terminal device in determining which of the first network and a second network that is operating according to a second RAT to use for emergency traffic that is to be sent by and/or received at the terminal device (701).

48. A method as defined in claim 47, wherein the step of sending information to the terminal device (701) comprises:

sending information comprising a set of routing restrictions and/or constraints for emergency traffic.

49. A method as defined in claim 48, wherein the set of routing restrictions and/or constraints indicate which of the first network and second network are suitable and/or unsuitable for emergency traffic.

50. A method as defined in claim 48, wherein the set of routing restrictions and/or constraints for emergency traffic override a network selection decision taken according to a network interworking feature that enables and controls interworking between the first network and the second network.

51. A method as defined in claim 47, wherein the step of sending information to the terminal device (701) comprises sending a rule or conditions and thresholds for a network interworking feature that enables and controls interworking between the first network and the second network, the evaluation of the rule or conditions and thresholds by the terminal device determining which network or networks the terminal device should use to send and/or receive non-emergency traffic and/or emergency traffic.

52. A method as defined in claim 51 , wherein the evaluation of the rule or conditions and thresholds by the terminal device determines which network or networks the terminal device should use to send and/or receive non-emergency traffic, and the information further comprises an indication of whether the terminal device is permitted to deviate from the rule or conditions and thresholds for emergency traffic.

53. A method as defined in claim 47, wherein the step of sending information to the terminal device (701) comprises sending a command determined according to a network interworking feature that enables and controls interworking between the first network and the second network, the command indicating the network for the terminal device to use for traffic.

54. A method as defined in claim 53, wherein the information further comprises an indication of whether the terminal device is permitted to deviate from the command received from the first network relating to the network to use for non-emergency traffic.

55. A method as defined in any of claims 47-54, wherein the method further comprises the steps of: receiving a request from the terminal device for a connection to be used for emergency traffic; and

rejecting the request if the first network is unsuitable for emergency traffic.

56. A method as defined in any of claims 47-55, wherein the emergency traffic comprises a voice call to an emergency number.

57. A network node (500) for use in a first network that is operating according to a first radio access technology, RAT, the network node comprising:

a processing circuit (510) and interface circuitry (540) that are configured to: send information to a terminal device that is operating in the first network, the information being for use by the terminal device in determining which of the first network and a second network that is operating according to a second RAT to use for emergency traffic that is to be sent by and/or received at the terminal device.

58. A network node (500) as defined in claim 57, wherein the processing circuit (510) and interface circuitry (540) are configured to send information to a terminal device that comprises a set of routing restrictions and/or constraints for emergency traffic.

59. A network node (500) as defined in claim 58, wherein the set of routing restrictions and/or constraints indicate which of the first network and second network are suitable and/or unsuitable for emergency traffic.

60. A network node (500) as defined in claim 58, wherein the set of routing restrictions and/or constraints for emergency traffic override a network selection decision taken according to a network interworking feature that enables and controls interworking between the first network and the second network.

61. A network node (500) as defined in claim 57, wherein the processing circuit (510) and interface circuitry (540) are configured to send a rule or conditions and thresholds for a network interworking feature that enables and controls interworking between the first network and the second network, the evaluation of the rule or conditions and thresholds by the terminal device determining which network or networks the terminal device should use to send and/or receive non-emergency traffic and/or emergency traffic.

62. A network node (500) as defined in claim 61 , wherein the evaluation of the rule or conditions and thresholds by the terminal device determines which network or networks the terminal device should use to send and/or receive non-emergency traffic, and the information sent by the network node further comprises an indication of whether the terminal device is permitted to deviate from the rule or conditions and thresholds for emergency traffic.

63. A network node (500) as defined in claim 57, wherein the processing circuit (510) and interface circuitry (540) are configured to send information that comprises a command determined according to a network interworking feature that enables and controls interworking between the first network and the second network, the command indicating the network for the terminal device to use for traffic.

64. A network node (500) as defined in claim 63, wherein the information sent by the network node further comprises an indication of whether the terminal device is permitted to deviate from the command received from the first network relating to the network to use for non-emergency traffic.

65. A network node (500) as defined in any of claims 57-64, wherein the processing circuit (510) and interface circuitry (540) are further configured to:

receive a request from the terminal device for a connection to be used for emergency traffic; and

reject the request if the first network is unsuitable for emergency traffic.

66. A network node (500) as defined in any of claims 57-65, wherein the emergency traffic comprises a voice call to an emergency number.

67. A computer program product having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable processing circuit or computer, the processing circuit or computer is caused to perform the method of any of claims 1-23 or 47-56.