WO2018105022A1

WO2018105022A1 - Interfacing node, multi-mode radio device and system including interfacing node and multi-mode radio device

Info

Publication number: WO2018105022A1
Application number: PCT/JP2016/086113
Authority: WO
Inventors: Tien Ming Benjamin Koh; Suan Yee TAN; Takako Hori; Toyoki Ue
Original assignee: Panasonic Intellectual Property Management Co., Ltd.
Priority date: 2016-12-05
Filing date: 2016-12-05
Publication date: 2018-06-14

Abstract

This invention describes the operation of a multi-radio terminal (a multi-mode radio device) comprising of at least one additional radio access technology apart from the 3GPP interface. The solution comprises at least of an interfacing node and the multi-radio terminal. The preferred embodiment describes how the 3GPP interface interworks with a TETRA interface to provide seamless voice communications even in the event the terminal is experiencing bad connectivity on both interfaces. This is made possible if multiple radio UEs are transmitting/receiving on both 3GPP and TETRA radios and the inclusion of TETRA voice framing information in the packets destined for UEs in the LTE coverage. With the framing information and voice frames from the multiple radios, a more complete voice frames could be formed at both the interfacing node and UEs.

Description

INTERFACING NODE, MULTI-MODE RADIO DEVICE AND SYSTEM INCLUDING INTERFACING NODE AND MULTI-MODE RADIO DEVICE

The invention pertains to terminals equipped with multiple radio interfaces. More specifically, it relates to the operation of such terminals in a network assisted manner.

The modern day urban environment is dense with overlapping coverage of ubiquitous wireless networks. Heterogeneous digital radio networks of varying capability, range and usage pepper the typical urban landscape. Amongst the most notable include the 3GPP defined networks (including GSM, UMTS and LTE) used for cellular communications, TETRA that is used in many public safety outfits as well as the shorter ranged WiFi/WLAN that is found in many residential as well as commercial properties.

Due to the customer expectations, many wireless-capable devices are typically equipped with multiple wireless network interface capabilities. Most smartphones are able to access the various flavours of 3GPP (GSM, UMTS and LTE) as well as WLAN networks and also PANs such as Bluetooth.

It is not difficult to envision the possibility of devices that can be easily equipped with the necessary wireless interfaces depending on customer preference or mission requirements. Examples of such flexibility include software solutions such as SDR (Software Defined Radio), NFV (Network Function Virtualisation) as well as hardware-centric solutions such as Project Ara.

With the widespread proliferation of smartphones and wireless devices, the emphasis naturally shifts from the type of network to the service the user expects to receive regardless of the underlying network technology. Users expect seamless voice calls to continue regardless of whether the underlying cellular network has handed over between the GSM, UMTS or LTE flavours of the 3GPP network.

Likewise, it is foreseeable that public safety personnel would expect communications to be continued seamlessly, whether the underlying communications is being carried over TETRA, LTE or some other platform. Similarly, the device is expected to be able to autonomously switch between available networks while minimising service disruption.

Earlier teachings such as PTL 1 proposes a gateway to interconnect the Public Safety and Security (PSS) communication network and public cellular communication network. The gateway converts between PSS and cellular data protocols. However such a solution employs a voice transcoder to convert the voice signals from one format to another, required by the destination network. This results in additional network delay. The solution extends the range of Push-to-Talk (PTT) however it does not provide seamless transition from PTT coverage to cellular coverage.

Another similar teaching PTL 2 uses a dispatch gateway (DG) or real time exchange (RTX) that interfaces to the wireless communications system to provide advanced voice services. However such a solution is based on the older generation of cellular communication where circuit channels are used to provide reliable connections. However, in order to handle the longer circuit switch setup up time, the first talk burst uses pre-established Internet Packet (IP) data session. This complicated setup mechanism is no longer required in today's LTE system. Additionally, the proposed scheme is unable to provide true seamless service.

Yet another teaching PTL 3 offers recommendations on how to effectively utilize the benefits provided by multi-mode radio devices. However, it suffers from the disadvantage of requiring the communicating endpoints to be similarly equipped such that they can negotiate a suitable interface to be used. As such, not fully able to provide seamless service across dissimilarly capable devices.

[PTL 1] US20080171533A1
[PTL 2] US20100142414A1
[PTL 3] US9264987B2

It is an object of the invention to solve the above discussed problems. In particular this invention teaches a way to interwork 3GPP with TETRA to provide seamless voice communications. A method is also disclosed for network-assisted information for interface selection.

Figure 1 is a system configuration figure of the main embodiment; Figure 2 shows the modules in the interfacing node to enable seamless service continuity; Figure 3 shows the TETRA DL framing information being inserted into RTP payload to enable seamless service continuity; Figure 4 shows a dual mode UE architecture; Figure 5 shows how a dual mode UE is able to improve voice frames reception using the proposed solution; Figure 6 summarizes the start-up procedure of the proposed system; Figure 7 shows that for LTE uplink PTT voice frames, framing information is left empty and the field is updated at the interfacing node; Figure 8 is the procedural flow for Figure. 5 which shows how voice frames are buffered, assembled and replaced with voice frames from another radio; Figure 9 is the extension of the procedural flow for Figure 8 that shows the handling of duplicated/missing frames from both radios; Figure 10 shows how the QCI can be set for the PTT service over LTE; Figure 11 shows how the explicit synchronization could be performed between the interfacing node and the SwMI; Figure 12 shows the high level procedural flow of explicit synchronization between SwMI, Interfacing node, EPC and the dual mode UE; Figure 13 shows the inclusion of an additional field, codec identifier in the TETRA DL framing information to enable the use of higher quality voice codec for UEs using PTT service via LTE; Figure 14 shows the scenario of how the additional codec identifier is being used by the transcoder module in the interfacing node to convert high quality encoded voice to a lower quality one for purpose of compatibility; Figure 15 shows a User Equipment multi-mode radio device as it moves within between several physical locations; Figure 16 summarises the behaviour of a multi-mode radio device equipped with the described solution; Figure 17 illustrates the typical message flow between the User Equipment and the Interfacing Node; Figure 18 describes the typical message flow between the User Equipment and the Interfacing Node when communication takes place over a 3GPP defined interface; Figure 19 illustrates the typical message flow between the User Equipment and the Interfacing Node when communication takes place over a TETRA defined interface; Figure 20 provides a functional breakdown of the User Equipment; Figure 21 provides a functional breakdown of the Interfacing Node; Figure 22 depicts the Response message; and Figure 23 depicts the Notification message.

In the following description, for the purpose of explanation, specific numbers, times, structures, protocols, and other parameters are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to anyone skilled in the art that the present invention may be practiced without these specific details.

(Embodiment 1)
In the following description of the preferred embodiment, reference is made to the accompanying drawings from which the invention may be practiced.

Figure 1 shows the interconnection of the invention that allows PTT service extension and seamless voice service. Within the diagram, an interfacing node 1100 is connected to the TETRA network 1000 via TETRA inter-system interface (ISI) to the switching management infrastructure (SwMI) 1000. On the other end, the interfacing node is connected to the LTE evolved packet core (EPC) 1040 at the packet data network (PDN) gateway in short, P-GW. The P-GW could also be connected to other external network e.g. the internet network 1030. The E-UTRAN (Evolved Universal Terrestrial Radio Access Network) comprising of the

eNodeBs

1010, 1020 are connected to the EPC to provide the LTE radio services and indirectly the TETRA extended services. The UEs (the multi-mode radio devices), 1060, 1070, 1080 in order to support seamless advanced voice services, need to at least equip with both LTE and TETRA radios wherein the advanced voice services provide instant two-way half-duplex voice messaging within a group of users of the cellular mobile network.

Figure 2 shows the main components or functionalities present in an interfacing node 1100. The interfacing node 1100 contains an inter-system interface (ISI) module 1110 that supports interconnection to a TETRA SwMI 1000. The mapping function 1120 provides a means to map Individual TETRA subscriber identity (ITSI) to group TETRA subscriber identity (GTSI) to individual mobile subscriber identity (IMSI) and vice versa. The registration of this mapping information could be performed through some graphical user interface (GUI) applications. LTE UE presence monitor 1130 on the other hand is responsible for keeping track of a UE's connection to TETRA PTT service via LTE. The monitor 1130 based on the UE's connection to the interfacing node 1100 will be able to determine whether it requires the PTT service through LTE. The interfacing node 1100 receives TETRA voice frames from SwMI 1000. The encapsulation module 1140, will encapsulate the TETRA voice frames as IP/UDP/RTP format with the insertion of TETRA framing information at the head of the RTP payload as shown in Figure 3 1205. The forwarding module 1150 forwards received LTE PTT frames back to the LTE network as there could be other LTE PTT UEs in the LTE network. The de-capsulation module 1160, will de-capsulate LTE PTT voice frames and commands into TETRA PTT MAC format. The updating module 1170 synchronizes with TETRA network and is responsible for updating framing information in the received LTE PTT voice frames. Lastly, the voice stitching module 1180 in the interfacing node, upon receiving voice frames from both LTE and TETRA networks and in addition, if they originates from the same UE, will be combined. Any duplicated frames that exist during the combining/stitching shall be discarded. Out of sync packets will also be discarded. Stitching is made possible with the inclusion of framing information in the RTP payload as shown in Figure 3 1205. The interfacing node 1000 or

UEs

1060, 1070 and 1080 made use of this information to synchronize the voice frames and possible inclusion of buffering mechanism to aid this synchronization.

Figure 3 shows a LTE PTT voice frame format or a PTT voice frame encapsulated in a RTP packet. This packet format is used when transmitting and receiving in LTE network. The packet comprises of 3 main parts: RTP header 1200, TETRA downlink (DL) framing information 1205 and TETRA voice frames 1210. The TETRA DL framing information contains TETRA multi-frame number 1210, frame number 1220, timeslot number 1230 and reserved fields 1240. For person familiar with the TETRA technology, the former 3 fields correspond to the framing information used in TETRA in which it is the clock of the TETRA system. A UE connected to the TETRA network will know the framing information and any frames received by the UE/interfacing node will correspond to this framing information and TETRA voice frames shall be played out in the correct sequence. Since TETRA voice frames are tagged to the framing information, using the 3 information fields in the LTE PTT voice frame format, received voice frames in LTE can be matched with those voice frames received using the TETRA radio. In this way, out of synch, missing and duplicated voice frames could be identified. The reserved field 1240 is reserved for future use. In the current invention, TETRA DL framing information is updated by the interfacing node 1100.

Figure 4 shows an example of architecture of a dual mode UE 1300 (The

UEs

1060, 1070, 1080 in Figure 1) that could be used to enable seamless voice service when a UE moves from TETRA service area to LTE service area and vice versa. The dual mode UE 1300 is made up of 4 components to support this seamless service: application 1310, algebraic code-excited linear prediction (ACELP) codec 1320, LTE radio and protocol stack 1330 and TETRA radio and protocol stack 1340. Within the application 1310, there exists the control module 1311, synchronized frame and buffering function 1313 and a reduced TETRA stack module 1312. The control module 1311 determines whether LTE radio or TETRA radio or both radios are used for transmitting/receiving PTT voice frames. It could base on the received signal strength of both or either radios to make the decision, e.g. when TETRA radio signal is weak, it could enable LTE radio to allow dual reception and perform voice stitching. The reduced TETRA stack 1312 is used to decode the content of PTT packets where the packets are transmitted over LTE encapsulated in IP/UDP or IP/UDP/RTP format. The content to be decoded comprises of voice frames and TETRA mac and above layers messages. The synchronized frame and buffering function 1313 buffers PTT voice frames from both LTE and TETRA radios, reorders and combines them before sending them for decoding in the ACELP codec 1320.

In an exemplary operation of the solution as seen in Figure 5, the dual mode radio UE1 1430 is at the cell boundaries of eNodeB1 1410 and SwMI 1400, and radio conditions for both LTE and TETRA are bad. Voice frames received from either radios will have missing packets. Voice frames successfully received using TETRA radio is assumed to be 1450. Voice frames received using LTE radio is 1451. Using this invention, improvements could be achieved by combining packets from both radios and result is 1452 where a more complete set of voice frames is received. The numbers in 1450, 1451, 1452, 1460, 1461 and 1462 is a simplified representation of the TETRA framing information for easy illustration where the voice frames are tagged in increasing numbers. This allows seamless voice service especially when a user is located at the cell edge. Similarly for transmission, UE1 1430 at cell edge will send voice frames on both radios. The voice frame format for LTE will be based upon Figure 5 although the framing information 1205 will be left empty. This information will be updated by the interfacing node 1100.

In another exemplary operation of the solution using the same figure, UE2 1440 is under the cell coverage of both LTE and TETRA radios where the LTE service is provided by eNodeB2 1420 and the TETRA service by SwMI 1400. UE2 1440 is moving outwards away from eNodeB2 and LTE coverage. The UE while moving out of the LTE coverage can enable both radios to allow reception of the voice frames from each radio. The UE can then concatenate the received voice frames so that seamless voice service is achieved such that no broken speech is experienced. Voice frames received from TETRA radio 1460 and from LTE 1461, are combined to form a complete speech 1462.

Figure 6 summarizes the start-up behaviour of the proposed system. The system comprises of SwMI 1510, UE under TETRA coverage 1500, interfacing node 1520 connected to both SwMI 1510 and EPC 1530, eNodeB (eNB) 1540 and UE under the LTE coverage 1550.At start-up, the interfacing node 1520 is assigned an IP address 1561 and connected to the EPC 1530 via the P-GW. Talkgroups are set up and ITSI, GTSI and IMSI of the allowed UEs are pre-registered into the system. Through this registration, the interfacing node will be able to map the traffic to the corresponding UEs in the networks. The interfacing node 1520 will also need to synchronize to SwMI 1510 time in the context of framing information as it needs to update the framing information field in the received LTE PTT voice frames and also to perform voice stitching operations. For UEs in the TETRA network, registration to the network with authentication is required 1565. Likewise for UEs in the LTE network, registration and attachment procedure is needed 1566. After attachment, dedicated uplink and downlink channels with QoS class identifier (QCI) 65 are established for the PTT traffic 1567. In the event that multimedia broadcast multicast service (MBMS) is used, multicast service needs to be activated 1568. Interfacing node is made known of a UE's connection to PTT service via LTE through the use of Session Initiated Protocol (SIP) or any other equivalent protocol 1569. On knowing that channels have been established between TETRA and LTE networks, PTT traffic could be directed to and from the networks for the concerned UEs.

Subsequent procedures

1580, 1590 and 1570 are used to set up (join), terminate group calls and transmit data respectively. TETRA commands and voice frames destined for LTE network are encapsulated in IP/UDP or IP/TCP format and IP/UDP/RTP format respectively.

Figure 7 shows that for LTE uplink PTT voice frames, framing information field 1610 is left empty and to be updated by the interfacing node 1620.

Figure 8 shows the procedural flow of Figure 5 involving UE1 1430. In this scenario, the UE 1720 at the cell edge is the UE1 1430 in Figure 5, has both its LTE and TETRA radios enabled and connected to both networks. The presence of the UE 1720 and the UE 1700 under TETRA coverage are already made known to the interfacing node 1710, it could be receiving duplicated commands, one on TETRA radio and the other on LTE radio as represented by 1721 and 1722. Duplicated voice frames could also be received 1730, 1740 and under poor signal conditions for TETRA or LTE or both, the UE could take advantage of this duplication to form a more complete set of voice frames through buffering and assembling. When the UE in this scenario moves further away from the LTE coverage and signal becomes weaker, MBMS multicast service is deactivated if it is used. Any dedicated bearers for LTE PTT shall be released and the interface node 1710 will be notified 1770 e.g. via SIP using an unguaranteed bearer as what VoLTE is using, for IMS signalling. Upon knowing that the UE is no longer connected to PTT service via LTE, interface node will no longer forward any data to it via LTE 1780.

Figure 9 is an extension of the procedure in Figure 8 when both radios are enabled. Here, the floor control is given to the UE 1800 upon its request 1805. Even though both radios are enabled, only one radio will be used to send the request command (U-TX-Demand) to prevent complication. In this example, TETRA command over LTE is shown although TETRA radio can also be used. Though command is sent using only one radio, voice frames are transmitted on both radios 1810, 1820. The interfacing node will have to handle duplication and possibly stitching 1830. This allows other UEs to receive better quality voice.

As TETRA is generally used for PSS scenario and when LTE is used to extend its coverage, there is a requirement to give TETRA services particularly PTT a higher priority as compared to the existing LTE services, since it is used in mission critical operations.

Figure 10 is an illustration of how the QCI could be set for the PTT service over LTE. QCI 1 could be used for PTT although allocation and retention priority (ARP) should be given a lower value than VoLTE 1900 so that the latter is of lower priority and could be pre-empted in times of congestion. Alternatively, QCI 65 which has been assigned for mission critical application could also be used.

In the earlier part of the embodiment, voice frames stitching and duplicated voice frames handling in the interfacing node and UEs are carried out based on the TETRA downlink information field included in the RTP payload. Alternatively, they could also be performed without the additional information field, however this requires explicit synchronization between the interfacing node and UEs.

Figure 11 is used to illustrate this explicit synchronization. The flow is as follows:
1. Interfacing node 2020 and SwMI 2010 performs synchronization.
2. UE 2030 connected to the LTE network performs synchronization to the network clock and UE's RTP timestamp will be based on this clock.
3. Interfacing node 2020 sends a RTP timestamp relating to start of the TETRA hyper-frame, to the UE 2030.
4.Based on this timing information, the UE can relate between RTP timestamp and TETRA framing and synchronize voice frames from the 2 radios without needing to include TETRA framing information in the RTP payload.

Figure 12 is a self-explanatory procedure of the above flow.

In yet another exemplary operation of the solution, a portion of the reserved field 1240 in Figure 3, can be used to carry the codec identifier field as in 2110 in Figure 13. This field enables the use of higher quality voice codec for UEs using PTT service via LTE. This additional "codec identifier" element helps the UE in identifying the codec the voice frame is using and also assist the interfacing node in transcoding.

In Figure 14, calling

UEs

2230, 2240 from LTE network can communicate using a better quality codec so that the called UE(s) in LTE coverage can receive better quality voice. Called UEs 2232, 2221 in TETRA coverage will still receive ACELP encoded voice frames and this is made possible with the use of a transcoder at the interfacing node 2210 to convert encoded voice frames from LTE to ACELP coded format. LTE UE encoded voice frames can be sent every 20ms as opposed to TETRA, which is sent every 56.67ms (except for the 18^th TDMA frame), two 30ms ACELP encoded voice frames. This reduces transcoding time. On the other hand, calling UE from TETRA will use ACELP codec and UE(s) in LTE coverage will receive the ACELP encoded voice frames. No transcoding is required.

(Embodiment 2)
In the following description, the operation of the interfacing node in assisting the multi-mode radio device for power-efficient interface selection is disclosed.

Figure 15 shows a User Equipment (UE) multi-mode radio device as it moves within between several physical locations namely 160, 170 and 175. In this particular scenario, there is a TETRA (Terrestrial Trunked Radio) based network 110 and associated TETRA network 110 and base station 115. There is also a nearby 3GPP Evolved Packet Core (EPC) 100 and associated eNodeB 105 with partially overlapping network coverage as the TETRA base station 115. Scattered within the coverage of these two wider ranged radios are several WLAN AP (access point) 130, 135 and 140 that provide Internet 120 access. Additionally, there is an Interfacing Node 150 that allows for intelligent provision of interface selection information.

In one exemplary operation of the solution, the UE 160 is currently connected to but leaving the range of WLAN AP 130. It had previously received a Resource List containing the details for TETRA base station 115. When the signal strength from WLAN AP 130 drops below a suitable threshold value, UE 160 would proceed to enable its TETRA interface to connect and register with TETRA base station 115. Depending on the current usage profile of UE 160, this connection may take place at an earlier or later time. Illustratively, if there is no ongoing voice and data communications (UE 160 is idle), then it is highly likely that handset may choose to delay turning on the TETRA radio interface until the WLAN interface is completely unusable. This is to prevent unnecessary wastage of power. Correspondingly, if there is an active voice or data session ongoing, UE 160 may decide to pre-emptively prepare the TETRA link in anticipation of a need for seamless handover in the event of disconnection. The triggers or threshold values for determining handover preparation may also be influenced by other factors such as priority of the specific application. As an example, ongoing voice communications in an emergency response talkgroup may have a higher application priority compared to an entertainment application's media stream download.

In another exemplary operation of the solution, the UE 170 is currently connected to TETRA base station 115. As the signal strength of the TETRA radio link to base station 115 steadily dropped as UE 170 moved further afield, it sends a Notification via the TETRA radio link to the Interfacing Node 150. The Notification may include the current radio strength as well as other information such as current usage profile, location information. The Interfacing Node 150 would then respond with a Resource List containing information on 3GPP eNodeB 105. However, due to UE 170 lacking a WLAN interface, information regarding WLAN AP 135 was not included in the Resource List. Alternatively, WLAN AP 135 may also have been omitted from the Response List even if UE 170 was equipped with a WLAN interface but was at that point in time idle and had no usage requirements.

In yet another exemplary operation of the solution, the UE 175 is currently connected on its 3GPP interface to eNodeB 105. The user starts a media streaming session on UE 175 and this is updated to the Interfacing Node 150 in a Notification message as a change in the usage requirement. In response, the Interfacing Node 150 may send a Response List containing information on WLAN AP 135 and WLAN AP 140. UE 175 proceeds to selectively turn on its WLAN interface to listen for the presence of a usable WLAN AP.

Figure 16 summarises the behaviour of a multi-mode radio device equipped with the described solution. After the device is started 500, the default interface is selected as the active interface for data communications 510. This selection is typically based on user history, choice or policy.

After the initial bootstrap, the terminal (the multi-mode radio device) should attempt to contact the Interfacing Node 150 using the default communication interface 520. Information related to contacting the Interfacing Node 150 could have been obtained in an out-of-band manner. This could take the form of a URI (Uniform Resource Identifier), IP (internet Protocol) address or pre-configured via installed application. Identification and authentication may be accomplished via a plurality of known methods such as user name and password, hardware-based authentication (SIM card or other similar identity device) or other schemes (such as MAC address or other hardware identifier).

Once the initial contact and authentication is performed, normal communication between the Interfacing Node 150 and the terminal (the multi-mode radio device) can take place 530. This communication may take place periodically or in an ad-hoc manner when required. Communication typically consists of Notification messages (Figure 23) from the terminal to the Interfacing Node 150 and Response messages (Figure 22) from the Interfacing Node 150 to the terminal.

Depending on the type of the active interface 540, communication with the Interfacing Node 150 may occur differently. The use of an underlying data transport 570 to communicate with the Interfacing Node 150 is typically available for any interface that is able to transmit and receive IP level messages that is able to reach the interfacing Node 150. Such communication is typically via the globally reachable internet. For the other forms of communication, the typical advantages are the reduced overheads and latency of communicating via a native protocol defined by the underlying radio subsystem.

In the event that the multi-mode radio device includes a 3GPP defined interface 550, it may be more efficient to utilise the messages and procedures that 3GPP adopts for ANDSF (Access Network Discovery and Selection Function) entity communications. It is trivial for the skilled person to adapt the messages and procedures defined for ANDSF to match the requirements of the Notification and Response messages defined in this document. While 3GPP only specifically defines 3GPP RATs (Radio Access Technology), WLAN and WiMAX, it is trivial to adopt the standards that OMA DM (Open Mobile Alliance Device Management) working group has defined to extend ANDSF operations to support other types of radio networks. In fact the ANDSF functionality in 3GPP is based on OMA DM standards.

Similarly, in the event that the multi-mode radio device includes a TETRA defined interface 560, a viable communication option is to utilise the TETRA defined Short Data Service (SDS) as the transport layer to communicate with the Interfacing Node 150.

Figure 17 illustrates the typical message flow between the UE 200 and the Interfacing Node 230. Switch application 205 resides within UE 200 and implements the described solution. The data transport interface 210 refers to the interface to the active data communications interface that provides data transport 220 for the messages to be exchanged between the UE 200 and the Interfacing Node 230. As described previously, UE 200 first connects with the Interfacing Node 230 after the initial bootstrapping 240.

After initial registration exchange, UE 200 will periodically send Notification messages to the Interfacing Node 230 to update the Interfacing Node 230 on its current status such as the status of the current connection, its usage requirements or other information such as its current location 245. The Notification message is carried over the selected data transport medium 250. The Interfacing Node 230 receives and processes the message and generates a suitable response 255. The Response message is carried via the data transport connected back to the UE 200. It is worth noting that the message exchange may be asymmetric and can be carried by any data transport 260 on which the UE 200 is reachable. Based on the contents of the Response message, the UE 200 will then proceed to perform the necessary network selection and handover if needful 265.

Figure 18 describes the typical message flow between the UE 300 and the Interfacing Node 360 when communication takes place over a 3GPP defined interface 370. In this scenario, the UE 300 may have been previously configured with the knowledge of the ANDSF address of the Interfacing Node 360. It is also possible that the Interfacing Node 360 only acts as the ANDSF over a restricted geographical location and is locatable via normal procedures defined in 3GPP 375. In any case, the UE 300 makes use of the Access Network Info Request message 380 to send the Notification message to the Interfacing Node 360. Similar to previous descriptions, the Interfacing Node 360 processes the Notification 385 and sends a Response in the form of an Access Network Info Response 390. UE 300 then makes the network selection 395 and handover if necessary 398. It is worth noting that for the Access Network Info Request and Access Network Info Response messages, additional values for non-3GPP defined networks such as TETRA may need to be defined. However, this is a trivial exercise that does not affect the operation of the described solution.

Figure 19 illustrates the typical message flow between the UE 400 and the Interfacing Node 430 when communication takes place over a TETRA defined interface 412. The UE 400 connects to TETRA in 440 via the TETRA defined interface 412. Here, the Switch application 406 utilises the TETRA defined Short Data Service as a transport layer to send the Notification message to the Interfacing Node 430. The Switch application 406 sends report to the Interfacing Node 430 on current status in 445. The tlsds_transfer_req message 450, tnsds_unitdata_req message 455 and U-SDS-DATA message 460 is used to transfer the Notification payload to the TETRA SwMI (Switching and Management Infrastructure) 420 which in turn transfers it to the Interfacing Node 430 via the ISI (Inter-System Interface) ANF-ISISDS-UNITDATA 465. After the Interfacing Node 430 processes the Notification and prepares the Response message 470, it then sends the Response as a payload of the ANF-ISISDS-UNITDATA message 475 back to the SwMI 420 which in turn routes it to UE 400 via the D-SDS-DATA 480 message and tnsds_unitdata_Ind message 485, tlsds_transfer_Ind message 490. After the Switch Application 406 receives the Response message, it proceeds with the network selection and handover decision 495.

The following description provides a functional breakdown of the UE 600 and Interfacing Node 700. In Figure 20, UE 600 contains a module called the Switch Client Application 610. Although this may be implemented at the application layer, it may be more efficient to implement it at the session layer or lower within the part of the operating system of the UE 600 that controls network selection. The important requirement of the switch client application 610 is the availability of interfaces to the data transport service interface 620 that provides data communication services via the data communications subsystem 650. This may be any medium and technology that provides for information exchange via the internet or where the Interfacing Node 700 is reachable (Figure 21).

Preferably the switch client application 610 should be able to access the ANDSF client service interface 630 of the 3GPP subsystem 660 in order to effect the message sequence as described in Figure 18 if a 3GPP defined interface is available. Likewise where the UE 600 contains a TETRA subsystem 670, it should optimally be able to utilise the TETRA SDS service interface 640 in order to effect the message exchange described in Figure 19. Furthermore, it is likely that there might exist some other native or supplementary service interface 680 whereby it is possible for the switch client application 610 to exchange information with the Interfacing Node 700. Examples include the Media Independent Handover Function defined in IEEE 802.21 or the Radio Network Information Service defined in Mobile Edge Computing (MEC).

In the Interfacing Node 700 of Figure 21, it can be seen that the Switch server application 725 has an interface to the data transport service interface 730 which allows data communications with UE 600 via the data communications subsystem 735. Likewise, where the 3GPP subsystem 745 is available, the switch server application 725 is able to respond to ANDSF requests via the ANDSF server service interface 740 to effect communications described in Figure 18. In the event that TETRA subsystem 755 is available, an interface to the TETRA SDS service interface 750 is preferred in order to effect the message exchanges described in Figure 19. Interfaces to other services 760 such as IEEE 802.21 and MEC may also be implemented.

Additionally the Switch server application 725 has access to information in several repositories. The User database 705 repository stores information related to the users of the system. This repository may be consulted in the event of user authentication as well as to retrieve the list of devices that a user may be utilising. The Device database 710 contains information regarding the status and capabilities of registered devices. Capability includes information such as the types of interfaces available on the device and may also include information such as the versions of installed software and hardware that can be used to determine protocol or software compatibility. Status may include whether the device is currently online, its location, reachable address, network requirement profile as well as other information that might be submitted by the device (for example technology-specific information such as wireless or device fingerprints). The Locale database 715 is a repository for local information. The Switch server application 725 may refer to this repository to obtain information regarding available networks at the device location. Relevant network parameters, location, proximity information may be stored here. Possible location identifiers include GPS/GNSS coordinates, or relative parameters such as locality groups, signal strength distance as well as wireless fingerprints. Switch server application 725 may also be able to utilise algorithms or policies to determine the relevant network list for the UE's approximate location. The Requirements database 720 provides a repository of information relevant for assessing and translating the network requirements for a UE or terminal. This repository is typically used when the Switch server application 725 needs to determine a suitable list of candidates to supply to a requesting device. Possible implementations include a simplistic requirement number with corresponding requirements for network bandwidth, latency and jitter or even more complex implementations that breaks down requirements based on type of application that is running on a device or some other form of real time reports or QoS (quality of service) messaging. It is also possible that requirements are assigned based on type of device or some other predictive algorithm.

Figure 22 depicts an implementation of the Response message sent from the Interfacing Node to the UE that typically contains a customised list of usable networks that are in the terminal's vicinity. It should be obvious that this message may be implemented in a number of ways including being carried in the payload of TETRA's SDS service, by adaptation of 3GPP's ANDSF messages or OMA's DM messages. It is also trivial for a skilled person to implement this in the format of a JSON message or XML schema in order to achieve purposes of simplicity of parsing or efficiency of transmission. As such, a simple overview of the various desirable features is given below.

SN 800 is simply used to identify duplicate messages. This is especially useful if the message is transferred over a broadcast medium. The MSG TYPE 810 is used to identify the type of data that this message is carrying. AUTH 815 is a security related field that may be used to authenticate the sender and recipient. Examples include security tokens encrypted and authenticated using PKI (public key infrastructure) or keyed-hash message authentication code (HMAC) based on a pre-shared key between the terminal (the multi-mode radio device) and the Interfacing node. NW TYPE 820 identifies the type of wireless network that the following fields are describing. Hence for a WLAN network, the NW TYPE 820 may be "WLAN", NW SETTING1 830 might contain the SSID, NW SETTING2 840 may contain the encrypted WPA/WPA2 key, NW SETTING3 may contain the channel id and so on. In the event that there are multiple recommended networks in the vicinity, additional sets of NWn TYPE 860, NWn SETTING1 870, NWn SETTING2 880, etcetera may be included in the Response message.

Figure 23 depicts an implementation of the Notification message sent from the UE to the Interfacing Node that typically contains an update or report of the terminal's status. It should be obvious that this message may be implemented in a number of ways including being carried in the payload of TETRA's SDS service, by adaptation of 3GPP's ANDSF messages or OMA's DM messages. It is also trivial for a skilled person to implement this in the format of a JSON message or XML schema in order to achieve purposes of simplicity of parsing or efficiency of transmission. As such, a simple overview of the various desirable features is given below.

SN 900 is simply used to identify duplicate messages. This is especially useful if the message is transferred over a broadcast medium. The MSG TYPE 910 is used to identify the type of data that this message is carrying. AUTH 920 is a security related field that may be used to authenticate the sender and recipient. Examples include security tokens encrypted and authenticated using PKI (public key infrastructure) or keyed-hash message authentication code (HMAC) based on a pre-shared key between the terminal and the Interfacing node.

USAGE 930 is used to report on the UE's current or expected requirement for connectivity. This may take the form of pre-defined levels or some other metric. LOCATION 940 is used to provide UE's location-related information to the Interfacing node. An example would be a GPS/GNSS coordinates. The IF1 TYPE 950 and IF1 VALUE1 960 fields are used to report on any network interface specific information. In one implementation, the IF1 TYPE 950 may contain the value "WLAN" and IF1 VALUE1 may contain "HOMENET" which refers to the SSID of the connected access point. It is possible that there may be a IF1 VALUE2 field with a value of "197" that refers to the received signal strength of the afore-mentioned access point. If the UE has multiple connected radios, then it is likely that there will also be multiple groups of IF1 TYPE 950 and IF1 VALUE1 960 fields in the Notification message.

Claims

A system used to extend and provide seamless TETRA services to multi-mode radio devices, the system comprising:
the multi-mode radio device; and
an interfacing node connected to a 3GPP capable network and TETRA network with the multi-mode radio devices,
wherein the interfacing node enables the multi-mode radio devices to synchronize voice frames received from the multi-mode radio devices via TETRA framing information sent or through explicit time synchronization.
The system according to claim 1, wherein, when configured with users' or devices' related information pertaining to the TETRA group(s) which they belong to, the interfacing node is able to route data from one network to the other.
The system according to claim 2, wherein, when receiving voice frames from TETRA network, the interfacing node will be able to encapsulate the voice frames in IP/UDP/RTP format and forward the encapsulated frames to the 3GPP defined network.
The system according to claim 2, wherein, when receiving TETRA control frames from the TETRA network, the interfacing node will able to encapsulate the voice frames in IP/UDP or IP/TCP format and forward encapsulated frames to the 3GPP defined network.
The system according to claim 2, wherein, when receiving voice and control frames from the 3GPP network, the interfacing node will be able to de-capsulate the frames and forward de-capsulated frames to the TETRA network based on the interface format used between the TETRA network and the interfacing node.
The system according to claim 2, wherein, when receiving encapsulated TETRA voice or control frames from the multi-mode radio device connected and using the 3GPP defined network, the interfacing node will be able to forward these received frames back to the 3GPP defined network.
The system according to claim 2, wherein, when connected to a 3GPP defined network capable of broadcasting and multicasting, the interfacing node is able to serve as a broadcast multicast service centre (BM-SC) or interface with a BM-SC in the network.
The system according to claim 2, wherein, when receiving frames that are able to identify duplicated or missing voice frames, the interfacing node discards duplicated voice frames and combines the voice frames coming from different networks.
The system according to claim 1, wherein the interfacing node transmits framing information that comprises at least one of
TETRA Multi-frame number,
TETRA TDMA frame number and
TETRA timeslot number.
The system according to claim 1, wherein, when not employing the method of explicit sending of framing information to devices to enable the synchronization of voice frames from multiple radios, the interfacing node will comprise a clock where the devices/UEs will have to synchronize to this clock wherein the clock is synchronized to the TETRA network framing time.
The system according to claim 9, wherein the interfacing node is able to send an identifier field together with the voice frame to the 3GPP defined network to indicate the codec used for encoding the voice frame.
The system according to claim 11, wherein the interfacing node comprises a transcoder that transcodes the received encoded voice frames from the 3GPP defined network to the TETRA defined codec voice frames.
The system according to claim 1, wherein the multi-mode radio device supports at least dual mode radios, LTE and TETRA, and is capable of receiving/transmitting and decoding/encoding frames from both radios.
The system according to claim 13, wherein, when receiving frames that are able to identify duplicated or missing voice frames, the multi-mode radio device discards duplicated voice frames and combines the voice frames received from different networks.
The system according to claim 14, wherein the multi-mode radio device is able to synchronize the voice frames received from the different networks using framing information sent by the interfacing node or it synchronizes with the interfacing node's clock that in turn is synchronized to the TETRA network framing time with the multi-mode radio device informed of a time that provides references to the framing timing.
The system according to claim 14, wherein the multi-mode radio device has a controller that decides whether either radio or both radios should be used to transmit or receive voice frames.
The system according to claim 14, wherein the multi-mode radio device is able to base on a codec identifier field in the received voice frames to identify the codec used to decode the voice frame.
An interfacing node, connected to a 3GPP capable network and TETRA network with a multi-mode radio device, the interfacing node comprising:
a encapsulation module that encapsulate the voice frames in IP/UDP/RTP format or IP/UDP format or IP/TCP format when receiving TETRA control frames from the TETRA network,
a de-capsulation module that de-capsulate the voice and control frames when receiving voice and control frames from the 3GPP network,
a forwarding module that forward the encapsulated frames to the 3GPP defined network, forward the de-capsulated frames to the TETRA network.
The interfacing node according to claim 18, wherein, when configured with 3GPP relevant capabilities, the interfacing node is able to respond and operate as an Access Network Discovery and Selection Function (ANDSF) entity.
The Interfacing node according to claim 19, wherein, when configured with Access Network Discovery and Selection Function (ANDSF) capabilities, the interfacing node is able to process and provide additional network types not presently defined in 3GPP, including TETRA networks.
The Interfacing node according to claim 18, wherein, when configured with TETRA relevant capabilities, the interfacing node is able to respond and operate to requests from the multi-mode radio device via TETRA SDS (Short Data Service) messages.
The Interfacing node according to claim 18, wherein, when configured with relevant processing capabilities, the interfacing node is able to dynamically provide a relevant resource list based on usage requirement of the multi-mode radio device.
The Interfacing node according to claim 18, wherein, when configured with relevant processing capabilities, the interfacing node is able to dynamically provide a relevant resource list based on location information of the multi-mode radio device.
A multi-mode radio device, being able to perform network selection based on optimal resource list received over any single radio.
The multi-mode radio device according to claim 24, wherein, when configured with 3GPP relevant capabilities, the multi-mode radio device is able to transmit and process communications with an Access Network Discovery and Selection Function (ANDSF) entity that provides additional network types not presently defined in 3GPP, including TETRA networks.
The multi-mode radio device according to claim 24, wherein, when configured with TETRA relevant capabilities, the multi-mode radio device is able to utilize TETRA SDS (Short Data Service) messages to request for a resource list.
The multi-mode radio device according to claim 24 being able to send status reports to an interfacing node.