Technical Field The present invention relates to wake-up, or triggering, mechanisms for entities in a telecommunications network. In particular, although not exclusively, the invention relates to apparatus and methods for authenticating wake-up, or triggering, requests to devices without human operators. Background

Current cellular communication networks offer a high degree of security to users. Security ensures both authentication of users to the network and vice versa, and protection against eavesdropping. Security may also provide integrity protection allowing a recipient of data (possibly within the network) to confirm the integrity of sent data. This may involve a sender adding an integrity checksum to a message and which is computed using a secret key. The receiver, knowing the secret key, can verify the integrity checksum and thereby ensure that the message has indeed been sent by the trusted sender and has not been tampered with while in transit.

Such security mechanisms have been developed to work efficiently with conventional cellular network use cases. These tend to be concerned with users possessing mobile devices such as mobile telephones, smart phones, and other wireless enabled devices, and who make use of voice and data services. Such services involve the transfer of significant amounts of data to and from the user devices. Volumes of signalling traffic associated with these scenarios are not great when compared to the transferred data volumes. As such, the signalling overheads associated with security mechanism such as client and network authentication are relatively small. In the coming years it is expected that there will be a rapid growth in so-called machine-to-machine (M2M) applications, or Machine Type Communications (MTC), that use cellular network infrastructure. Such applications involve devices such as sensors and actuators communicating with other devices or network servers, often without direct human operation. An example application might involve domestic water meters configured to transmit water consumption readings periodically to a server owned by the utility company supplying water. M2M applications are expected to increase dramatically the number of wirelessly connected devices in use with cellular networks. Ericsson™ has predicted 50 billion such devices by the year 2020. In systems supporting M2M applications, a feature that is generally needed is a mechanism to trigger (or wake up) an entity (e.g. a device). Triggering typically means that a first entity in the network (e.g. an application server) wants to trigger a second entity (e.g. a second device), which is possibly in a sleep mode prior to the triggering) to perform some action which may include contacting the first entity (or another entity). This may be for example metering a temperature and reporting it to the first entity.

Figure 1 is a schematic illustration of an MTC UE (Machine Type Communications User Equipment) application 101 operating on a UE device 102 in a 3GPP network 103. A double dotted line 104 illustrates the boundaries of the 3GPP system. A Services Capability Server (SCS) 105 could be inside or outside the 3GPP system. Where a 3GPP system is used to support M2M applications, it is likely to be an Application Server (AS) 106, 107 or a generic SMS source (SM E) 108 that is used to trigger the device 102.6 M2M devices are frequently battery operated devices with limited power resources, and may not have access to power supplies to charge their batteries. Despite this they may be required to operate for very long times. This makes the M2M devices very sensitive to power consumption and vulnerable to unauthorized or fake trigger requests from the network, which could drain the battery.

One possible approach to mitigate the threat of fake trigger requests could be to use integrity protection of the trigger request between the trigger source (e.g. AS 106) and the device 102. This would be based on some keys shared between the device and the AS. While this kind of end-to-end integrity protection would help the device to distinguish real triggers from fake triggers, it would still be harmful to the device as it would have to use power to receive and verify the integrity of the trigger request. Therefore even fake trigger requests which are ultimately rejected would require action on the part of the device, leading to wasted power. Another possibility is that some node in the intermediate network between the device and the AS could determine if the AS 106 is authorized to send trigger requests to this device 102, and consequently discards fake trigger requests. 3GPP has taken this approach in 3GPP Release 11 and is investigating other mechanisms, like end-to-end integrity protection, in ongoing Release 12.

In a 3GPP system such as that shown in Figure 1 , trigger requests can be sent from an AS 106 via SCS 105 to a MTC-IWF (MTC Interworking function) 109 over a Tsp interface or from an SME 108 to a SMSC (Short Message Service Centre) 110 over a Tsms interface. In both of these cases, the authorization of the source of the trigger request is checked but in different ways.

In the case of a trigger request over Tsp the MTC-IWF 109 and SCS 105 are required to have credentials to mutually authenticate each other. After authentication the MTC- IWF 109 checks from a database (in HSS 11 1) if the SCS 105 is authorized to trigger this device 102. The trigger request is typically originated from the AS 106, but it has been left out of the 3GPP scope of how the SCS 105 will authorize the AS 106.

In the case of a trigger request over Tsms the SMSC 1 10 can only accept trigger requests from "trusted sources", i.e. "trusted" SMEs 108. This means that there is no authentication mechanism specified but the authorization decision is based on trust. In practice this limits the number of authorized senders of device triggers to known entities who have a relation with the operator anyway and are likely to be big players. One reason for relying on "trusted sources" is that Tsms is a legacy interface based on proprietary mechanisms, and it is considered desirable that this is kept intact. Another reason was that the "SME" 108 is a generic source of SMS and it would not be feasible to establish authentication credentials between the SMSC 1 10 and all possible SMEs.

The approaches taken by 3GPP highlight the more general fact that the number of sources allowed to issue trigger requests is currently very limited, whatever system or network is used. A common reason for this is that it is very difficult for the intermediate system providing the "trigger service" (like the 3GPP system in the example above) to verify authorization of an arbitrary trigger request source (e.g. ASs owned by individuals) in practice. This is because trustworthy authorization needs to be preceded by authentication, and even though the (owner of the) device could specify a list of authorized trigger request sources (like ASs) and give that list to the intermediate system, the intermediate system would need to share or exchange authentication credentials with all listed trigger request sources, which is likely not feasible in practice. Therefore, there is currently no way for an arbitrary trigger source to be authorized to send a trigger to a device.

Summary

It is an object of the present invention to address, or at least alleviate, the problems described above.

In accordance with one aspect of the present invention there is provided a system for authorising a trigger source to issue a trigger request to a device in a network, the device being associated with a trigger entity authoriser and configured to receive trigger messages only via a trigger server. The trigger entity authoriser is configured to send an initiation message to the trigger server via a secure connection, the initiation message including an indication of the identity of the trigger source and the identity of the device. The trigger entity authoriser and trigger server are configured to agree a ticket usable by the trigger server as a unique association of the trigger source and the device. The trigger entity authoriser is configured to send the ticket to the trigger source. The trigger source is configured to send a trigger request message to the trigger server, the trigger request message including the ticket and a request to trigger the device. The trigger server is configured to receive the ticket from the trigger source and authenticate the trigger source and, if the received ticket correctly associates the authenticated trigger source and the device, to send a trigger message (6) to the device.

The trigger server may be configured to generate the ticket in response to receipt of the initiation message, and send the ticket to the trigger entity authoriser.

The trigger entity authoriser may be configured to include in the initiation message an indication of a mechanism by which the trigger source should be authenticated by the trigger server. The trigger entity authoriser may be configured to send the indication of the mechanism to the trigger source with the ticket. The trigger server may be configured to authenticate the trigger source using the indicated mechanism.

The trigger entity authoriser may be configured to send an address of the trigger server to the trigger source with the ticket.

The trigger server may be configured to authenticate the trigger source using a delegated authenticator. The trigger entity authoriser and trigger server may be configured to agree credentials for the trigger source to enable the trigger server to authenticate the trigger source. The trigger entity authoriser may be configured to send the credentials to the trigger source over a secure connection. The trigger source may be configured to authenticate with the credentials to the trigger server when sending a trigger request. Alternatively, the credentials may also be sent together with the trigger request.

The trigger entity authoriser may be a module configured to run at the device. The device may be an M2M device. The trigger source may be an application server.

In accordance with another aspect of the present invention there is provided a trigger entity authoriser for authorising a trigger source to issue a trigger request to a device in a network. The trigger entity authoriser comprises a processor and a memory. The memory contains instructions executable by said processor to cause the processor to: send an initiation message to a trigger server via a secure connection, the initiation message including an indication of the identity of the trigger source and the identity of the device; send to or receive from the trigger server a ticket associating the trigger source and the device; and send the ticket to the trigger source.

In accordance with another aspect of the present invention there is provided a trigger entity authoriser for authorising a trigger source to issue a trigger request to a device in a network. The trigger entity authoriser comprises a message initiator for sending an initiation message to a trigger server via a secure connection, the initiation message including an indication of the identity of the trigger source and the identity of the device. The trigger entity authoriser further comprises a ticket negotiator for sending to or receiving from the trigger server a ticket associating the trigger source and the device, and a ticket sender for sending the ticket to the trigger source. The message initiator may be configured to include in the initiation message an indication of a mechanism by which the trigger source should be authenticated by the trigger server, and the ticket sender may be configured to send the indication of the mechanism to the trigger source. The ticket sender may be configured to send an address of the trigger server to the trigger source.

The ticket negotiator may be configured to send to or receive from the trigger server credentials for the trigger source to enable the trigger server to authenticate the trigger source, and to send the credentials to the trigger source over a secure connection.

In one embodiment the trigger entity authoriser may be provided in an M2M device.

In accordance with another aspect of the present invention there is provided a trigger source for issuing a trigger request to a device in a network. The trigger source comprises a processor and a memory. The memory contains instructions executable by said processor to cause the processor to: receive a ticket from a trigger entity authoriser, the ticket usable by a trigger server as a unique association of the trigger source and the device; send a trigger request to the trigger server accompanied by the ticket; and authenticate the trigger source to the trigger server.

In accordance with another aspect of the present invention there is provided a trigger source for issuing a trigger request to a device in a network. The trigger source comprises a ticket receiver for receiving a ticket from a trigger entity authoriser, the ticket usable by a trigger server as a unique association of the trigger source and the device. The trigger source further comprises a trigger request sender for sending a trigger request to the trigger server accompanied by the ticket, and an authenticator for authenticating the trigger source to the trigger server. The ticket receiver may be configured to receive from the trigger entity authoriser an indication of an authentication mechanism, and the authenticator may be configured to authenticate the trigger source to the trigger server using the indicated authentication mechanism. The authentication mechanism may include the use of a delegated external authenticator in combination with the authenticator of the trigger source.

The ticket receiver may be configured to receive from the trigger entity authoriser credentials for authenticating the trigger source to the trigger server and to use the credentials in the authentication.

In accordance with another aspect of the present invention there is provided a trigger server for sending a trigger message to a device in a network. The trigger server comprises a processor and a memory. The memory contains instructions executable by said processor to cause the processor to: receive an initiation message from a trigger entity authoriser via a secure connection, the initiation message including an indication of the identity of the device and the identity of a trigger source to be authorised to issue a trigger request to the device; agree with the trigger entity authoriser a ticket usable by the trigger server as a unique association of the trigger source and the device, and store the ticket; receive a trigger request message from the trigger source, the trigger request message including a request to trigger the device and the ticket; and authenticate the trigger source and, if the received ticket correctly associates the authenticated trigger source and the device, send a trigger message to the device. In accordance with another aspect of the present invention there is provided a trigger server for sending a trigger message to a device in a network. The trigger server comprises an initiation message receiver for receiving an initiation message from a trigger entity authoriser via a secure connection, the initiation message including an indication of the identity of the device and the identity of a trigger source to be authorised to issue a trigger request to the device. The trigger server further comprises a ticket negotiator for agreeing with the trigger entity authoriser a ticket usable by the trigger server as a unique association of the trigger source and the device, and a trigger request receiver for receiving a trigger request message from the trigger source, the trigger request message including a request to trigger the device and the ticket. The trigger server further comprises an authenticator for authenticating the trigger source and a trigger sender for sending a trigger message to the device if the received ticket correctly associates the authenticated trigger source and the device.

The ticket negotiator may be configured to generate the ticket in response to receipt of the initiation message, and send the ticket to the trigger entity authoriser.

The initiation message receiver may be configured to receive an indication of a mechanism for authenticating the trigger source, and to authenticate the trigger source using the indicated mechanism.

In accordance with another aspect of the present invention there is provided a method of operating a trigger entity authoriser to authorise a trigger source to issue a trigger request to a device in a network. The method comprises sending an initiation message to a trigger server via a secure connection, the initiation message including an indication of the identity of the trigger source and the identity of the device. The method further comprises sending to or receiving from the trigger server a ticket associating the trigger source and the device, and sending the ticket to the trigger source. An indication of a mechanism by which the trigger source should be authenticated by the trigger server may be included in the initiation message and sent to the trigger source with the ticket.

Credentials for the trigger source may be sent to or received from the trigger server to enable the trigger server to authenticate the trigger source, and sent to the trigger source over a secure connection.

In accordance with another aspect of the present invention there is provided a method of operating a trigger source to issue a trigger request to a device in a network. The method comprises receiving a ticket from a trigger entity authoriser, the ticket usable by a trigger server as a unique association of the trigger source and the device. The method further comprises sending the trigger request to the trigger server accompanied by the ticket, and authenticating the trigger source to the trigger server. The method may further comprise receiving from the trigger entity authoriser an indication of an authentication mechanism, and authenticating the trigger source to the trigger server using the indicated authentication mechanism. Credentials for authenticating the trigger source to the trigger server may be received from the trigger entity authoriser and used in the authentication.

In accordance with another aspect of the present invention there is provided a method of operating a trigger server to send a trigger message to a device in a network. The method comprises receiving an initiation message from a trigger entity authoriser via a secure connection, the initiation message including an indication of the identity of the device and the identity of a trigger source to be authorised to issue a trigger request to the device. The method further comprises agreeing with the trigger entity authoriser a ticket usable by the trigger server as a unique association of the trigger source and the device, storing the ticket, and receiving a trigger request message from the trigger source, the trigger request message including a request to trigger the device and the ticket. The method further comprises authenticating the trigger source and, if the received ticket correctly associates the authenticated trigger source and the device, sending a trigger message to the device.

The ticket may be generated in response to receipt of the initiation message, and sent to the trigger entity authoriser.

An indication of a mechanism for authenticating the trigger source may be received in the initiation message, and the trigger source may be authenticated using the indicated mechanism.

The invention also provides a computer program, comprising computer readable code which, when operated by a trigger entity authoriser, trigger source or trigger server, causes the respective trigger entity authoriser, trigger source or trigger server to operate as a trigger entity authoriser, trigger source or trigger server as described above. The invention further provides a computer program, comprising computer readable code which, when operated by a device, causes the device to operate any of the methods described above. The invention also provides a memory, optionally arranged in the form of a computer program product, comprising a computer program and a computer readable means on which the computer program is stored.

Brief Description of the Drawings

Some preferred embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of elements of an exemplary 3GPP network containing an MTC UE;

Figure 2 is a schematic diagram including elements of a network;

Figures 3A and 3B are schematic diagrams of implementations of a trigger entity authoriser;

Figures 4A and 4B are schematic diagrams of implementations of a trigger source; Figures 5A and 5B are schematic diagrams of implementations of a trigger server; and

Figure 6 is a set of flowcharts illustrating the steps carried out by the trigger entity authoriser, trigger source and trigger server in authenticating the trigger source and issuing trigger instructions to a device. Detailed Description

Figure 2 is a schematic diagram of elements of a network 200 including a device 201 which may be an M2M device (e.g. a MTC UE similar to that shown in Figure 1 , or other M2M capable device) which is designed to be triggered or woken up in response to a trigger request from a trigger source 202, which could for example be an Application Server or SME but is not limited to such entities. It could be another UE.

The network includes a trigger server 203, and the device 201 is configured to be woken up only when it receives a trigger message from the trigger server 203. If the network is a 3GPP network the trigger server could be a MTC-IWF, similar to that shown in Figure 1. A trigger entity authoriser 204 also has access to the network. It is assumed that the trigger entity authoriser 204 can communicate securely with the trigger server 203, for example using 3GPP security mechanisms. The trigger entity authoriser 203 may be operated, for example, by, or on behalf of, the owner of the M2M device 201.

If the trigger entity authoriser 204 wishes to authorise the trigger source 202 to trigger or wake up the device 201 , then the following procedure may be carried out:

1. The trigger entity authoriser 204 sends an initiation (ticket request) message to the trigger server 203. The initiation message includes an indication of the device 201 , together with the identity of the trigger source 202 which is to be authorised to trigger the device 201 , and optionally a mechanism by which the trigger source 202 should be authenticated by the trigger server 203. The indicated mechanism could, for example, be a public key certificate or a Single Sign-On identity, like OpenID identity. The trigger entity authoriser 204 and the trigger server 203 may alternatively negotiate an authentication mechanism which they both support, e.g. the trigger entity authoriser 204 may send both a public key certificate and a Single Sign-On identity to the trigger server 203. The trigger server 203 may then choose the one of the public key certificate and a Single Sign-On identity it supports, or just choose one of these if it supports both. The ticket request message may also have other information related to the triggering, such as e.g. information indicative of how often, and/or in what time period, the trigger source 202 is allowed to trigger the device 201.

2. The trigger server 203 stores the information received, and allocates a ticket for the device. The ticket may be a random number. The trigger server 203 sends the ticket to the trigger entity authoriser 204. The address of the trigger server 202 may also need to be sent to the trigger entity authoriser 204 so that the trigger source 202 knows who to contact in step 4 below. It will be appreciated that it would also be possible for the trigger entity authoriser 204 to allocate the random number to the ticket and send it to the trigger server in the initiation message in step 1 above, in which case the response need only confirm receipt of the initiation message and ticket. What is important is that the ticket is bound to the trigger source - device pair.

3. The trigger entity authoriser 204 sends the ticket and the address of the trigger server to the trigger source 202. The ticket may be integrity protected to protect the contents from tampering, but in one embodiment it does not need to be encrypted when sent since it can only be used by the specific authorized trigger source 202 associated with the Ticket.

4. When the trigger source 202 needs to trigger the device 201 , it sends a trigger request to the trigger server 203. The ticket is included in the trigger request or sent following authentication.

5. The trigger server 203 authenticates the trigger source 202 to confirm its identity, optionally using the method indicated in the original ticket request. This may be done by an authentication functionality in the network such as a PKI or SSO system. The ticket enables the trigger server 203 to associate the trigger request to the correct trigger source - device pair. The trigger server 203 is authorised to act on the trigger request only if the authenticated trigger source 202 is correctly associated with the ticket.

For example, in one embodiment the trigger source 202 may send a trigger request message signed with the private key corresponding to a public key sent by the trigger entity authoriser 204 to the trigger server 203 in step 1. The trigger server may need to fetch an appropriate certificate from a PKI system 205 to verify the signature.

In an alternative embodiment, the trigger source 202 may send a trigger request message with an OpenID identity, in which case the trigger server 203 authenticates the trigger source with an associated OpenID provider.

It will be noted that the trigger source 202 and trigger server 203 do not need to share credentials or even have prior knowledge of each other for authentication, but can rely on a delegated external authenticator 205 such as PKI or SSO. 6. If authentication and authorization of the trigger request from the trigger source is successful, the trigger server sends a trigger message to the device 201. As a result, the device can be triggered only by an authorized trigger source. It will be appreciated that the trigger message may be a forwarded version of the trigger request (with authentication information to identify the trigger server) or may be an entirely separate message.

The trigger entity authoriser may be operated by, or on behalf of, the owner of the device, and may communicate with the trigger server, for example, via a secure web portal. It may also be the case that the trigger entity authoriser is contiguous with the device 201 itself. Thus it may be the case that the device 201 is programmed by a user to receive triggers from the trigger source 202. If this is the case (and assuming the device has a secure connection to the trigger server 203), steps 1 and 2 may take place between the device 201 and trigger server 203, so that the device 201 makes the initial ticket request from the trigger server and the trigger server 203 returns the ticket to the device (or the device generates a ticket itself and sends it to the trigger server). The device 201 can then send the ticket to the trigger source 202 to enable it to authenticate itself to the trigger server. This could be done, for example, when the device 201 has as connection to the trigger source 203 as a part of normal application communication. In this scenario, once the ticket has been sent to the trigger source 202 the device can go to sleep.

Using the process described above it will be noted that there is no requirement for the trigger entity authoriser 204 to have a secure connection to the trigger source 202. However, if such a secure connection does exist then in step 1 the trigger entity authoriser 204 may send to the trigger server 203 credentials with which the identity of the trigger source 202 can be authenticated. Such credentials could include a shared key or password. Alternatively the trigger server 203 could generate these credentials and send them to the trigger entity authoriser 204.

Then in step 3 these credentials can be sent from the trigger entity authoriser 204 to the trigger source 202. This message should be encrypted to prevent eavesdropping.

In steps 4 and 5, the credentials as well as the ticket are sent from the trigger source 202 to the trigger server 203. The ticket enables the trigger server 203 to associate the trigger request to the correct trigger source - device pair and the credentials enable the authentication of the trigger source 202, optionally in conjunction with the mechanism specified in step 1 as before. For example, the trigger source 202 could set up a TLS connection to the Trigger Server and use the credential as a password for HTTP digest within the TLS connection.

Figure 3A is a schematic diagram illustrating some of the structure of one implementation of the trigger entity authoriser 204. The trigger entity authoriser 204 includes a processor 301 a, memory 302a and communications unit 303a for communicating with other entities in the network. As previously discussed, the trigger entity authoriser may be independent of the device itself, or may be implemented in the device. The memory 302a includes instructions executable by the processor 301a to operate the communications unit 303a, and further includes an initiation module 304a having instructions causing the processor to send an initiation message (using the communications unit) towards the trigger server 203. The initiation message includes an indication of the identity of the trigger source 202 and the identity of the device 201. The memory also includes a ticket negotiation module 305a configured either to send a ticket associating the trigger source and the device to the trigger server 203, or to receive such a ticket from the trigger server. The memory also includes a ticket sending module 306a configured to send the ticket to the trigger source 202.

Figure 3B is a schematic diagram illustrating an alternative implementation of the trigger entity authoriser 204 having a message initiator 304b for sending an initiation message towards the trigger server 203, a ticket negotiator 305b for sending a ticket to the trigger server or receiving such a ticket from the trigger server, and a ticket sender 306b for sending the ticket to the trigger source 202. In one embodiment this may be part of a memory, such that the message initiator, ticket negotiator and ticket sender are interacting units provided as software in the memory. In another embodiment it could illustrate part of a processor, the interacting units provided as hardware in the form of suitable circuitry. It will be appreciated that a combination of these two embodiments is also possible. In general it will be appreciated that the trigger entity authoriser may include hardware implementation such as e.g. one or more ASICs, software implementation, or a combination thereof. Figure 4A is a schematic diagram illustrating some of the structure of one implementation of the trigger source 202. The trigger source 202 includes a processor 401a, memory 402a and communications unit 403a for communicating with other entities in the network. The memory 402a includes instructions executable by the processor 401a to operate the communications unit 403a, and further includes a ticket receipt module 404a having instructions causing the processor to receive (via the communications module) a ticket from the trigger entity authoriser 204. The memory also includes a trigger request module 405a configured to send a trigger request to the trigger server accompanied by the ticket, and an authentication module 406a configured to authenticate the trigger source 202 to the trigger server 203.

Figure 4B is a schematic diagram illustrating an alternative implementation of the trigger source 202 having a ticket receiver 404b for receiving the ticket from the trigger entity authoriser 204, a trigger request sender 405b for sending a trigger request to the trigger server 203 accompanied by the ticket, and an authenticator 406b for authenticating the trigger source to the trigger server. In one embodiment this may be part of a memory, such that the ticket receiver, ticket request sender and authenticator are interacting units provided as software in the memory. In another embodiment it could illustrate part of a processor, the interacting units provided as hardware in the form of suitable circuitry. It will be appreciated that a combination of these two embodiments is also possible. In general it will be appreciated that the trigger source may include hardware implementation such as e.g. one or more ASICs, software implementation, or a combination thereof.

Figure 5A is a schematic diagram illustrating some of the structure of one implementation of the trigger server 203. The trigger server 203 includes a processor 501 a, memory 502a and communications unit 503a for communicating with other entities in the network. The memory 502a includes instructions executable by the processor 501a to operate the communications unit 503a, and further includes an initiation message receipt module 504a having instructions causing the processor to receive an initiation message from the trigger entity authoriser 204. The memory also includes a ticket negotiation module 505a configured either to receive a ticket from the trigger entity authoriser or to generate and send the ticket to the trigger entity authoriser. The ticket associates the identity of the device 201 with that of the trigger source 202.

The memory also includes a trigger request receipt module 506a having instructions causing the processor to receive a trigger request from the trigger source 202. An authentication module 507a is configured to authenticate the trigger source and confirm that the identity of the trigger source matches that associated with the ticket. A trigger sending module 508a is configured to cause the processor to send a trigger message to the device 201 if the authentication is successful.

Figure 5B is a schematic diagram illustrating an alternative implementation of the trigger server 203 having an initiation request receiver 504b, ticket negotiator 505b, trigger request receiver 506b, authenticator 507b and trigger sender 508b. The initiation request receiver 504b receives the initiation message from the trigger entity authoriser 204. The ticket negotiator 505b either receives a ticket from the trigger entity authoriser or generates and sends the ticket to the trigger entity authoriser. The trigger request receiver 506b causes the processor to receive a trigger request from the trigger source 202. The authenticator 507b authenticates the trigger source and confirms that the identity of the trigger source matches that associated with the ticket. The trigger sending module 508b causes the processor to send a trigger message to the device 201 if the authentication is successful. In one embodiment this implementation may be part of a memory, such that the initiation request receiver, ticket negotiator, trigger request receiver, authenticator and trigger sender are interacting units provided as software in the memory. In another embodiment it could illustrate part of a processor, the interacting units provided as hardware in the form of suitable circuitry. It will be appreciated that a combination of these two embodiments is also possible. In general it will be appreciated that the trigger server may include hardware implementation such as e.g. one or more ASICs, software implementation, or a combination thereof.

Figure 6 includes three flowcharts illustrating the steps which may be carried out by the trigger entity authoriser 204, trigger server 203 and trigger source 202 in order to authorise the trigger source 202 to send a trigger message to the device 201. The trigger entity authoriser 204 sends an initiation message 701 to the trigger server 203. The trigger server 203 receives the initiation message 702, generates a ticket, and sends it 703, 704 to the trigger entity authoriser 204. Alternatively, the ticket may be generated by the trigger entity authoriser and sent to the trigger server, either as part of the initiation message or subsequently. The trigger entity authoriser 204 sends the ticket 705 to the trigger source 202, together with the address of the trigger server (and optionally an indication of a desired authentication mechanism). The trigger source 202 receives and stores the ticket 706 for future use. When it is required that the device should be triggered, the trigger source 202 sends a trigger request 707, including the ticket, to the trigger server 203. When the trigger server 203 receives the trigger request 708 it authenticates 709, 710 the identity of the trigger source 202, and confirms that the identity of the trigger source, and the identity of the device for which the trigger is requested, match the trigger source and device associated with the ticket 711. If the authentication is successful and the ticket matches, the trigger server 203 sends a trigger message 712 to the device 201. If the authentication is not successful or the ticket does not match, the process stops 713 without a trigger message being sent to the device. It will be appreciated that the approach described above allows a device to dynamically and securely authorize arbitrary trigger sources such as application servers or even other devices to send a trigger. The trigger server and trigger source do not need to share credentials or even be aware of each other before the trigger request arrives at the trigger server. This significantly increases the possibilities available for choosing trigger sources which can trigger M2M devices. This, in turn, enables easier introduction of M2M services.