US20090212901A1

US20090212901A1 - Arrangement At A Mobile Data Unit

Info

Publication number: US20090212901A1
Application number: US11/665,413
Authority: US
Inventors: Mikael Langstrom; Per Westermark; Patrick Persson
Original assignee: Falt Communications AB
Current assignee: Falt Communications AB
Priority date: 2004-10-14
Filing date: 2005-10-12
Publication date: 2009-08-27
Also published as: SE0402505L; JP2008517522A; WO2006041399A2; SE0402505D0; EP1806020A2; US20170078958A1; CN101120606A; CN101120606B; WO2006041399A3; HK1117983A1; US10136382B2; EP1806020A4; US20140106744A1

Abstract

The invention is based on a platform that has both hardware and software. The latter includes, amongst other things, an algorithm to solve the problem encountered when, on passing between countries and operators, data services have to roam between mobile networks. The invention handles and solves existing technical limitations such as existing roaming logic for switches between operators not taking into account: which services the “original” operator has activated; geographical coverage; different costs for different services; and, whether services other than speech can function in the selected network.

Description

BACKGROUND

At present, when using mobile communication, whether it be for speech or data, problems arise when geographic movement results in switches between operators. This is particularly the case when national boundaries are crossed.
Existing roaming logic for switches between operators does not, for example, take into account:

- Which services (speech or various data configurations) the “original” operator has activated.
- Geographical coverage.
- Different costs for different services.
- Whether services other than speech can function in the selected network.

On the whole, existing roaming logic has been developed for speech communication and, as a result, there are certain shortcomings when communication is between machines.
The mobile data services offered in today's mobile data networks handle roaming both in the national network and internationally. The latter is handled by the operator concluding contracts with, most usually, a number of operators in other countries.
When, for example, GSM was launched, speech was and, to a large extent, still is the only or the most common use. With operators and telecom suppliers increasing their range of services (e.g. MMS, GPRS, EDGE and UMTS), roaming has become more complex.
When a subscription leaves the “original” operator's national network and enters a different country, the roaming logic built into telephones and SIM cards searches for the operators with which the original operator has agreements. It then makes a selection amongst those it comes into contact with.
If operator A has agreements with B, C, D and E in a foreign country, the choice of operator B, C, D or E is, when the subscription changes countries, random. If the application is speech, then roaming will, in all probability, be successful. However, if the application is, for example, MMS, GPRS, EDGE or UMTS, then the selected foreign operator must have support for the technology in question.
The identified difficulties hinge on the mobile service user not being able to control operator choice so as to achieve optimum results when confronted by the problems outlined below.
Problem 1 is where operators C, D and E support the required technology, but operator B does not. Thus, if the subscription from operator A roams to B, then the application will not work. Because the existing roaming logic in operators' networks and in SIM cards does not take support for various technologies into account, the subscription will stay with operator B.
Problem 2 is where operators have different prices for their services. For example, the subscription with original operator A roams, by chance, to operator C. The service works, but operators D and E are considerably cheaper than C and would thus be the logical choice.
Problem 3 is where, for strategic reasons, operators have different geographical coverages. For example, operator D covers 95% of a country, whereas operator E covers only 50% of this country. Given equal service charges, the logical choice is, of course, operator D. However, with existing roaming logic, the subscription's choice of operator is random.
In all probability, virtual operators will solve problem 1 by allowing their subscriptions to roam only to those operators who support the requisite technologies. However, problems 2 and 3 remain.
If it is assumed that, to overcome roaming problem 1, virtual operators select only one operator in each country, then this solution has the disadvantage that the application will not work if the selected operator's service goes down.
The problem of inadequate roaming technology became clear when vans/trucks were equipped for monitoring certain transport movements in which the cargo space was to be kept security sealed and the objective was to follow the vehicle's physical movements from a supplier in one country to a recipient in another.

DESCRIPTION OF THE INVENTION

Using the communication services platform described in the present application, the present invention solves the above problem by finding an operator who provides services that handle data communication (e.g. machine to machine). The platform is dynamic and independent of the form of communication. If the platform has a local network on the vehicle, then cameras, alarm sensors, other detectors, indicators, etc. can be monitored as desired. Similarly, if a GPS receiver is connected into the network, position data can be relayed. The platform's software handles data service roaming and, specifically, data-to-data communication in mobile networks when moving between countries and operators.
It is common for goods to be transported by trucks. The value and properties of the goods may be of such a nature that the haulier wishes to monitor their transport. The truck can then be equipped with the platform described in this application (a mobile data unit) that is connected to various modules, e.g. a telephone module that transmits the parameters to be monitored and a GPS module for continuous following of the truck's physical position. When national boundaries are passed, the services offered by operators often change. Unfortunately, today's roaming algorithms are optimised for speech. However, the algorithm system described in this patent prioritises data communication (i.e. machine to machine) and handles it optimally.
For tracking missing goods, hauliers may wish to monitor, for example, when the cargo space is opened. Both time and place can be monitored by having (in the network) sensors that register door opening or the breaking of the security seal. Additionally, the mobile data unit can receive other important information for transmission to selected receivers. It would be possible to measure distance driven so that, as the vehicle approaches a service unit, services could be ordered. Similarly fuel consumption could be measured and filling suggested at suitable stations with contracted suppliers.
Trucks with separate trailers are often used for goods transport. Hauliers with many vehicles can find it difficult to keep track of where all their trailers are at any one time. When it is separated from the tractor unit and the driver, each trailer becomes anonymous and it is often problematic to pinpoint its physical location. Such trailers can be equipped with a mobile data unit (as described and defined in this patent) containing a GPS module and a power backup so that, when the tractor unit leaves the trailer, the haulier can easily track the trailer and discover its position. Furthermore, driver changes and driving times can, if so wished, be recorded. The transport of certain goods, e.g. chilled wares, can require continuous or regular monitoring of temperatures.

INTRODUCTION—DRAWINGS

FIG. 1 shows the modular structure of the platform that forms a mobile data unit.

FIG. 2 is a schematic of communication and algorithm processing.

FIG. 3 shows an example algorithm.

FIG. 4 shows an application for trucks.

FIG. 5 shows a connection diagram for power supply and battery backup in the application for trucks.

DETAILED DESCRIPTION

Description of the Platform
Referring to FIG. 1, the platform can be simply described as a modularly constructed electronic apparatus, the modules of which can be chosen to answer the unique needs of the desired application. For example, the platform can comprise: a processor (1); various types of memory, e.g. RAM (2) and flash (3); a GPS module (4); an Ethernet (5); a power supply (6); and, various digital and analogue inputs. The software contains the unique algorithms that are critical for the functionality detailed in this patent application.
FIG. 2 gives an example and description of a mobile application. A mobile data unit (7) moves out of the area covered by the system and operator it has most recently used. The software (8) identifies the break in the mobile data service. This activates the algorithm for system and operator dependent roaming. A new mobile data session for continued IP communication (12) from to/the mobile data unit (7) is established.
The algorithm (10) starts by identifying available systems and operators. To choose between available systems/operators, the algorithm uses both the centrally (server) downloaded configuration parameters (11) and the local, empirical parameters from previous attempts (9). It chooses the system and operator that has the highest priority. The algorithm makes one or a number (configurable parameter) of attempts to establish a new data session with the selected system and operator. If a session cannot be established, the algorithm chooses the system and operator that has the next highest priority. This is repeated until a mobile data session is established. All failed and successful attempts to establish sessions are used to update the empirical information that is stored locally in the mobile data unit. This information is used in future attempts to establish mobile data sessions from the place in question.
FIG. 3 gives an overview of the entire schematic flow for an algorithm.
The algorithm for operator selection in mobile data service roaming has two parts:

- A configuration part that comprises a list of operators. This is downloaded to the mobile data unit from a server. The list has the following fields:
  - Operator code—e.g. the mobile network code (MNC) if communication is via GSM.
  - “Blocked flag”—a flag indicating whether use of an operator is permitted.
  - Weighting—a decimal value (integer) used by the self-learning algorithm to weight the priority for a certain operator. The mobile data unit uses this information to determine, in the self-learning part, whether or not an operator may be used. Where it is known in advance that certain operators in a country have better coverage or lower prices, the weighting is also used to direct the mobile data unit to advantageously use certain operators.
- A self-learning part that comprises a further list. This is created dynamically as, in the attempt to establish mobile data roaming, the mobile data unit fails or succeeds with each operator change. Each time the mobile data unit has to establish a mobile data session (i.e. at restarts or when the mobile data service is lost), a check is made (by asking the mobile data module) of the operators available in the current area. If they are not already there, the available operators are entered into the dynamic list. Before an operator is added to the dynamic list, the configuration list downloaded from the server is checked to see whether use of the operator is permitted. The weighting is also copied into the dynamic list. Next, the operator with the highest priority in the dynamic list is retrieved. The mobile data unit then attempts to establish a mobile data session with this selected operator. If it fails to connect to the operator or to set up a session, the operator's priority is adjusted downwards by altering the weighting. In this way, the dynamic list's prioritisation has a self-learning function (inasmuch as the value that indicates priority contains an empirical measure of how well an operator functions in a certain country). The dynamic list thus has the following fields:
  - Operator code
  - “Blocked flag”
  - Weighting
  - Priority

One function that is of great importance for mobile applications is the possibility of limiting the current drawn by the mobile data unit when it is using a battery as its sole power source. This is based on two (configurable) levels being downloaded from a server. These set:

- The voltage level to start the mobile data unit when it has gone into a power management mode.
- The voltage level to go into a power management mode.

Where the function is activated in the configuration downloaded from the server, the mobile data unit continuously monitors the voltage level of the source from which it takes its power. When the voltage feed falls below the level set in the configuration downloaded from the server, the mobile data unit signals the server that it is going into a power management mode. All the mobile data unit's unnecessary power-consuming functions (e.g. main processor, mobile module, other interfaces, etc.) are shut down and only a minimum number of components are allowed to be energised. These are the components necessary for monitoring voltage levels and alarm inputs. They also handle restarting of all the mobile data unit's essential functions
When the mobile data unit is in a power management mode, it is only allowed to “restart” if:

- The voltage level exceeds the configured (i.e. previously downloaded from a server) “restart” level.
- Any of the mobile data unit's active alarm inputs has an active alarm.
- A preset timer function (60 seconds up to 1 year) activates a temporary “restart”.

If an alarm “restarts” the mobile data unit, the alarm is sent to a server. Once it has been acknowledged, the terminal returns to a power management mode. If a timer function “restarts” the mobile data unit, the mobile data unit signals its position (or, if there is no positioning, simply its existence) and then returns to a power management mode. The timer interval to be used can be downloaded from a server (it should be possible to set this from 60 seconds to 365 days).
Another function that is of great importance for mobile applications is the possibility of sending an alarm that also contains position information. It should be possible for alarms to be activated by various types of “alarm indicators”, e.g.: door sensors in trucks/trailers; wireless personal-safety alarm buttons; hardwired alarm buttons; level sensors; etc. This would require the mobile data unit to have support for an array of alarm inputs and for managing the activation and resetting of these. The mobile data unit should also offer the function of sending (via the mobile data channel) these alarms with position indication (from a GPS receiver built into the mobile unit) and handling the acknowledgement message from the receiving unit (server).
For the receiving side to be able to ensure that the mobile unit is active and has not been subjected to any form of sabotage or operational interference, the mobile data unit should also continuously send, at predetermined intervals, a connection monitoring message (containing position indication). If these messages were not sent, the receiving unit (server) could trigger a connection alarm that gave the last known position and the associated time. Where the mobile data unit has these two. functions, it can be used for a whole range of mobile security applications.
These two functions (alarm inputs and connection monitoring messages) could be configured from the receiving unit (server) and updated via the mobile data unit's data channel.
FIG. 4 shows how the mobile data unit (16) could be installed in a trailer application. Communication and GPS aerials (14) are sited on the trailer unit's roof. Sensors (15) that register door opening send door position related signals to the data unit (16). Along with the mobile data unit (16), a GPS receiver, other electronics and a power unit (17) are built into an equipment box (18).
FIG. 5 shows how the mobile data unit (19) could be electrically connected to a battery monitor (20) and battery (21).
The concrete application detailed in this document centres on the need for reliable communication between a vehicle and its proprietors, said communication not being affected by today's shortcomings in service offerings.
The application is in no way restricted to this physical application. The latter is used solely as an example of the practical use of the invention. The application can be used on land, at sea and in the air—wherever the same phenomenon arises on passage between areas covered by different operators.

Claims

1. Mobile unit/apparatus that is equipped with mobile telephone parts used for sending/receiving and mobile telephone parts that have unique storage units such as SIM cards, the unit/apparatus having software and storage surfaces for data, the whole being characterised by algorithms controlling searches for system types, data formats, operators and selected prioritisation parameters, the searches being between and in different geographical networks.

2. Unit/apparatus as per patent claim 1 characterised by logical algorithms and empirical data from previous searches being used to select and test the way forward to establishing communication that is optimised for the purpose in question.

3. Unit/apparatus as per patent claim 1 characterised by the data relating to network/operator being automatically updated and by the unit/apparatus being self-learning and registering new data that controls the algorithms for the selection of operator(s) in accordance with preset/learned prioritisations.

4. Unit/apparatus as per patent claim 1 characterised by its enabling the customer-side optimisation of various services and factors (e.g. speech, data communication, geographical coverage, etc.) that differ between operators.

5. Unit/apparatus as per patent claim 1 characterised by its having configurable functions that can be downloaded from a server and which, for example, set: the voltage level to “restart” the unit/apparatus when it has gone into a power management mode; and, the voltage level at which the unit/apparatus goes into a power management mode.

6. Unit/apparatus as per patent claim 5 characterised by the data unit being able to start up in response to alarms and the suchlike. Alarms are sent to a server and when an acknowledgement has been received or, alternatively, positions have been notified, the unit/apparatus can return to a power management mode.

7. Unit/apparatus as per patent claim 5 characterised by the data unit, in a network, being able to monitor whatever parameters are considered to be of interest, irrespective of whether they relate to: the cargo in the cargo area (e.g. temperature and the suchlike); the vehicle's engine (e.g. fuel consumption); or, driver behaviour (e.g. total distance driven, speed, rests, etc.).