Dynamic profile switching

Abstract

Managing network connections at a mobile device comprising an embedded SIM (eSIM) with a first profile comprising at least one international mobile subscriber identity (IMSI). The mobile communicates

Description

Field of the Invention The present application relates to a method and system for managing network connections at a mobile device. In particular, the present application relates to a method and system for dynamic profile switching at a mobile device. Background Subscriber Identity Module, SIM, cards are commonly used to enable a mobile device to connect to a cellular network operated by a Mobile Network Operator, MNO. The MNO can identify and grant network access to the mobile device by inspecting an international mobile subscriber identifier, IMSI, stored on the SIM card. Where a mobile device is within the geographical coverage of its ‘home’ MNO network (i.e. the network of the MNO to which the IMSI belongs), it will be able to communicate data over that home network. To maintain network connectivity when the mobile device moves outside the range of its home network, for example when crossing an international border, devices may be allowed to ‘roam’. Where a roaming agreement exists between the home MNO and a new local MNO, no loss of service will be experienced at the mobile device. Where no roaming agreement is in place, or in cases where roaming is time-limited, maintaining network connectivity requires swapping the SIM card in the mobile device with a new SIM card provided by the new local MNO. An embedded SIM, eSIM, provides an alternative to such swapping of physical SIM cards. An eSIM comprises software installed onto an embedded Universal Integrated Circuit Card, eUlCC, in a mobile device. Once a profile having an IMSI has been installed on the eUlCC, it operates in much the same way as a physical SIM card. Multiple profiles can be loaded onto the eSIM at the manufacturing stage to allow the mobile device to connect to a plurality of networks operated by different MNOs. However, the device manufacturer may have no knowledge of where the mobile device will ultimately be deployed. Overcoming this problem by providing a large number of pre-installed eSIM profiles, or indeed a large number of physical SIM cards, would be impractical. Furthermore, arbitrary and unmanaged switching between a finite number of profiles may result in non-optimal connectivity and / or increased costs, for example when the cost of using a local profile is greater than roaming charges incurred by using another, non-local, profile. There exists a need for a way of managing network connections at mobile devices, particularly mobile devices which may be deployed in one or more of a large number of territories. Summary of the Invention Accordingly, a first embodiment provides a method as defined in claim 1. A second embodiment provides a method as defined in claim 13. Systems configured to carry out either method are also provided. Advantageously, the present methods and systems can be used to manage network connections at a mobile device effectively, and to minimise service disruption at a mobile device. Further advantageously, the present methods and systems allow a mobile device to maintain network connectivity, even when the mobile device moves across one or more borders, Further advantageously, the present methods and systems allow a mobile device to seamlessly connect to multiple cellular networks operated by different MNOs while roaming. Further advantageous embodiments are provided in the dependent claims. Brief Description of the Drawings The present application will now be described with reference to the accompanying drawings in which: Figure 1 is a schematic showing a system in accordance with the present invention. Figure 2A is a schematic showing a mobile device connected to a network provided by a first MNO. Figure 2B is a schematic showing the mobile device of figure 2A connected to a network provided by a second MNO. Figure 3 is a schematic showing a method in accordance with the present invention. Figure 4 is a schematic showing a further method in accordance with the present invention. Figure 5 is a schematic showing a further method in accordance with the present invention. Figure 6 is a schematic showing a further method in accordance with the present invention. Figure 7 is a schematic showing a further method in accordance with the present invention. Figure 8 is a schematic showing a further method in accordance with the present invention. Detailed Description A system 100 according to an aspect of the invention is shown in figure 1. The system comprises a mobile device 102, a server 130 and a Mobile Network Operator, MNO, 170. In preferred embodiments the mobile device 102 is located in a network-enabled vehicle such as a car, truck, drone, plane or an agricultural vehicle such as a combine harvester or tractor. The mobile device 102 may be a network access device, NAD, or modem that allows internet connections to be made between vehicles and networks (e.g. mobile communication networks such as 3G, 4G or 5G networks). The mobile device 102 is able to physically cross borders such as international borders between countries and / or network coverage borders between coverage areas provided by different MNOs. As will be explained in further detail below, the methods, apparatus and systems disclose herein allow mobile device 102 to maintain network connectivity even when it has moved across a border, such as an international border between two or more countries, states or territories and / or borders between regions of network coverage provided by different MNOs, for example within a single country, state or territory. Mobile device 102 comprises an embedded Subscriber Identity Module, eSIM, 104. The eSIM 104 is an embedded Universal Integrated Circuit Card, eUlCC, particularly a machine-to-machine, M2M, eUlCC comprising at least one profile 105. In this example, the eSIM 104 comprises a bootstrap profile 105a and a home profile 105b. The home profile 105b comprises an IMSI which allows connections to be made to the network provided by MNO 170. MNO 170 can identify and grant network access to the mobile device 102 by inspecting the IMSI of the home profile 105b. Where a manufacturer is aware of the geographical location where the mobile device 102 is to be deployed, the home profile 105b can be installed on the eUlCC 104 during manufacture of the eSIM 104 and / or mobile device 102. Alternatively, if the geographical region where the mobile device 102 is to be deployed is not known then the eSIM 104 may be provisioned with a suitable home profile 105b after manufacture of the eSIM 104 and / or mobile device 102. MNO 170 can also identify and grant network access to the mobile device 102 by inspecting the IMSI of the bootstrap profile 105b. The bootstrap profile 105a, which may also be referred to as a provisioning profile, may be pre-installed on the eUlCC 104 to allow the mobile device 102 to connect to any available network anywhere the world. In other words, the bootstrap profile 105a is a type of ‘global’ profile which is not limited to a single network and can allow access to networks provided by a range of MNOs across the world. Again, the eSIM 104 may be provisioned with a suitable bootstrap profile 105a after manufacture of the eSIM 104 and / or mobile device 102. The mobile device 102 further comprises a processor and memory (not shown). The memory comprises computing instructions configured to cause the mobile device 102 to carry out the methods described herein. The mobile device 102 comprises a fallback profile assistant 1 which is hosted in the device 102. The fallback profile assistant 1 is an on-board application which can detect loss of connectivity at the mobile device 102. The mobile device 102 may lose connectivity to a network when using a particular profile. When this happens, the fallback profile assistant 1 can be used to ensure that the elllCC 104 falls back to the appropriate profile, such as the bootstrap profile 105a, in response to the loss of connectivity. Many mobile devices contain in-built / default elllCC fallback mechanisms which rely on receipt of specific network rejection codes at the respective mobile device. Real-world testing highlights the limitations of such in-built / default elllCC fallback mechanisms, especially when network connections have been interrupted or lost. Furthermore, the configuration of in-built / default eUlCC fallback mechanisms cannot be modified without additional OS development by the manufacturer of the eUlCC. The fallback profile assistant 1 overcomes these problems. The fallback profile assistant 1 detects loss of connectivity by polling the current network registration status, using Attention, AT, commands (e.g. AT+CREG:- Status NOT IN (1,5), which is polled for e.g. 5 minutes). After a continual period (e.g. 5 minutes) of no network registration, the fallback profile assistant 1 triggers a Local Swap / Fallback Request to the elllCC 104 using AT commands (e.g. AT+STKENV=211,124). The fallback request may be triggered by the mobile device 102. For example, in cases where the mobile device 102 completely loses connection to the network, it will not be possible for that mobile device to receive e.g. fallback requests from remote resources. Therefore in such cases the fallback request can be triggered locally. In response to the fallback request, the eUlCC 104 switches to a particular profile (e.g. the bootstrap profile 105a) which then allows the mobile device 102 to connect to a wide range of networks provided by various MNOs. Figure 1 also shows an example server 130. It will be appreciated that the server 130 may comprise a plurality of servers distributed over a network. The server 130 comprises a Device Provisioning Service, DPS, 132. The DPS service 132 comprises a DPS event stream 5, a DPS Service module 6 and DPS Rules 7. The DPS event stream 5 ingests DPS-relevant events only. The DPS Service 6 consumes the DPS events and compares against its configured rules 7 to identify the use of non-preferred IMSIs and determine the preferred IMS I. The list of configured rules defines the preferred IMSI per country and the roaming tolerance thresholds. The server 130 comprises a core network, CN, 140 including a packet gateway 2, P-GW. The P-GW 2 publishes various session Event Data Records, EDRs, in Real-Time. The server 130 comprises an event processing module 150. The event processing module 150 comprises an EDR event stream 3 and a stream filter 4. The EDR event stream 3, published by the P-GW2, is ingested and processed. The EDR Event Stream 3 is queried, in-stream, and DPS-relevant events are identified and published downstream at the DPS Event Stream 5. The server 130 comprises core services, SM-SR and MNO Adaptors 8. When a profile switch is required, core services may be invoked to download / enable the preferred profile through the MNO systems. Figure 1 also shows an example MNO 170. The MNO 170 comprises an loT Platform, SM-DP and a Core Network. Networks provided by MNO 170 may include LTE networks, GSM networks, 3G networks, 5G networks, and the like. Figures 2A and 2B show an example mobile device 202 before and after crossing a border 210, respectively. In preferred embodiments the mobile device 202 is a NAD or modem located within a network-enabled vehicle such as a car, truck, drone, plane or an agricultural vehicle such as a combine harvester or a tractor. The mobile device 202 is able to physically cross borders such as international borders between countries and / or network coverage borders between coverage areas provided by different MNOs. In this example, the border 210 is a border which defines a separation of network coverage provided by separate MNOs i.e. a border between a first territory 220a in which a first MNO 270a provides network coverage and a second territory 220b in which a second MNO 270b provides network coverage. Networks provided by the first and second MNOs 270 may include LTE networks, GSM networks, 3G networks, 5G networks, and the like. Border 210 may correspond to an international border between two countries, territories or states, a plurality of borders between multiple countries, territories or states, or a network services border within a single country, territory or state. One or both of the first territory 220a and the second territory 220b may correspond to multiple countries, territories or states in which groups of MNOs have roaming agreements. The mobile device 202 shown in figures 2A and 2B is similar to the mobile device 102 shown in figure 1 and described above. In particular, the mobile device comprises an eSIM 204 and a fallback profile assistant similar to those described previously. In eSIM 204 is an M2M elllCC. The server 230 shown in figures 2A and 2B is similar to the server 130 shown in figure 1 and described above. In this example the server 230 comprises a connection manager 235. As is explained in further detail below, the connection manager 235 is configured for monitoring profile usage at the mobile device 202. In figure 2A mobile device 202 is in the first territory 220a. The eSIM 204 of the mobile device 202 holds a bootstrap profile 205a and a home profile 205b. In figure 2A the mobile device 202 is in a configuration in which the bootstrap profile 205a is disabled and the home profile 205b is enabled. The mobile device has a network connection 260a to the network 272a of the first MNO 270a. The network connection 260a allows the transfer of data to and from the mobile device 202. For example, data such as streaming data, instructions, updates and / or notifications can be transferred between the mobile device 202 and the server 230 via the network connection 260a to network 272a. In figure 2A the mobile device 202 is connected to the network 272a of the first MNO 270a using its enabled home profile 205b. The home profile 205b comprises an IMSI which allows connections to be made to the network 272a of the first MNO 270a. It will be appreciated that the first MNO 270a could also identify and grant network access to the mobile device 202 when the mobile device 202 falls back to the bootstrap profile 205a, by inspecting the IMSI of the bootstrap profile 205a when the boostrap profile 205a has been enabled. However, while the mobile device 202 remains within the geographic range of the first MNO 270a, it is preferred that the mobile device 202 stays connected to the network of the first MNO 270a using the home profile 205b. In figure 2B mobile device 202 has moved into the second territory 220b by crossing border 210. It will be noted that elllCC 204 of mobile device 202 has also gained an alternative profile 205c (methods of how this can be achieved are explained in further detail below). As noted above, and as will be conventionally understood, the border 210 defines a separation of network coverage provided by the first MNO 270a and the second MNO 270b. The second territory 220b is outside the geographic range of coverage provided by the first MNO 270a. This means that, once the mobile device 202 is in the second territory 220b it is no longer able to maintain the network connection 260a to the network 272a provided by the first MNO 270a. In the present example, network coverage can be provided in the second territory 220b by the second MNO 270b. To ensure that the mobile device 202 can send and receive data in the second territory 220b, for example to and from the server 230, then a network connection 260b must be made to the network of the second MNO 270b. In the second territory 220b the mobile device 202 can connect to the new local network provided by the second MNO 270b using one of the following options: (i) remaining on the home profile 205b and using an IMSI of the home profile 205b to roam on the new local network; (ii) enabling the bootstrap profile 205a and using an IMSI of the bootstrap profile 205a to roam on the new local network; or (iii) enabling an alternative profile 205c which allows connections to be made to the new local network 272b (e.g. a profile having an IMSI belonging to / provided by the second MNO 270b, or another MNO having a roaming agreement with the second MNO 270b) and using an IMSI of the alternative profile 205c to connect to the new local network. Each option has certain limitations. Option (i) is not available when there is no roaming agreement between the first MNO 270a and the second MNO 270b. This is typically the case when the first and second territories are non-neighbouring and there are large distances between them. Option (ii) is often territory-dependent and time-limited, since many MNOs only allow roaming devices to connect to their network for a limited amount of time. Option (iii) relies on the elllCC of the device having an alternative profile which can allow connections to be made to the new local network 272b. The methods described below in relation to figures 3 to 8 allow dynamic switching between profiles in order to maintain connectivity at a mobile device is in a particular territory, for example after said mobile device has crossed a border such as a network coverage border. As will be understood, the methods presented herein can make varying use of options (i) to (iii) to effectively manage network connections at a mobile device. Figure 3 discloses an example method 300 according to an aspect of the invention. The method 300 can be used to manage network connections at a mobile device configured for communication with a connection manager. The mobile device could be either of the mobile devices 102 and 202 disclosed in figures 1 and 2, and the connection manager can correspond to computer instructions stored on either of the servers 130 and 230 disclosed in figures 1 and 2. For brevity, the example method 300 will be explained with reference to the mobile device 202 and server 230 shown in figures 2A and 2B. Method 300 begins at step 302 in which the connection manager 235 (located on server 230) determines that the mobile device 202 has enabled the bootstrap profile 205a. The mobile device enables the bootstrap profile 205a in response to crossing the border 210. In particular, the mobile device 202 comprises a fallback profile assistant (as described above) which causes the elllCC 104 to enable the bootstrap profile 105a in response to a loss of connectivity to home network 272a after crossing border 210. The connection manager 235 (located on server 230) determines that the mobile device 202 has enabled the bootstrap profile 205a by receiving a message from and / or polling the fallback profile assistant which can communicate the current status of the eSIM 204 and / or network status of mobile device 202 to the connection manager 235. As will be appreciated, in this example the connection manager 235 can only detect that the mobile device 202 has enabled the bootstrap profile 205a after the mobile device has been able to connect to the new local network 272b using the IMS I of the bootstrap profile 205a. Therefore there may be a short delay between the time when the mobile device 202 falls back to the bootstrap profile 205a and the time when the connection manager 235 actually detects that the bootstrap profile 205a has been enabled. At step 304, the connection manager 235 determines whether the mobile device is currently roaming on the bootstrap profile 205a. In particular, the connection manager 235 determines whether a roaming event has taken place at the mobile device 202 such that the mobile device 202 is connected to the network 272b of the second MNO 270b using an IMSI of the bootstrap profile 205a. The connection manager 235 makes this determination by inspecting information received from the fallback profile assistant i.e. the current status of the eSIM 204 and / or network status of mobile device 202. If the connection manager identifies that the mobile device has connected to the network of the second MNO 270b using an IMSI of the bootstrap profile 205a (‘Y’ branch from box 304 in figure 3), then the method proceeds to step 306. In step 306 the connection manager 235 starts a timer. The timer is used to measure the amount of time that the mobile device 202 has been known to be connected to the network 272b of the second MNO 270b using the IMSI of the bootstrap profile 205a. In step 308 the connection manager 235 determines whether a connectivity tolerance threshold has been met. The connectivity tolerance threshold corresponds to a predetermined maximum usage, by the mobile device 202, of the IMSI of the bootstrap profile 205a to connect to the network 272b. The connectivity tolerance threshold corresponds to an amount of time that the mobile device 202 is allowed to be connected to the network 272b of the second MNO 272b using the bootstrap profile 205a. The connection manager 235 stores and / or is able to access various connectivity tolerance thresholds defined for specific combinations of profiles and MNOs. In the present example, the connectivity tolerance threshold used in step 308 is a roaming tolerance threshold defined for use of the bootstrap profile 205a on the network 272b of the second MNO 270b. The connectivity tolerance threshold is met when the mobile device 202 has been continuously connected to the network 272b of the second MNO 270b using the IMSI of the bootstrap profile 205a for a predetermined period of time, such as one or more days, weeks, months or years. The connection manager 235 determines whether or not the roaming tolerance threshold has been met by comparing the roaming tolerance threshold with the timer that was started in step 306. In the present example, the second MNO 270b allows roaming profiles to be connected to the network 272b for up to 90 days. Once a mobile device has been connected to the network 272b using a roaming profile for the maximum 90 days, then the connection to the network will be refused. In the present example, the roaming tolerance threshold is set to 45 days (i.e. less than the maximum allowed roaming time permitted by the second MNO 270b) so that once the connection manager 235 determines that the mobile device 202 has been connected to the network 272b of the second MNO 270b using the bootstrap profile 205a for 45 days, the connection manager 235 will instruct the mobile device 202 to use a different profile, such as a local profile for the network of the second MNO 270b. This ensures that the mobile device 202 will not reach the maximum roaming time and therefore will not be prevented from using the network 272b. As will be appreciated, the roaming tolerance threshold can be adjusted for each MNO / profile combination. The roaming tolerance threshold may be set to be a different number of days, weeks, months etc. according to how long a particular MNO allows roaming profiles to use its network, and / or how long a mobile device should be allowed to use a roaming profile before switching to e.g. a local profile. By setting the roaming tolerance threshold to e.g. 45 days, the connection manager 235 ensures that the mobile device 202 will remain on the bootstrap profile 205c for some time after crossing a border. This can be useful where the mobile device 202 crosses multiple territories in a short period and it would not be practical or efficient to obtain local profiles for each territory. Conversely, the roaming tolerance threshold may be set to zero e.g. when it is determined that a mobile device should not be allowed to roam on the bootstrap profile when using the network of a particular MNO. Roaming tolerance thresholds for multiple MNO / profile combination may be stored in the connection manager 235, in a local file on the same server as the connection manager 235 and / or remotely from the connection manager 235. Returning to figure 3, if in step 308 it is determined that the connectivity tolerance threshold has not been met (‘N’ branch from box 308 in figure 3), then the method 300 proceeds to step 309. In step 309 the connection manager 235 waits for a predetermined amount of time, for example 12 hours, before returning to the determination at step 308. If in step 308 it is determined that the connectivity tolerance threshold has been met (‘Y’ branch from box 308 in figure 3), then the method 300 proceeds to step 312. In step 312 the connection manager 235 instructs the mobile device 202 to connect to the network 272b using the alternative profile 205c. In particular, the connection manager 235 sends an instruction to the mobile device 202 to connect to the network 272b using an IMSI of the alternative profile 205c. In response, the mobile device 202 enables the alternative profile 205c and connects to the network 272b using an IMSI of the alternative profile 205c. As will be appreciated the example method 300 assumes that, when in the second territory 220b, the ell ICC 204 already contains an alternative profile 205c suitable for connecting to the network 272b provided by the second MNO 270b. In cases where the mobile device 202 crosses border 210 and reaches the second territory 220b without an alternative profile 205c stored in the eUlCC 204 method 300 cannot be used to effectively maintain network connections at the mobile device 202. Figure 4 discloses an example method 400 according to an aspect of the invention. The method 400 can be used to manage network connections at a mobile device, such as the mobile devices 102 and 202 disclosed in figures 1 and 2. In particular, the method 400 can be used to manage network connections at a mobile device which enters a territory with or without a profile suitable for connecting to a new local network provided by a new local MNO in that territory. Many steps of the method 400 are similar to the method 300 shown in figure 3, with similar numerals (e.g. 302, 402) denoting similar steps. The method 400 is distinguished from the method 300 by steps 410 and 411. In step 410, after determining that the roaming tolerance threshold has been met in step 408 (‘Y’ branch from box 408 in figure 4) the connection manager 235 determines whether the eUlCC 204 of the mobile device 202 has at least one alternative profile 205c suitable for connecting to the network 272b provided by the second MNO 270b. If in step 410 it is determined that the eUlCC 204 of the mobile device 202 does not have at least one alternative profile 205c suitable for connecting to the network 272b provided by the second MNO 270b (‘N’ branch from box 410 in figure 4), then the method proceeds to step 411. In step 411 the connection manager 235 instructs the mobile device 202 to download the alternative profile 205c. For example, the mobile device can download the alternative profile from the connection manager 235 or other suitable source using the existing connection (i.e. the roaming connection on the bootstrap profile 205a). After instructing the mobile device 202 to download the alternative profile 205c, in step 412 the connection manager 235 instructs the mobile device to connect to the network 272b (i.e. the new local network provided by the second MNO 270b) using the alternative profile 205c. In particular, the connection manager 235 sends an instruction to the mobile device 202 to connect to the network 272b using an IMS I of the alternative profile 205c. If in step 410 it is determined that the elllCC 204 of the mobile device 202 does already have at least one alternative profile 205c suitable for connecting to the network 272b provided by the second MNO 270b (‘Y’ branch from box 410 in figure 4), then the method 400 proceeds to step 412 (described above). As will be appreciated, the present disclosure can be applied to managing dynamic switching between profiles more generally, for example when the mobile device 202 is connected to a network using a non-optimal profile. Figure 5 discloses an example method 500 according to an aspect of the invention. The method 500 can be used to manage network connections at a mobile device configured for communication with a connection manager. The mobile device could be either of the mobile devices 102 and 202 disclosed in figures 1 and 2, and the connection manager could correspond to computer instructions stored on either of the servers 130 and 230 disclosed in figures 1 and 2. For brevity, the example method 500 will be explained with reference to the mobile device 202 and server 230 shown in figures 2A and 2B. Method 500 begins at step 502 when the connection manager 235 (located on server 230) determines that the mobile device 202 is connected to a network, for example the network provided by the second MNO 270b, using a current profile. In this example, the current profile is the alternative profile 205c. At step 504, the connection manager 235 determines whether the current profile being used to connect to the network is the preferred profile for the mobile device 202 to connect to that network. The connection manager 235 makes this determination by inspecting information received from the mobile device 202. For example, the connection manager 235 may poll the mobile device 202 for information. The information received from the mobile device 202 includes the current IMSI being used by the mobile device 202, details of the network being used by the mobile device 202 and optionally country information for that network. The connection manager 235 uses the received information to determine whether the current profile being used (i.e. the profile corresponding to the current IMSI being used) is the preferred profile. The connection manager 235 makes a rules-based determination of whether the current profile being used is the preferred profile. For example, the connection manager 235 may compare the current profile with the preferred profile defined in a lookup table for that network. The lookup table may be stored at the connection manager 235. If in step 504 it is determined that the current profile being used to connect to the network is not the preferred profile (‘N’ branch from box 504 in figure 5), then the method 500 proceeds to step 506. In step 506 the connection manager 235 starts a timer. The timer is used to measure the amount of time that the mobile device 202 has been known to be connected to the network 272b of the second MNO 270b using the IMSI of the non-preferred profile (i.e. the alternative profile). In step 508 the connection manager 235 determines whether a connectivity tolerance threshold has been met. The connectivity tolerance threshold corresponds to a predetermined maximum usage, by the mobile device 202, of the IMSI of the non-preferred profile to connect to the network 272b The connectivity tolerance threshold corresponds to an amount of time that the mobile device 202 is allowed to be connected to the network 272b of the second MNO 272b using the non-preferred profile. The connection manager 235 stores and / or is able to access various connectivity tolerance thresholds defined for specific combinations of profiles and MNOs. In the present example, the connectivity tolerance threshold used in step 508 is defined for use of any profile other than the bootstrap profile 205a on the network 272b of the second MNO 270b. The connectivity tolerance threshold is met when the mobile device 202 has been continuously connected to the network 272b of the second MNO 270b using the IMSI of any profile other than the bootstrap profile 205a for a predetermined period of time, such as one or more days, weeks, months or years. The connection manager 235 determines whether or not the connectivity tolerance threshold has been met by comparing the roaming connectivity threshold with the timer that was started in step 506. In the present example, the connectivity tolerance threshold has been set to 1 hour. This may be because the charges associated with using the local profile 205c to connect to the network 272b of the second MNO 270b are more expensive than using the bootstrap profile 205a, and / or because better network coverage will be provided by the bootstrap profile 205a. Setting the connectivity tolerance threshold to 1 hour reduces the probability of repeated switching when e.g. the device is connected to network 272b for only a short period. If in step 508 it is determined that the connectivity tolerance threshold has not been met (‘N’ branch from box 508 in figure 5), then the method 500 proceeds to step 509. In step 509 the connection manager waits for a predetermined amount of time, for example 1 minute, before returning to the start of step 508. If in step 508 it is determined that the connectivity tolerance threshold has been met (‘Y’ branch from box 508 in figure 5), then the method 500 proceeds to step 512. In step 512 the connection manager 235 instructs the mobile device to connect to the network (i.e. the new local network provided by the second MNO 270b) using the preferred profile. The preferred profile may be the bootstrap profile 205a. In particular, the connection manager sends an instruction to the mobile device 202 to connect to the network using an IMS I of the preferred profile. In response, the mobile device 202 enables the preferred profile and connects to the network using an IMSI of the preferred profile. As will be appreciated, method 500 may be augmented with steps similar to steps 410 and 411 described above, i.e. the method 500 may additionally include determining whether or not the elllCC 204 of the mobile device 202 holds the preferred profile and, if not, instructing the mobile device 202 to download the alternative profile. Figure 6 discloses an example method 600 according to an aspect of the invention. The method 600 can be used to manage network connections at a mobile device configured for communication with a connection manager. The mobile device could be either of the mobile devices 102 and 202 disclosed in figures 1 and 2, and the connection manager could correspond to computer instructions stored on either of the servers 130 and 230 disclosed in figures 1 and 2. For brevity, the example method 600 will be explained with reference to the mobile device 202 and server 230 shown in figures 2A and 2B. Method 600 begins at step 602 in which the mobile device 202 connects to its home network using the home profile 205b stored on the ell ICC 204 (figure 2A). At step 604 the mobile device 202 loses connection to the home network after crossing border 210 (figure 2B). Once the border 210 has been crossed, the mobile device 202 will be out of the range of the home network 272a. At step 606 the mobile device 202 enables the bootstrap profile 205a. In particular, the fallback profile assistant of mobile device 202 causes the eUlCC 104 to enable the bootstrap profile 105a in response to a loss of connectivity to home network 272a after crossing border 210. This allows the mobile device 202 to connect to the new local network 272b in the second territory 220b. At step 608, the mobile device 202 connects to the new local network using the bootstrap profile 205a. In this example, the mobile device 202 connects to the network of the second MNO 270b using an IMSI of the bootstrap profile 205a. In step 610 the mobile device 202 receives an instruction to download an alternative profile 205c to the eUlCC 204. This instruction is sent from the connection manager 235 to the mobile device 202 when the eUlCC 204 does not hold an alternative / preferred profile suitable for connecting to the network of the second MNO 270b. It will be appreciated that step 610 is optional: if the mobile device 202 already holds an alternative / preferred profile suitable for connecting to the network of the second MNO 270b then no instruction will need to be sent. In response to the received instruction, the mobile device 202 downloads the alternative profile. As is explained above, connection manager 235 is able to identify a suitable alternative profile suitable for connecting to the network of the second MNO 270b. In step 612 the mobile device 202 receives an instruction to connect to the new local network 272b using the alternative profile 205c. This instruction is sent from the connection manager 235 to the mobile device 202 when the connection manager 235 determines that a connectivity tolerance threshold, such as a roaming tolerance threshold, has been met. In response to the received instruction, the method 600 proceeds to step 614 in which the mobile device disconnects from the local network 272b, disables the bootstrap profile 205a and enables the alternative profile 205c. At step 616 the mobile device 202 connects to the local network 272b (the network of the second MNO 270b) using the alternative profile 205c. As will be appreciated, the methods 300, 400, 500 and 600 relate to managing network connections at a mobile device by a connection manager. In these examples the connection manager can be implemented in a server which is remote from the mobile device. However, in optional embodiments the connection manager may be implemented locally on the mobile device. In further optional embodiments, one or more steps of the above methods may be carried out at the mobile device, rather than at the (remote) connection manager. Figure 7 discloses an example method 700 where some steps are carried out at the mobile device. Figure 8 discloses an example method 800 where all steps of the previous methods are carried out at the mobile device. Figure 7 discloses an example method 700 according to an aspect of the invention. The method 700 can be used to manage network connections at a mobile device, such as the mobile devices 102 and 202 disclosed in figures 1 and 2. Many steps of the method 700 are similar to the method 600 shown in figure 6, with similar numerals (e.g. 602, 702) denoting similar steps. The method 700 is distinguished from the method 600 by steps 710, 712 and 713. In step 710 the mobile device 202 receives an instruction to connect to the new local network 272b using an alternative profile 205c. This instruction is sent from the connection manager 235 to the mobile device 202 when the connection manager determines that a connectivity tolerance threshold, such as a roaming tolerance threshold, has been met. In response to the received instruction, the method 700 proceeds to step 712 in which the mobile device 202 determines whether the elllCC 204 has at least one alternative profile, particularly an alternative profile suitable for connecting to the network 272b of the second MNO 270b. If in step 712 it is determined that the elllCC 204 of the mobile device 202 does not have at least one alternative profile 205c suitable for connecting to the network 272b provided by the second MNO 270b (‘N’ branch from box 712 in figure 7), then the method proceeds to step 713. In step 713 the mobile device 202 downloads the alternative profile 205c. For example, the mobile device 202 can download the alternative profile 205c from the connection manager 235 or other suitable source using the existing connection (e.g. the roaming connection on the bootstrap profile 205a). After downloading the alternative profile 205c, the method proceeds to step 714, which is similar to step 614 explained previously. If in step 712 it is determined that the elllCC 204 of the mobile device 202 does have at least one alternative profile 205c suitable for connecting to the network 272b provided by the second MNO 270b (‘Y’ branch from box 712 in figure 7), then the method proceeds to step 714, which again is similar to step 614 explained previously. The advantage of method 700 over method 600 is that the responsibility for determining whether the mobile device needs to download an alternative profile is offloaded from the connection manager 235 to the mobile device 202. In some embodiments it may be beneficial to offload all steps carried out by the connection manager 235 to the mobile device 202. Figure 8 discloses an example method 800 according to an aspect of the invention. The method 800 can be used to manage network connections at a mobile device, such as the mobile devices 102 and 202 disclosed in figures 1 and 2. Many steps of the method 800 are similar to the method 700 shown in figure 7, with similar numerals (e.g. 702, 802) denoting similar steps. The method 800 is distinguished from the method 700 by steps 810, 811 a and 811 b. In step 810 the mobile device 202 starts a timer in response to connecting to a new local network (i.e. the network 272b of the second MNO 270b) using the bootstrap profile 205a. The timer is used to measure the amount of time that the mobile device 202 has been connected to the network of the second MNO 270b using the IMS I of the bootstrap profile 205a. In step 811a the mobile device 202 determines whether a connectivity tolerance threshold has been met. The connectivity tolerance threshold is similar to one or more of the connectivity tolerance thresholds described above in relation to the previous methods. The mobile device 202 determines whether or not the roaming tolerance threshold has been met by comparing the connectivity tolerance threshold with the timer that was started in step 810. If in step 811a it is determined that the connectivity tolerance threshold has not been met (‘N’ branch from box 811a in figure 8), then the method 800 proceeds to step 811 b. In step 811 b the mobile device 202 waits for a predetermined amount of time, for example 1 minute or 12 hours, before returning to the start of step 811a. If in step 308 it is determined that the connectivity tolerance threshold has been met (‘Y’ branch from box 811a in figure 8), then the method 800 proceeds to steps 812, which is similar to step 712 explained previously. The advantage of method 800 over e.g. method 700 is that the determination of whether the mobile device has met a connectivity threshold is carried out at the mobile device 202, which may allow a more accurate determination of the amount of time that the mobile device has been connected to the network of the second MNO 270b on the bootstrap profile 205a. Furthermore, making the determination of whether the mobile device 202 has met a connectivity threshold locally at the mobile device 202 means that this method step does not rely on an over-the-air connection to a remote resource, such as the connection manager 235. This is particularly useful in areas of poor coverage where it may be more appropriate to rely on local computing resources rather than remote resources only accessible via unreliable or weak connections to the network. Modifications can be made to that herein described without departing from scope of the present application which is intended to be limited only insofar as is necessary in the light of the claims that follow. For example, the methods 300, 400, 600, 700 and 800 described herein may be adapted to situations in which a mobile device uses a non-preferred profile (rather than the bootstrap profile) to connect to a network. In such examples the connectivity threshold may be met when the mobile device has used the non-preferred profile for a predetermined amount of time. The mobile device 102, 202 may be any suitable mobile computing device, such as a NAD or modem locatable in a vehicle. Alternatively the mobile device 102, 202 may be hardware components of the vehicle which allow the vehicle to connect to a network, such as a cellular or radio access network. Alternatively the mobile device 102, 202 may be a user device such as a mobile phone, tablet or laptop, which may be locatable within a vehicle and which may be configured to provide a local network within a vehicle. The words comprises / comprising when used in this specification are to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Claims

09 06 251. A method of managing network connections made by a mobile device, the mobile device comprising an embedded subscriber identity module, eSIM, 5 comprising at least a first profile, the first profile comprising at least oneinternational mobile subscriber identifier, IMS I, the mobile device being configured for communication with a connection manager configured for monitoring profile usage at the mobile device, wherein the eSIM is a machine-to-machine embedded universal integrated circuit card, M2M eUlCC, the10 method comprising:identifying, by the connection manager, that the mobile device has connected to a network provided by a mobile network operator, MNO, using an IMSI of the first profile, wherein the connection manager stores a plurality of connectivity tolerance thresholds defined for particular combinations of 15 profiles and MNOs;measuring, by the connection manager, the amount of time that the mobile device has been connected to the network using the IMSI of the first profile;determining, by the connection manager, whether a connectivity 20 tolerance threshold stored by the connection manager and defined for thecombination of the first profile and the MNO has been met by the mobile device, wherein the connectivity tolerance threshold corresponds to a predetermined maximum usage, by the mobile device, of the IMSI of the first profile to connect to the network, wherein the connectivity tolerance threshold 25 has been met when the mobile device has been connected to the networkusing the IMSI of the first profile for a predetermined period of time; andinstructing, by the connection manager, the mobile device to connect to the network using an IMSI of an alternative profile when the connectivity tolerance threshold defined for the combination of the first profile and the30 MNO has been met.09 06 252. A method according to claim 1, wherein the first profile is a bootstrap profile.

3. A method according to claim 1 or claim 2, wherein the step of identifying, by the connection manager, that the mobile device has connected to a network5 using an IMSI of the first profile includes identifying that a roaming event hastaken place at the mobile device.

4. A method according to any preceding claim, wherein the connectivity tolerance threshold is a roaming tolerance threshold.

05. A method according to any preceding claim, wherein the connectivity tolerance threshold has been met when the mobile device has been connected to the network using the IMSI of the first profile for one or more days, weeks, months or years.

56. A method according to any preceding claim, wherein the method further comprises instructing, by the connection manager, the mobile device to download the alternative profile.20 7. A connection manager comprising one or more processors and memory,wherein the memory comprises computer instructions that, when executed by the one or more processors, are configured to cause the connection manager carry out the method of any one of claims 1 to 6.25 8. A connection manager according to claim 7, wherein the connection manageris located on a server.

9. A connection manager according to claim 7, wherein the connection manager is located on the mobile device.09 06 2510. A method of managing network connections made by a mobile device, the mobile device comprising an embedded subscriber identity module, eSIM, comprising at least a first profile, the first profile comprising at least one5 international mobile subscriber identifier, IMS I, the mobile device beingconfigured for communication with a connection manager configured for monitoring profile usage at the mobile device, wherein the connection manager stores a plurality of connectivity tolerance thresholds defined for particular combinations of profiles and mobile network operators, MNOs, and10 wherein the connection manager is configured for measuring the amount oftime that the mobile device has been connected to a network provided by a MNO using an IMSI of the first profile, wherein the eSIM is a machine-to-machine embedded universal integrated circuit card, M2M eUICC, the method comprising:15 connecting, by the mobile device, to the network provided by the MNOusing an IMSI of the first profile;receiving, by the mobile device and from the connection manager, an instruction to connect to the network using an IMSI of an alternative profile when a connectivity tolerance threshold stored by the connection manager20 and defined for the combination of the first profile and the MNO has been met,wherein the connectivity tolerance threshold corresponds to a predetermined maximum usage, by the mobile device, of the IMSI of the first profile to connect to the network, wherein the connectivity tolerance threshold has been met when the mobile device has been connected to the network using the25 IMSI of the first profile for a predetermined period of time; andconnecting, by the mobile device, to the network using an IMSI of the alternative profile.11 .A method according to claim 10, wherein the first profile is a bootstrap profile.3009 06 2512. A method according to claim 10 or claim 11, wherein the step of connecting, by the mobile device, to a network using an IMSI of the first profile is carried out in response to a loss of connectivity.5 13. A method according to any one of claims 10 to 12, wherein the step ofconnecting, by the mobile device, to a network using an IMSI of the first profile is carried out in response to a roaming event.

14. A method according to any one of claims 10 to 13, wherein the method further 10 comprises receiving, by the mobile device and from the connection manager,an indication that the roaming tolerance threshold has been met.

15. A method according to any one of claims 10 to 14, wherein the method further comprises receiving, by the mobile device and from the connection manager, 15 an instruction to download the alternative profile.

16. A mobile device comprising a connection manager configured to carry out the method of any one of claims 10 to 15.20 17. A mobile device according to claim 16, wherein the mobile device is a networkaccess device.

18. A mobile device according to claim 16 or claim 17, wherein the mobile device is located in a network-enabled vehicle such as a car, truck, drone or plane.

Images