WO2014125036A1

WO2014125036A1 - Method and system for supporting communication with a group of devices via a mobile network

Info

Publication number: WO2014125036A1
Application number: PCT/EP2014/052841
Authority: WO
Inventors: Andreas Kunz; JaeSeung SONG
Original assignee: Nec Europe Ltd.
Priority date: 2013-02-13
Filing date: 2014-02-13
Publication date: 2014-08-21

Abstract

A method for supporting communication with a group of devices via a mobile network (1) is characterized in that an entity outside said mobile network (1) dynamically generates a group of member devices (2) by selecting, from the devices associated with said mobile network (1), said member devices (2) according to configurable grouping criteria on the basis of capabilities and/or service features supported by the devices, wherein said entity assigns said group of member devices (2) an external group identifier, creates a binding of the external identifiers of the member devices (2) and said external group identifier, and provides the binding information back to said mobile network (1).

Description

METHOD AND SYSTEM FOR SUPPORTING COMMUNICATION WITH A GROUP OF DEVICES VIA A MOBILE NETWORK

The present invention relates to a method and a systenn for supporting communication with a group of devices via a mobile network.

In today's communication scenarios, there are various situations or applications in which one and the same message has to be delivered to a number of devices. Depending on the specific application, the group of recipients may include hundreds or even thousands of devices. In particular, although not limited to, such scenarios occur in the field of MTC (Machine Type Communication) applications. For instance, to name just one particular application, one can think of energy suppliers who want to trigger the electricity meters of their customers to transmit a particular parameter, e.g. the current energy value of the meters.

Currently there is no solution to address a dedicated group of MTC devices without severe changes to the current network architecture described in 3GPP TS 23.682 "Architecture enhancements to facilitate communications with packet data networks and applications". Current solutions only describe the delivery of group messages via cell broadcast or multicast. Even worse, current 3GPP networks do not cooperate with external entities, such as application servers (AS) located outside of the 3GPP network. 3GPP only supports a static grouping of devices typically based on their location or subscription. However, in certain situations application service providers may need more flexibility when installing or removing devices that could be grouped based on features and/or capabilities the devices support.

In view of the above it is an objective of the present invention to improve and further develop a method and a system for supporting communication with a group of devices via a mobile network in such a way that a higher degree of flexibility regarding the composition of the recipients of the message is achieved.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method is characterized in that an entity outside said mobile network dynamically generates a group of member devices by selecting, from the devices associated with said mobile network, said member devices according to configurable grouping criteria on the basis of capabilities and/or service features supported by the devices, wherein said entity assigns said group of member devices an external group identifier, creates a binding of the external identifiers of the member devices and said external group identifier, and provides the binding information back to said mobile network. Furthermore, the above mentioned objective is accomplished by a system comprising the features of claim 17. According to this claim such a system is characterized in that it comprises an entity outside said mobile network that is configured to dynamically generate a group of member devices by selecting, from the devices associated with said mobile network, said member devices according to configurable grouping criteria on the basis of capabilities and/or service features supported by the devices, to assign said group of devices an external group identifier, to create a binding of the external identifiers of the member devices of said group of devices and said external group identifier, and to provide the binding information back to said mobile network.

According to the present invention it has been recognized that a higher degree of flexibility regarding the composition of the recipients of the message can be achieved by introducing a dynamic grouping of devices based on the device capabilities and/or service features the devices support. According to the invention the automatic grouping is outsourced to an entity outside the mobile network, i.e. outside the 3GPP domain, e.g. to an MTC application server, which provides the binding information back to the mobile network in order to update the mobile network's terminal group table. According to a preferred embodiment the member devices of the group of devices may be MTC devices, since the present invention can be most suitably applied in MTC type communication scenarios. In such applications, the grouping may be performed by an MTC or M2M (Machine-to-Machine) application server. According to a further preferred embodiment the characteristics used as grouping criteria may be related to the device's location, capabilities, sensor type, service type, or the like. For instance, with respect to the capabilities supported by the devices grouping may be performed on the basis of specific equipment, e.g. whether the device is equipped with a camera, a screen, and/or a sensor. Other capability related grouping criteria may be based on whether the devices have mobility support and/or power saving or not, or on the basis of the access technologies the devices support. In case of sensor equipment third grouping criteria may distinguish between sensors for measuring temperature, humidity, gas, electricity, water, etc. With respect to service type related grouping criteria support of different services like e.g. fleet management, smart meter, etc. may be considered.

Advantageously, the entity outside the mobile network may send a trigger message to the devices associated with the mobile network that instructs the devices to provide information on their supported capabilities and/or service features. Alternatively, the entity outside the mobile network may send a resource discovery message to the devices associated with the mobile network that instructs the devices to report back only in case they support certain capabilities and/or service features. For instance, an energy supplier may be interested in generating a group of member devices that includes only those devices that are equipped with, e.g., a gas sensor.

In order to properly indicate the capabilities and/or service features the entity outside the mobile network, for instance an MTC application server, is interested in, these capabilities and/or service features may be specified in the payload of the resource discovery message by means of respective search strings. In particular, this procedure may be executed in accordance with the resource discovery mechanism as described in ETSI TS 102 690 V2.0.13 (2013-05): "Machine-to- Machine communications (M2M); Functional architecture". Specifically, in this document the querying of devices together with various discovery and filter criteria is described in sub-section 9.2, the disclosure of which is incorporated herein by way of reference. According to preferred embodiment it may be provided that a dedicated node within the mobile network configured to assign, based on the binding information, a mobile network internal, routable identifier - internal group identifier - to the external group identifier, and to create a mapping between the internal group identifier and the mobile network internal identifiers of the member devices of the group of devices. Preferably, it may be an MTC-IWF (MTC Interworking Function) within in the mobile core network that implements the functionality of the dedicated node. Alternatively, the dedicated node may be a serving node in the mobile core network the member devices of the group of devices are associated with. For instance, in case of 3GPP networks, the serving node may be an MME (Mobility Management Entity), an MSC (Mobile-services Switching Centre), a BM-SC (Broadcast Multicast - Service Centre, as specified in 3GPP TS 23.246), CBC (Cell Broadcast Centre, as specified in 3GPP TS 23.041 ) or an SGSN (Serving GPRS Support Node). In case of SMS related application scenarios, the dedicated node may be an SMS-SC (Short Message Service - Service Centre). As will be easily appreciated by those skilled in the art, the above list is not conclusive, and in mobile networks other than 3GPP networks different nodes may be configured to function as dedicated node that is in charge of the mapping between the external and the internal group identifier and the binding between the latter and the internal identifiers of the member devices. In an alternative embodiment, in which the MTC-IWF is the dedicated node, the MTC-IWF may provide the binding information of the internal group identifier and the internal identifiers of the member devices of the group to any of the above listed nodes within the mobile core network.

With respect to an efficient creation of the group identifier used for addressing the group of devices, it may be provided that the group identifier is created as a group MSISDN (Mobile Station Integrated Services Digital Network Number) or a group IMSI (International Mobile Subscriber Identity). For instance, a group MSISDN or a group IMSI could be easily derived from the MSISDNs or IMSIs of the member devices of the respective group, e.g. according to a predefined algorithm. Alternatively, the group identifier may be created as a group URI or as a group E.164 number (as specified by ITU-T). Generally, in this context it is important to note that the above group identifier is an "internal" group identifier, which is routable within the mobile network. This "internal" group identifier has to be distinguished from the "external" group identifier, which the entity outside the mobile network, e.g. an MTC application server of an energy supplier, may use to identify the addressed devices. As will be easily appreciated by those skilled in the art, there are various possibilities how to translate such external identifier into an internal, routable identifier for the mobile network.

According to a preferred embodiment the entity outside the mobile network may provide the binding information back to the mobile network whenever a member device joins or leaves said group of devices. Alternatively, the binding information may be provided back to the mobile network in an aggregated message.

In a specific embodiment it may be provided that the entity outside the mobile network employs the external group identifier for sending a trigger message for the member devices of the group of devices to perform a specific action. For instance, an MTC application server of an energy provider may generate a message that triggers the electric meters of the energy provider's customers to transmit their current meter readings. In a specific embodiment it may be provided that the dedicated node within the mobile network transmits the trigger message to the member devices of the group of devices by means of individual transmissions. Individual transmissions come along with the advantage that it is possible to reach also member devices of the same group of devices that are served by the same serving node as dedicated node, even though they do not belong to the same geographical area, e.g. cell. This is advantageous compared to solutions that rely on cell broadcast or multicasts services for the delivery of trigger messages. In addition, sending the trigger message via individual transmissions to the member devices of a group of devices enables the dedicated node that keeps state of the trigger message delivery to resend the trigger message only to those member devices of the group of devices that have not received the trigger message correctly in the first try. In particular scenarios it may happen that the member devices of a group of devices are attached to different serving nodes. In such cases, it may be provided that the trigger message is forwarded to all involved serving nodes.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to patent claims 1 and 17 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawing

Fig. 1 is a schematic view illustrating an application scenario in a 3GPP architecture for machine type communication in accordance with an embodiment of the invention, and

Fig. 2 is a flow diagram illustrating a triggering call flow and grouping based on supported features/capabilities in accordance with an embodiment of the invention.

Fig. 1 schematically illustrates a mobile network 1 according to the 3GPP architecture for the support of machine type communication (MTC) from 3GPP TS 23.682 "Architecture enhancements to facilitate communications with packet data networks and applications". Currently the architecture according to this standard supports three different ways, how an MTC device 2 can be triggered by way of a trigger message to perform a specific action. The trigger message payload itself is transparent to the 3GPP system.

The MTC application server (AS) 3 sends a trigger either directly or indirectly or in a hybrid mode that combines elements of the direct and of the indirect approach. In the direct mode, the MTC application server 3 is aware of the IP address of the MTC device 2 and can send a trigger message via the user plane connection, i.e. via the Gi/SGi reference point.

In the indirect model, the MTC application server 3 sends the trigger message via a Service Capability Server (SCS) 4, which belongs either to the mobile network 1 or the MTC service provider that hosts the MTC application server 3. The SCS 4 then provides the trigger message to the MTC interworking function (IWF) 5, which can translate the external identity of the MTC device 2 into an internal, routable identity for the mobile network 1 and which decides whether the trigger is sent via the T4 or the T5 interface to the MTC device 2.

According to the above mechanism, for example, if a service provider company deploys gas meters and other smart meters within different cities and it groups them together per type of smart meter, then this has to be configured manually and separately within the 3GPP network 1 and within the external application server 3. The binding of the external identifier to the external group identifier has to be configured in the application server 3 each time a device joins a group or gets removed (The term "external", which is employed in contrast to the term "internal", refers to the outside of the mobile network 1 ; this notation will be maintained throughout the following description). In addition, this has to be configured within the 3GPP network 1 too, but in a different way. The 3GPP network 1 needs to know that the external group identifier now also accommodates another device and needs to bind the 3GPP internal identifier such as IMSI of the device with the external group identifier. Else the newly joined device would never be triggered in case the 3GPP network 1 receives a group trigger with the external group identifier.

In connection with the flow diagram of Fig. 2, which builds upon the architecture shown in Fig. 1 and in which same reference numerals denote same components as in Figs. 1 , an embodiment of the present invention is described hereinafter that introduces a dynamic grouping of devices based on their device capability and service features. The automatic grouping is outsourced to the external node, i.e. the MTC application server 3, which provides the binding information back to the 3GPP network in order to update the 3GPP internal group table. It is noted that while the embodiment of Fig. 2 relates to MTC type communication, the method according to the present invention can likewise be applied to "normal" UEs that are not specialized for MTC service. The embodiment illustrated in Fig. 2 makes use of a way of querying device capabilities and features from machine to machine (M2M) devices, as described in ETSI TS 102 690 V2.0.13 (2013-05): "Machine-to-Machine communications (M2M); Functional architecture" (for reference, see in particular subsection 9.2). It is not possible at the moment to utilize the grouping advantage for devices with the same feature or service application, e.g. in case a M2M application wants to read out all gas smart meter devices it could send a group trigger to those devices instead of querying all devices individually. In addition, continuous group operations, such as exchanging information for a certain period, are not supported. These continuous group operations can reduce network signaling loads and provide optimized network management.

The ETSI M2M architecture provides a way to discover a specific resource or a list of resources sharing the same features, such as finding devices at the same location. When a resource needs to be found using the specified filter criteria, one or more than one search string can be associated to a resource, enabling a matching criteria method for retrieving resources having common search string tokens.

Referring now to Fig. 2 in detail, this figure illustrates an embodiment of mapping the ETSI M2M resource discovery mechanism to a 3GPP model, including the following steps:

In step 1.), the MTC (or M2M) application server 3 outside the 3GPP network 1 sends a trigger message to the MTC device (UE) 2 with an instruction in the payload of the message, such as search string as defined in the ETSI M2M specification to send back its supported features and capabilities. The payload of the trigger message is transparent to the 3GPP network 1. As illustrated in step 2.), when this device trigger request is received at the MTC- IWF 5, the MTC-IWF 5 performs authorization and load control and requests subscriber information. Next, the MTC-IWF 5 in the 3GPP network 1 would select the way how to deliver the trigger, e.g. via T4 or T5 and forwards the trigger to the respective nodes. Depending on the trigger delivery method, e.g. T4 or T5, intermediate nodes, which may include the MSC 7, MME 8, SGSN 9 or SMS-SC 10 and which are not illustrated in Fig. 2 for simplicity, would receive the trigger message. Finally, as illustrated in step 3.), the MTC device 2 receives the trigger. In step 4.), the MTC UE 2 then sends back to the MTC application server 3 its supported capabilities and features. Again, the answer of the MTC device 2 to the MTC application server 3 is transparent to the 3GPP network 1. The following features and capabilities are examples that can be used for grouping: - Location

- Capabilities (camera, screen, sensor, mobility support, power saving, access technologies, etc.)

- Sensor type (temperature, humidity, gas, electricity, water, etc)

- Service type (fleet management, smart meter, etc.)

As will be easily appreciated by those skilled in the art, additional or alternative selection criteria may be applied likewise.

As illustrated in step 5.), now the MTC application server 3 or the SCS 4 could perform a grouping based on the features, e.g. to trigger a specific group of devices in order to facilitate the triggering or reducing the load of routing individual trigger messages. Here, if it is assumed that there are several groups managed in the network 1 and the MTC UE's 2 capabilities are identical to one of the group, the MTC AS 3 or SCS 4assigns the MTC UE 2 to this specific group according to its supported features/capabilities. The MTC AS 3 or the SCS 4 creates a binding of the external identifier of the MTC UE 2 and the external group identifier it is assigned to. As illustrated in step 6.), the MTC AS 3 or SCS 4 informs the MTC-IWF 5 about the mapping between the external group ID and the corresponding members of the groups, i.e. their external IDs. This can be done in an aggregated message or any time once a MTC UE 2 joins or leaves a group.

As illustrated in step 6.), the MTC-IWF 5 assigns an internal routable identifier, e.g. a Group IMSI, Group MSISDN, Group E.164 number, Group URI, etc., to the external group identifier and creates a binding between those and the internal IDs (IMSIs/MSISDNs) of the member MTC UEs 2. It is provided that there is a characteristic in the assigned internal group identifier in order to assure that other nodes in the network recognize that the used identifier is representing a group. The MTC-IWF 5 may also resolve the group at this point and may use the internal identifiers of the group members 2 for individual messaging per group member 2. Now the MTC AS 3 or SCS 4 can send trigger messages using the external group ID to the MTC-IWF 5, which then can resolve the target MTC UEs 2 of the group and provide trigger messages accordingly. The MTC-IWF 5 may provide the binding information of internal group ID and internal IDs of the group members 2 also to other nodes, among them e.g. MSC 7, MME 8, SGSN 9, SMS-SC 10, BM- SC, CBC, etc.

Initial grouping can be done in a similar way as follows:

Still with reference to Fig. 2, in step 1.) te MTC (or M2M) application server 3 sends a resource discovery message to the devices in a cell or the network (which can be done through an available multicast or broadcast mechanism) with an instruction providing certain conditions, such as capability, subscribed services, location, etc. In step 2.), the MTC-IWF 5 would select the way how to deliver the trigger e.g. via T4 or T5 and forwards the trigger to the respective nodes. In step 3.), MTC devices 2 would receive the resource discovery message and check their capabilities whether they are supposed to be found by the MTC AS 3. Again, the intermediate nodes are not shown here for simplicity. In step 4.), the MTC devices 2 that satisfy the given criteria send back to the MTC application server 3 their supported capabilities and features. Again, the answer of the MTC devices 2 to the MTC application server 3 is transparent to the 3GPP network 1. As illustrated in step 5.), now the MTC AS 3 or the SCS 4 could perform a grouping based on the returned list of MTC devices 2 in order to create an initial group and facilitate the triggering or reducing the load of routing individual trigger messages. In step 6.), the MTC AS 3 or SCS 4 informs the MTC-IWF 5 about the mapping between the external group ID and the corresponding MTC members 2 of the groups, i.e. their external IDs. This can be done in an aggregated message or any time once a MTC UE 2 joins or leaves a group. In step 7.), the MTC-IWF5 assigns an internal routable identifier, e.g. a Group IMSI, Group MSISDN, Group E.164 number, Group URI, etc., to the external group identifier and creates a binding between those and the internal IDs (IMSIs/MSISDNs) of the member MTC UEs 2. Again, it is provided that there is a characteristic in the assigned internal group identifier in order to assure that other nodes in the network recognize that the used identifier is representing a group.

It may be provided that the binding information between MTC AS 3 or SCS 4 and 3GPP MTC-IWF 5 is automatically updated in case the group members change, e.g. a member device is removed from an existing group or a new device is added to an existing group based on its supported features/capabilities. For instance, for removing a specific MTC UE 2 from a group, the MTC UEs 2 that have changed their capabilities/features after joining the group have to inform the MTC-IWF 5 or MTC AS3 accordingly. It may be provided that once these entities receive the respective request/information from the MTC UEs 2, they automatically update their managing information about the group.

As will be appreciated by those skilled in the art, the grouping of devices in the MTC AS 3 and SCS 4 is not limited only to the supported features / capabilities and can be done based on any criteria. This is independent of the delivery of the binding information of the group members 2 to the MTC-IWF 5 and also independent of the assignment of an internal group ID. Further, it is noted that the usage of this internal group ID is not limited to the described purpose. For example, the group ID can be given to the MBMS (Multimedia Broadcast Multicast Service) node to be mapped to the ID used for MBMS grouping.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for supporting communication with a group of devices via a mobile network (1 ),

c h a r a c t e r i z e d i n that an entity outside said mobile network (1 ) dynamically generates a group of member devices (2) by selecting, from the devices associated with said mobile network (1 ), said member devices (2) according to configurable grouping criteria on the basis of capabilities and/or service features supported by the devices,

wherein said entity assigns said group of member devices (2) an external group identifier, creates a binding of the external identifiers of the member devices (2) and said external group identifier, and provides the binding information back to said mobile network (1 ).

2. Method according to claim 1 , wherein the member devices (2) of said group of devices are MTC devices.

3. Method according to claim 1 or 2, wherein said entity outside said mobile network (1 ) is an MTC or M2M application server (3).

4. Method according to any of claims 1 to 3, wherein the characteristics used as said grouping criteria are related to the device's location, capabilities, sensor type, service type, or the like.

5. Method according to any of claims 1 to 4, wherein said entity outside said mobile network (1 ) sends a trigger message to the devices associated with said mobile network (1 ) that instructs the devices to provide information on their supported capabilities and/or service features.

6. Method according to any of claims 1 to 4, wherein said entity outside said mobile network (1 ) sends a resource discovery message to the devices associated with said mobile network (1 ) that instructs the devices to report back in case they support certain capabilities and/or service features.

7. Method according to claim 6, wherein said certain capabilities and/or service features are specified in the payload of said resource discovery message by means of one or more search strings.

8. Method according to any of claims 1 to 7, wherein a dedicated node within said mobile network (1 ), based on said binding information, assigns a mobile network internal, routable identifier - internal group identifier - to said external group identifier and creates a mapping between said internal group identifier and the mobile network internal identifiers of the member devices (2) of said group of devices.

9. Method according to claim 8, wherein said dedicated node is an MTC-IWF (5) implemented in the mobile core network.

10. Method according to claim 8 or 9, wherein said internal group identifier is a group MSISDN or a group IMSI.

1 1. Method according to any of claims 1 to 10, wherein said entity outside said mobile network (1 ) provides said binding information back to said mobile network (1 ) whenever a member device (2) joins or leaves said group of devices.

12. Method according to any of claims 1 to 1 1 , wherein said entity outside said mobile network (1 ) employs said external group identifier for sending a trigger message for the member devices (2) of said group of devices to perform a specific action.

13. Method according to, wherein said dedicated node within said mobile network (1 ) transmits said trigger message to the member devices (2) of said group of devices by means of individual transmissions.

14. Method according to any of claims 1 to 9, wherein said dedicated node within said mobile network (1 ) transmits said message to the member devices (2) of said group of devices by means of multicast transmissions.

15. Method according to any of claims 1 to 10, wherein said dedicated node keeps state of the trigger message delivery and wherein the message is resend only to those member devices (2) of said group of devices that have not received said message correctly in the first try.

16. Method according to, wherein said trigger message, in case the member devices (2) of said group of devices are attached to different serving nodes, is forwarded to all involved serving nodes.

17. System for supporting communication with a group of devices via a mobile network (1 ), in particular for executing a method according to any of claims 1 to 16,

c h a r a c t e r i z e d i n that the system comprises an entity outside said mobile network (1 ) that is configured

to dynamically generate a group of member devices (2) by selecting, from the devices associated with said mobile network (1 ), said member devices (2) according to configurable grouping criteria on the basis of capabilities and/or service features supported by the devices, to assign said group of devices an external group identifier,

to create a binding of the external identifiers of the member devices (2) of said group of devices and said external group identifier, and

to provide the binding information back to said mobile network (1 ).

18. System according to claim 17, wherein the member devices (2) of said group of devices are MTC devices.

19. System according to claim 17 or 18, wherein said entity outside said mobile network (1 ) is an MTC or M2M application server (3).

20. System according to any of claims 17 to 19, further comprising a dedicated node within said mobile network (1 ) that is configured

to assign, based on said binding information, a mobile network internal, routable identifier - internal group identifier - to said external group identifier, and to create a mapping between said internal group identifier and the mobile network internal identifiers of the member devices (2) of said group of devices.

21. System according to claim 20, wherein said dedicated node is an MTC-IWF (5) implemented in the mobile core network.

22. System according to claim 20 or 21 , wherein said dedicated node is a serving node in the mobile core network the member devices (2) of said group of devices are associated with.

23. System according to claim 22, wherein said serving node is an MSC (7), MME (8), SGSN (9), or SMS-SC (10).