This invention relates to apparatus and methods for facilitating the transfer of SIM data between a SIM and a remote entity.

A Cellular I nternet-of -Things (loT) system preferably supports low cost terminals, is scalable to huge numbers of terminals per node, and yet is secure, easy to access and robust. Many existing loT systems transfer data between the terminals and servers using internet-protocol traffic. This is traffic that is relayed from source to destination in accordance with an internet protocol.

One example of data that can be carried to and from a Cellular loT device is data that either originates at or is intended for the SIM (subscriber identity module). Every loT device will include a SIM, whether that is a UICC or similar secure element, to enable the device to access the services of one or more communication networks. Normally the data is carried between the SIM and a communication module (such as a modem) in the same loT device. However, some SIM protocols enable traffic to be carried between the SIM and a remote entity such as a server. An example of such as protocol is BIP (bearer independent protocol). BIP runs between a UICC (universal integrated circuit card: a type of SIM card) and a communication module. It enables asynchronous data to be transferred from the SIM to a remote entity.

BIP carries data between the SIM of an loT device and its communications module. The communications module and the core network then carry that UICC data on to the remote entity via internet traffic. Internet protocols (IP) enable flexible routing of packets transmitted as internet traffic. To achieve this, every IP packet incorporates a large addressing overhead. This may not be optimal for bandwidth-limited implementations. Also, IP protocols are not available to some configurations of communications modules.

It is an object of the invention to provide concepts for efficiently transferring SIM data between devices.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, there is provided a communication module. The communication module is configured to receive data from a subscriber identity module (SIM) in accordance with a SIM protocol that is configured to carry data between the SIM and a remote entity. It is also configured to transmit the data towards the remote entity as non-internet protocol traffic. This avoids the high addressing overhead that is associated with routing IP traffic, enabling the SIM data to be transmitted in a more bandwidth efficient manner.

In a further implementation form of the first aspect, the SIM protocol may be the Bearer Independent Protocol (BIP). BIP is an existing protocol that enables data to be exchanged securely with a SIM. Using an existing protocol minimises the changes that have to be made to existing equipment.

In a further implementation form of the first aspect, the communication module may be configured to encapsulate the data in a packet in accordance with a non-SIM protocol. This enables the SIM data to be transmitted in accordance with any desired protocol. In a further implementation form of the first aspect, the communication module may be configured to transmit the data to a gateway that is configured to convert the non-internet protocol traffic to internet protocol traffic. This enables the SIM data to be routed towards the remote entity as internet protocol traffic, which minimises any changes that have to be made to existing remote entities.

In a further implementation form of the first aspect, the communication module may be configured to receive data from the SIM that includes channel initiation information. This enables the communication module to complete functions that are specified by existing SIM protocols.

According to a second aspect, there is provided a network device. The network device is configured to receive data as internet protocol traffic or non-internet protocol traffic, said data being in accordance with a SIM protocol that is configured to carry data between a subscriber identity module (SIM) and a remote entity. It is also configured to transmit that data as non- internet protocol traffic if the data was received as internet protocol traffic and to transmit that data as internet protocol traffic if the data was received as non-internet protocol traffic. The network device is thus able to terminate a non-internet protocol connection for carrying the SIM data. This renders the non-internet protocol portion of the routing essentially invisible to the remote entity, which thus requires minimal modification compared with existing remote entities. In a further implementation form of the second aspect, the network device may be configured to receive the data from the remote entity and transmit it towards a communication module that has a wired connection to the SIM. This enables SIM data to be routed from a remote entity to a SIM.

In a further implementation form of the second aspect, network device may be configured to receive the data from a communication module that has a wired connection to the SIM and transmit it towards the remote entity. This enables SIM data to be routed from a SIM to a remote entity.

In a further implementation form of the second aspect, the network device may be configured to open a socket for carrying internet protocol traffic to receive and/or transmit internet protocol traffic. This enables the communication of SIM data to look identical from the remote entity's perspective to existing mechanisms in which the SIM data is transferred entirely by internet protocol traffic.

In a further implementation form of the second aspect, the network device may be configured to open the socket in accordance with one of the TCP and UDP protocols. TCP and UDP are existing protocols, meaning that any changes to remote entity behaviour are kept to a minimum.

In a further implementation form of the second aspect, the network device may be configured to open the socket responsive to a request from the SIM. This enables the socket to be opened when the SIM needs to exchange data with the remote entity.

In a further implementation form of the second aspect, the network device may be configured to receive the data as internet protocol traffic in accordance with an internet protocol that includes one or more of HTTPS, TCP, CAT-TP, and UDP. HTTPS, TCP, CAT-TP, and UDP are existing protocols that enable data to be exchanged between devices. Using an existing protocol minimises the changes that have to be made to existing equipment.

In a further implementation form of the second aspect, the network device may be configured to transmit the data as internet protocol traffic in accordance with an internet protocol that includes one or more of HTTPS, TCP, CAT-TP, and UDP. HTTPS, TCP, CAT-TP, and UDP are existing protocols that enable data to be exchanged between devices. Using an existing protocol minimises the changes that have to be made to existing equipment. In a further implementation form of the second aspect, the SIM protocol may be the Bearer Independent Protocol (BIP). BIP is an existing protocol that enables data to be exchanged securely with a SI M. Using an existing protocol minimises the changes that have to be made to existing equipment.

According to a third aspect, there is provided a method. The method comprises receiving data as internet protocol traffic or non-internet protocol traffic, said data being in accordance with a SI M protocol that is configured to carry data between a subscriber identity module (SI M) and a remote entity, if the data was received as internet protocol traffic, the method comprises transmitting that data as non-internet protocol traffic. If the data was received as non-internet protocol traffic, the method comprises transmitting that data as internet protocol traffic.

The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings:

Figure 1 shows an example of a communication module in accordance with an embodiment of the invention; Figure 2 shows an example of a network device in accordance with an embodiment of the invention;

Figure 3 shows an example of a method for exchanging data between a SIM and a remote entity;

Figure 4 shows an example of a method for exchanging data between a remote entity and a SIM;

Figure 5 shows an example of a system for transferring data between a UICC and an SM-SR using the BI P-NI P and TCP protocols and a Packet Data Network Gateway;

Figure 6 shows an example of a system for transferring data between a UICC and an SM-SR using the BIP-NI P and UDP protocols and a Packet Data Network Gateway; and Figure 7 shows an example of a system for transferring data between a UICC and an SM-SR using the BI P-NI P protocol and a T8 bearer and a Packet Data Network Gateway. An example of a communication module is shown in Figure 1. The communication module is shown generally at 101. The communication module could be any equipment that enables transmission to and from a device. For example, the communication module could be a modem. The communication module comprises an input 102 that is configured to receive data from a subscriber identity module 104 (SIM). In some implementations, the communication module and the SIM may be contained within the same device. For example, in Figure 1 the communications module and the SIM are shown as being contained within the same housing. In some implementations, the communication module and the SIM may be connected via a wired connection.

The input 102 is configured to receive data from the SIM 104 in accordance with a SIM protocol. This protocol is configured to carry data between the SIM and a remote entity. The communication module 101 further comprises a transmit/receive unit that is configured to transmit the data from the SIM towards the remote entity as non-internet protocol traffic. This may include encapsulating the data in an appropriate packet structure and/or modulating one or more carrier waves to encode the SIM data for transmission. The transmit/receive unit may transmit the data from the SIM directly to the remote entity but it is more likely to transmit the SIM data indirectly to the remote device by transmitting it to an intermediate device first. A suitable intermediate device is the network device shown in Figure 2.

An example of a network device is shown in Figure 2. The network device, which is shown generally at 201 , comprises a receive unit 202 that is configured to receive data as internet protocol traffic or as non-internet protocol traffic. The data is in accordance with a SIM protocol. Again, the SIM protocol is configured to carry data between a SIM (e.g. SIM 104) and a remote entity. The network device also comprises a transmit unit 203. If the receive unit receives its SIM data as internet protocol traffic, the transmit unit is configured to transmit that data as non-internet protocol traffic. Conversely, if the receive unit receives its data as non-internet protocol traffic, the transmit unit is configured to transmit that data as internet protocol traffic. The network device is thus configured to act as a gateway, translating internet traffic to non- internet protocol traffic and vice versa.

The network device may be configured to open a socket that is configured to carry internet protocol traffic whenever it is required to receive or transmit that type of traffic. In some instances, the network device may be configured to open a socket responsive to a request from the SIM 104. (Any such request from the SIM is likely to be forwarded to the network device by the communication module). The socket may be opened by a process in the transmit or receive unit requesting a socket from the protocol stack. The protocol stack may return a socket descriptor to the transmit/receive unit accordingly, e.g. the descriptor may be a socket address comprising an IP address and/or port number for the socket. The network device is preferably configured to open the socket in accordance with an IP protocol, such as a TCP or UDP protocol.

The structures shown in Figure 1 and 2 (and all the block apparatus diagrams included herein) are intended to correspond to a number of functional blocks. This is for illustrative purposes only. Figures 1 and 2 are not intended to define a strict division between different parts of hardware on a chip or between different programs, procedures or functions in software. In some embodiments, some or all of the techniques described herein may be performed wholly or partly by a processor acting under software control. For example, the transmit/receive unit may incorporate an encapsulation unit that is configured to encapsulate the SIM data in an appropriate packet structure under software control. In some embodiments, some or all of the techniques described herein are likely to be performed wholly or partly in hardware. For example, the transmit/receive unit in the communication module may include a transceiver chain. Similarly, the transmit and receive units in the network gateway may be sockets that are configured to receive incoming data. The expression "internet protocol traffic" is used herein to refer to traffic that is relayed in accordance with an internet protocol (IP). An "internet protocol" may be any protocol that is part of any current or future internet protocol suite. An internet protocol typically defines addressing information that enables datagrams to be relayed between two points. Those points may be referred to as the "source" and the "destination" of the IP traffic and they may be in different networks. An IP protocol can thus relay packets across network boundaries. An IP protocol can define packet structures and/or addressing methods that are used to label packets with source and destination information. Examples of current internet protocols include HTTP (hypertext transfer protocol), HTTPS (hypertext transfer protocol over an encrypted connection), TCP (transmission control protocol), CAT-TP (card application toolkit transport protocol) and UDP (user datagram protocol).

The expression "non-internet protocol traffic" is used herein to refer to traffic that is relayed in accordance with a protocol that is not an internet protocol (non-IP). Any suitable protocol could be used. Preferably the protocol for non-internet traffic involves a lower addressing overhead than a typical internet protocol. Preferably the non-internet protocol is able to accommodate devices that are not always on. (In contrast, internet protocols tend to be designed for continually-connected devices.) An example of a non-internet protocol is BIP-NIP (bearer independent protocol over a non-internet protocol). This is a new protocol that is described herein.

The expression "SIM protocol" is used herein to refer to a protocol that enables data to be exchanged directly with a SIM. Some SIM protocols enable data to be exchanged just between the SIM and the "card accepting device" into which the SIM has been inserted. The techniques described herein are likely to be most useful for SIM protocols that enable data to be carried between a SIM and a remote entity, such as a server. An example of a current SIM protocol that can achieve this is BIP (bearer independent protocol).

The expression "SIM" is used herein to refer to any card or module that stores information that a device needs to access the services of a communication network. For example, the term "SIM" is also intended to encompass UICCs (universal integrated circuit cards). The communication module shown in Figure 1 and the network device shown in Figure 2 preferably cooperate to route SIM protocol data from the SIM to the remote entity as non- internet protocol traffic. This cooperation preferably extends to traffic that travels in both directions, i.e. traffic that travels from the SIM to the remote entity and vice versa. This is reflected in Figures 3 and 4.

Figure 3 illustrates the steps of a method for transferring data from the SIM to the remote entity. The communication module receives data from the SIM in accordance with a SIM protocol in step S301. The communication module transmits that SIM data to the network device in step S302. This may involve the communication module encapsulating the data in a packet in accordance with a non-SIM protocol. The network device receives the SIM data as non-internet protocol traffic in step S303. As explained above, the network device can be considered as a gateway that is configured to convert the non-internet protocol traffic to internet protocol traffic and vice versa. Consequently, in this example, the network device transmits the SIM data, as internet protocol traffic, to the remote entity that the data is intended for (step S304).

Figure 4 illustrates the steps of a method for transferring data from a remote entity to the SIM. The network device receives SIM data from a remote entity (step S401 ). This is data that has been prepared by the remote device in accordance with a SIM protocol and is intended for a SIM. The network device receives the SIM data as internet protocol traffic. As explained above, the network device can be considered as a gateway that is configured to convert the non-internet protocol traffic to internet protocol traffic and vice versa. Consequently, in this example, the network device transmits the SIM data to the communication module as non- internet protocol traffic (step S402). The communication module receives the SIM data as non- internet protocol traffic in step S403 and passes that data to the SIM in accordance with the SIM protocol (step S404).

Currently there is no way to transfer SIM data over the air-interface except by using IP traffic. This may not be ideal for devices in the loT sector because routing data using IP protocols involves a large overhead on each packet, e.g. due to the addressing information that is mandated by IP protocols. Communications in the loT sector are often bandwidth constrained, so this is not ideal. It is also frequently unnecessary since many loT devices are only expected to communicate with one remote entity. Having IP addressable loT devices can also pose a security risk by providing a means by which rogue third parties could communicate with them. In addition, IP protocols assume that the recipient of a packet is always connected, whereas many loT devices have limited battery life and are thus designed to only wake intermittently. The apparatus and techniques described herein provide a mechanism whereby SIM data is carried via a non-IP bearer and routed via a modified gateway.

Figures 5 to 7 show practical examples of systems configured to exchange SIM data via non- IP traffic. In each of these examples, data communicated as non-IP traffic by the remote devices appears at an interface in the core network that acts as a gateway. In Figures 5 and 6 that interface is a Packet Data Network Gateway (P-GW) 503, 603. In Figure 7 it is a Service Capability Exposure Function (SCEF) 703 in combination with an IP/non-IP gateway 704. The interface encapsulates the non-IP data so that it can be carried to the server it is intended for as IP traffic. Similarly, the interface retransmits SIM data from the server so that it can be carried to the SIM it is intended for as non-IP traffic. The use of non-IP is an optimisation for the remote device containing the SIM. Non-IP allows communication to and from remote loT devices without the excessive overhead of IP headers.

The use of non-IP traffic may require some modifications to the transport layers in the server. For example, remote entities (such as servers) will preferably be configured to support any encapsulation protocols used by the gateway. They should also be capable of establishing and maintaining some connection with the gateway.

BIP is suitable for implementing multiple different SIM-related tasks. For example, BIP can be used for the SIM card to communicate with some external server and for tasks such as downloading/enabling additional profiles for the SIM. The additional profiles may allow the SIM to authenticate with different core networks. BIP can also be used when the SIM card presents a web server. This application might be used to implement mobile operator-defined management functions on smartphones.

The communication of BIP data via non-IP traffic may embody a new protocol, which can be termed "BIP-NIP" (i.e. BIP over non-IP). Key features of BIP-NIP may include the following:

It can carry BIP channel initiation information

It can carry standard BIP data

Implementation of BIP-NIP by the network device, which acts as the gateway, preferably causes it to establish appropriate sockets for communicating that data. The sockets are preferably established in a manner that appears to the remote entity to be identical to conventional BIP.

BIP-NIP preferably terminates within the communication module and within the network device that implements the gateway. In this way, BIP-NIP remains almost invisible to both the SIM and the remote entity. Some examples are shown in Figures 5 to 7. In each of these examples, the communication module is implemented by a modem (502, 602, 702) that is configured to receive BIP data from a UICC (501 , 601 , 701 ). The remote entity is implemented by a Subscription Manager Secure Routing function (SM-SR: 504, 604, 705). The SM-SR may enable the secure download, enablement, disablement and/or deletion of profiles on the UICC.

Figures 5 to 7 differ in the network device that terminates the BIP-NIP connection. In Figures 5 and 6 the network device is implemented by a P-GW (503, 603). In Figure 6, the network device is implemented by a general IP/non-IP gateway (704). This gateway is preceded by a SCEF 703. The SCEF presents a set of internet-addressable Application Programming Interfaces (APIs) on the core network. It may exchange SIM data with the IP/non-IP gateway via a T8 bearer. Both the P-GW and the IP/non-IP gateway are capable of establishing sockets via UDP/IP or TCP/IP for carrying IP traffic to the SM-SR in a manner that appears the same as conventional BIP. Figures 5 to 7 also differ in the precise protocols that are used. In Figure 5 the internet protocol is HTTPS whereas in Figures 6 and 7 CAT-TP is used. Similarly, in Figure 5 the sockets are established using TCP whereas in Figures 6 and 7 they are established using UDP.

One advantage of the illustrated arrangements is that the remote entity need not alter its behaviour much since the modified P-GW or IP/non-IP gateway behaves in a similar way to a conventional BIP channel. Existing BIP initiation mechanisms will still be available. The UICC is also able to remain unchanged. For example, Figures 5 to 7 show that the UICC remains configured to implement both the BIP protocol and an IP protocol (501 , 601 , 701 ). In Figure 5 that IP protocol is HTTPS. In Figures 6 and 7 it is CAT TP. In all three figures, however, it is the modem (502, 602, 702) that captures that data and encapsulates it for transmission over a non-IP bearer so this function is invisible to the UICC. The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.