[0001] The present invention relates to a security solution for group based Machine-Type
Communication (MTC) with the architecture newly provided in NPL 1. The solution
can support MTC-IWF (MTC-Interworking Function) to perform proper authorization
to SCS (Services Capability Server) when a group message is sent from it. The present
invention also relates to a mechanism to deliver and broadcast the group message
securely.
Background Art
[0002] Study of group based feature is initiated in 3GPP for release 12 (see e.g. NPL 2), and
new architecture has been studied in NPL 1. With the concept of group gateway (GW)
that the inventors of this application proposed in PTL 1, this invention extends it in the
new architecture.
[0003] SCS sends group message to network node of MTC-IWF and MTC-IWF will
forward the group message to the target group of MTC devices. The message is
targeted to more than one MTC devices and may trigger these devices to communicate
with network.
Citation List
Patent Literature
[0004] PTL 1: International Patent Publication No. WO 2012/018130
Non Patent Literature
[0005] NPL 1: 3GPP TS 23.682, "Architecture enhancements to facilitate communications
with packet data networks and applications (Release 11)", v l 1.1.0, 2012-06
NPL 2: 3GPP TR 23.8xy, "Machine-Type and other Mobile Data Applications Com
munications Enhancements; (Release 12)", VO.1.0, 2012-05
NPL 3: 3GPP TR 33.868, "Security aspects of Machine-Type Communications;
(Release 11)", v0.8.0
Summary of Invention
Technical Problem
[0006] However, the inventors of this application have found a problem that a fraud group
message can cause DoS (Denial of Service) attack to the network. Note that the attacks
to MTC device described in NPL 3 also valid here.
[0007] Thus MTC-IWF should perform SCS authorization to see if it can send a group
message, especially when the message contains trigger.
Solution to Problem
[0008] In order to solve the above-mentioned problems, a network node according to first
exemplary aspect of the present invention is placed within a core network. This
network node includes a reception means for receiving a message from a transmission
source placed outside the core network, the message including an indicator indicating
whether or not the message is addressed to a group of one or more MTC devices
attached to the core network; and a determination means for determining to authorize
the transmission source, when the indicator indicates that the message is addressed to
the group.
[0009] Further, a method according to second exemplary aspect of the present invention
provides a method of controlling a network node that is placed within a core network.
This method includes receiving a message from a transmission source placed outside
the core network, the message including an indicator indicating whether or not the
message is addressed to a group of one or more MTC devices attached to the core
network; and determining to authorize the transmission source, when the indicator
indicates that the message is addressed to the group.
[0010] Further, a MTC device according to third exemplary aspect of the present invention
includes a reception means for receiving a message from the core network, the
message including an ID (identifier) for identifying whether or not the message is
addressed to a group of one or more MTC devices; and a determination means for de
termining to discard the message, when the ID does not coincide with an ID allocated
for the MTC device itself.
[001 1] Further, a method according to fourth exemplary aspect of the present invention
provides a method of controlling a MTC device attached to a core network. This
method includes receiving a message from the core network, the message including an
ID for identifying whether or not the message is addressed to a group of one or more
MTC devices; and determining to discard the message, when the ID does not coincide
with an ID allocated for the MTC device itself.
[0012] Further, a gateway according to fifth exemplary aspect of the present invention relays
a message from a transmission source of the message placed outside a core network to
a group of one or more MTC devices attached to the core network. This gateway
includes an acquisition means for acquiring a pair of group keys for the group of MTC
devices to securely conduct communication with the transmission source; and a
relaying means for relaying the message by use of the group keys.
[0013] Further, a MTC device according to sixth exemplary aspect of the present invention
includes an acquisition means for acquire a pair of group keys for securely conducting
communication with a transmission source that is placed outside the core network and
transmits a message addressed to a group of one or more MTC devices; and a commu
nication means for communicate with the transmission source by use of the group
keys.
[0014] Further, a method according to seventh exemplary aspect of the present invention
provides a method of controlling gateway that relays a message from a transmission
source of the message placed outside a core network to a group of one or more MTC
devices attached to the core network. This method includes acquiring a pair of group
keys for the group of MTC devices to securely conduct communication with the
transmission source; and relaying the message by use of the group keys.
[0015] Furthermore, a method according to eighth exemplary aspect of the present invention
provides a method of controlling a MTC (Machine-Type-Communication) device
attached to a core network. This method includes acquiring a pair of group keys for
securely conducting communication with a transmission source that is placed outside
the core network and transmits a message addressed to a group of one or more MTC
devices; and communicating with the transmission source by use of the group keys.
Advantageous Effects of Invention
[0016] According to the present invention, it is possible to perform SCS authorization to see
if it can send a group message, especially when the message contains trigger.
Brief Description of Drawings
[0017] [fig.l]Fig. 1 is a block diagram showing an example of system architecture according
to an exemplary embodiment of the present invention.
[fig.2]Fig. 2 is a sequence diagram showing an example of group message terminated
at MTC device in a system according to the exemplary embodiment of the present
invention.
[fig.3]Fig. 3 is a block diagram showing a configuration example of a network node
placed according to the exemplary embodiment of the present invention.
[fig.4]Fig. 4 is a block diagram showing a configuration example of a MTC device
according to the exemplary embodiment of the present invention.
[fig.5]Fig. 5 is a block diagram showing a configuration example of a gateway
according to the exemplary embodiment of the present invention.
Description of Embodiments
[0018] 1. Discussion
SA2 has started study on group based feature in TR 23.8xy vO.1.0 "Machine-Type
and other Mobile Data Applications Communications Enhancements (Release 12)".
SA3 should study security issue for release 12 according to the architectural re
quirements that SA2 provided.
[0019] The architectural requirements for group based messaging from SA2 are given
below:
- The network shall provide a mechanism to distribute a group message from an SCS
to those members of an MTC group located in a particular geographic area.
- The group based messaging feature shall not require additional new functionality
for UEs that do not use this feature.
- The system shall support a mechanism where a UE that uses the group based
messaging feature can efficiently recognize distributed group messages addressed to
the UE.
- The system shall provide an interface for the SCS to send a group message. This
interface shall be able to carry the following information:
- the application layer content of the group message,
- the group identification for which the group message is intended, and
- the geographical area and RAT(s) in which the group message shall be distributed.
- The system shall be protected against overload resulting from devices responding to
the distributed group message.
- Group based messaging shall be supported in GERAN, UTRAN, and E-UTRAN
access.
[0020] According to the current architecture, one can assume that MTC-IWF receives a
group message from SCS and forwards it to the target group of MTC devices.
[0021] With a group message multiple MTC devices can be triggered to respond. Therefore
an unauthorized group message may cause much more severe problem compared to
what a trigger to a single MTC device can cause. Other threats like MitM attack and
replay attack which were considered for non-group message also apply here with
amplified effect. Therefore
- Network should perform authorization of whether the SCS can send group message
to the target group. To do that, MTC-IWF should be able to distinguish the group
message from other messages.
- The group message should have confidentiality and integrity protection and MTC
devices which receive the message should be able to verify it.
- Network should provide a means for SCS, which is located outside of 3GPP
network, to communicate with the target group. The group identification is used when
SCS sends the group message. Similar with the UE identification, the group identi
fication used in 3GPP network should not be sent over an external interface, and not be
known by a node outside of 3GPP network. This applies for a SCS which is located
outside of 3GPP network.
[0022] With the above analysis, the security requirements for MTC group based feature are
concluded as below:
- MTC-IWF should verify if the SCS is authorized to send group message to a given
MTC group.
- MTC-IWF should be able to distinguish group (trigger) message from other
messages.
- Group message that are distributed to the group of MTC devices should have confi
dentiality, integrity protection and replay protection.
- MTC device which receives the group message should be able to verify if the group
message is sent from an authorized SCS.
- Group ID should not to be exposed to a node that is located outside of 3GPP network.
This includes the SCS which is outside of 3GPP network as well.
[0023] 2. Proposal
We propose SA3 to
1) Study the threats and security requirements for group based feature
2) Include the analysis and security requirements above in TR 33.868 for release 12,
given in a separate pCR as follows.
[0024] 5.x Key Issue - Group Based Messaging
5.x. 1 Issue Details
SA2 has started study for group based feature in TR 23.8xy (release 12). According
to the current architecture, one can assume that MTC-IWF receives a group message
from SCS and forwards it to the target group of MTC devices.
[0025] 5.X.2 Threats
With a group message multiple MTC devices can be triggered to respond. Therefore
an unauthorized group message may cause much more severe problem compared to
what a trigger to a single MTC device can cause. Other threats like MitM attack and
replay attack which were considered for non-group message also apply here with
amplified effect.
[0026] 5.x.3 Security Requirements
- MTC-IWF should verify if the SCS is authorized to send group message to a given
MTC group.
- MTC-IWF should be able to distinguish group (trigger) message from other
messages.
- Group message that are distributed to the group of MTC devices should have confi
dentiality, integrity protection and replay protection.
- MTC device which receives the group message should be able to verify if the group
message is sent from an authorized SCS.
- Group ID should not to be exposed to a node that is located outside of 3GPP
network. This includes the SCS which is outside of 3GPP network as well.
[0027] Hereinafter, an exemplary embodiment of the present invention will be described
with reference to Figs. 1 to 5.
[0028] As shown in Fig. 1, a system according to this exemplary embodiment includes a
core network (3GPP network), a plurality of MTC devices 10 which connect to the
core network through a RAN (Radio Access Network), and an SCS 30 and an SME
(Short Message Entity) 40 which serve as group message or group trigger sources
placed outside the core network. Note that the RAN is formed by a plurality of base
stations (i.e., eNBs (evolved Node Bs)).
[0029] Among them, each MTC device 10 is a UE for MTC connecting to the core network
via the Um/Uu/LTE-Uu interface. The UE can host one or multiple MTC Applications.
The corresponding MTC Applications in the external network are hosted on one or
multiple ASs (Application Servers).
[0030] Further, the SCS 30 and the SME 40 connect to the core network to communicate
with the MTC devices 10.
[0031] Furthermore, the core network includes an MTC-IWF 2 1 and an HSS (Home
Subscriber Server) 22 in the HPLMN (Home Public Land Mobile Network). In the
core network, the MTC-rWF 2 1 serves as a network node which receives a group
message or group trigger from its transmission source. Typically, the MTC-rWF 2 1
receives a group message which can be also be a group trigger from the SCS 30 via
Tsp interface or from the SME 40 via T4 and Tsms interfaces, and forwards the group
message to the MME (Mobility Management Entity), SGSN (Serving GPRS (General
Packet Radio Service) Support Node) or MSC (Mobile Switching Centre), which
serves as a network element forwarding the group message to the MTC device 10, via
T5b/T5a/T5c interface, so that the group message or group trigger can be routed to the
MTC device 10. The HSS 22 or the MTC-IWF 2 1 can create and stores a mapping of
an internal and external group IDs, and the HSS 22 generates a pair of group keys
(which will be described later). One of the group keys is generated for encryption and
decryption, another one is generated for integrity protection.
[0032] Next, operation examples of this exemplary embodiment will be described in detail
with reference to Fig. 2. Fig. 2 shows the message sequence of group message sending
to a group of MTC devices. There are more than one device in the MTC device group.
[0033] In this exemplary embodiment, assume that mutual authentication has been
performed between group GW (which will be described later) and network and group
GW and MTC devices 10. Note that a gateway was proposed in a separate invention of
PTL 1 which is responsible of receiving group message and send it to MTC devices,
and send concatenated messages for MTC device communicating with network or
SCS. This exemplary embodiment proposes some new functions for the gateway and it
can be either deployed in a network node or be an independent node.
[0034] (1) Group message sending and receiving
(A) SCS 30 sends a group message over Tsp interface to MTC-IWF 2 1 (Step S8). The
group message contains group ID and geography area information (this is described in
NPL 2). In addition, the message includes an indicator indicating whether the message
is a group message or a non-group message. Therefore, the MTC-IWF 2 1 can dis
tinguish the group message from the non-group message, thereby being able to
perform a proper authorization to the SCS 30 as described at the following (B).
Further, the indicator may indicate whether or not the group message contains trigger.
In this case, the MTC-IWF 2 1 can also distinguish the group trigger from the group
message or the non-group message.
[0035] (B) MTC-IWF 2 1 performs authorization to SCS 30, to see if it can send group
message to the target group (Step S9). This should be the same authorization procedure
when MTC-IWF 2 1 sends a non-group message. The authorization is based on the
group information of group ID, geography area information received from SCS 30 and
authorization data retrieved by MTC-IWF 2 1 from HSS 22.
[0036] (C) MTC-IWF 2 1 forwards the group message to a group GW 50 (Step S10). The
group GW 50 can own more than one group. It can be a virtual function that deployed
on any network node like eNB/MME/MTC-IWF, or an independent node.
[0037] (D) The group GW 50 broadcasts the group message to the target group of MTC
devices (Step S12). In the case where the group GW 50 is deployed on the eNB, the
group message is broadcast only between the eNB and the MTC devices. Therefore, it
is possible to avoid congestion of the core network. On the other hand, in the case
where the group GW 50 is deployed on the MME which serves as one of network
elements connected to one or more base stations, it is possible to broadcast the group
message over a plurality of areas while partly reducing the congestion of the core
network.
[0038] (2) Group ID, group key management and group message security
HSS 22 generates a unique group ID for the group of MTC devices (Steps SI and
S3). At Step S3, the HSS 22 can generate the group keys. For the SCS 30 which is
located outside of the core network (3GPP network domain), the group ID should not
be exposed to SCS 30 thus HSS 22 will have a mapping of the group IDs and external
use group IDs. Internal use Group ID can be sent to MTC devices 10, group GW 50
within the existing NAS or AS messages (Step S4).
[0039] There can be two ways of generating an external group ID. It can be created by HSS
22 and provided to SCS 30. Alternatively it can be created by SCS 30 and provided to
HSS 22 (Step S2). Either way, HSS will create the mapping of both group IDs.
[0040] The MTC-IWF 2 1 downloads the mapping from the HSS 22 (Step S5), and stores it
locally (Step S6). Further, upon forwarding the group message to the group GW 50 at
the above-mentioned Step S10, the MTC-IWF 2 1 refers to the mapping, thereby
mapping the external group ID to the corresponding internal group ID in the group
message.
[0041] Thus, in this exemplary embodiment, the internal group ID shall be hidden from
outside the core network. Therefore, it is possible to prevent a fraud group message
from causing attack to the core network. Further, the external group ID is made
effective only after the source authorization. Therefore, even if the external group ID is
revealed to attackers, it is possible to prevent attack.
[0042] Security is needed when a group message is broadcasted to the group of MTC
devices. This exemplary embodiment proposes to use a pair of group keys for the
group message confidentiality and integrity protection.
[0043] After MTC devices and group GW are mutually authenticated with network, the
group key management and security activation should be performed (Step S4). The
group key is for all the MTC devices in a MTC group to have group key. This group
key is the same for all the MTC devices in the group, and it is shared by them with
group GW 50 and optionally with the other end where the group message is sent.
[0044] There are few options of which network node can have the same group key and how
the group message is sent:
(A) MTC device - group GW
The group message transferring between group GW 50 and SCS 30 can be protected
by IPsec or other existing network security solution. Group GW 50 uses the group key
to protect the group message and broadcasts it to the target group MTC devices. At
Step S4, the MTC devices and the group GW 50 acquire the group keys from the HSS
22, so that the group keys are shared between the MTC devices and the group GW 50.
[0045] (B) MTC device - SCS (Step S7)
In this case, group GW 50 will forward the group message and broadcast it as it is.
On the other hand, the MTC devices acquire the group keys as with the abovementioned
(A). Further, after the authorization, the SCS 30 acquire the group keys
from the HSS 22 through the MTC-IWF 21, so that the group keys are shared between
the MTC devices and the SCS 30. Therefore, it is possible to provide end-to-end
security between MTC devices and SCS 30. MTC device can perform authorization to
SCS 30.
[0046] (C) MTC device - group GW - SCS (Step S11)
In this case, the communication between group GW 50 and SCS 30 can be protected
by the group key. Group GW 50 can perform authorization to SCS 30 with the group
key and MTC device do not need to perform authorization. As with the abovementioned
(A) and (B), the group keys are shared between the MTC devices, the group
GW 50 and the SCS 30. Further, the group GW verifies the group message (decryption
and integrity check) with the shared group key, thereby discarding the group message
upon failing the verification. In this case, it is possible to avoid the broadcasting itself.
[0047] (3) The group message that can be broadcasted with or without group ID
When the group ID is included in the group message, MTC device listens to the
message but will only receive the message which contains the same group ID it has,
then the MTC device will perform integrity check and decrypt the message with the
shared group key (Steps S13 and S14). When the group ID does not coincide with the
group ID allocated for the MTC device itself, the MTC device discards the group
message. In this case, the MTC device does not need to verify the group message.
Therefore, it is possible to reduce processing load on the MTC device.
[0048] On the other hand, when the group ID is not included, the MTC device will listen to
all the broadcasts and perform integrity check and decryption and only respond to the
ones it can verify.
[0049] As shown in Fig. 3, the MTC-IWF 2 1 includes at least a reception unit 211 and a de
termination unit 212. The reception unit 211 receives from the SCS 30 or the SME 40
the group message or group trigger including the above-mentioned indicator. The de
termination unit 211 determines to authorize the SCS 30 or the SME 40, when the
indicator indicates the group message or group trigger. In addition to these units 211
and 212, the MTC-IWF 2 1 can include a storage unit 213, a mapping unit 214, and a
forwarding unit 215. The storage unit 213 stores the above-mentioned mapping. The
mapping unit 214 maps the external group ID to the corresponding internal group ID in
the group message or group trigger, by use of the mapping. The forwarding unit 215
forwards the group message or group trigger to one of the MME/SGSN/MSC, so that
the group message or group trigger is broadcast to the MTC devices. Note that these
units 211 to 215 are mutually connected with each other thorough a bus or the like.
[0050] These units 211 to 215 can be configured by, for example, transceivers which r e
spectively conduct communication with the HSS 22, the MME/SGSN/MSC, the SCS
30 and the SME 40, and a controller which controls these transceivers to execute the
processes shown at Steps S5, S6 and S8 to S10 in Fig. 2 or processes equivalent
thereto.
[0051] Further, as shown in Fig. 4, each of the MTC devices 10 includes at least a reception
unit 101 and a determination unit 102. The reception unit 101 receives from the core
network the group message or group trigger including the above-mentioned group ID.
The determination unit 102 determines to discard the group message or group trigger,
when the group ID does not coincides with a group ID for each of the MTC devices 10
itself. As substitutes for or in addition to these units 101 and 102, each of the MTC
devices 10 can include an acquisition unit 103 and a communication unit 104. The ac
quisition unit 103 acquires the group keys from e.g. the HSS 20. The communication
unit 104 communicates with the SCS 30 or the SME 40 by use of the group keys. Note
that these units 101 to 104 are mutually connected with each other thorough a bus or
the like.
[0052] These units 101 to 104 can be configured by, for example, a transceiver which
wirelessly conducts communication with the core network through the RAN, and a
controller which controls this transceiver to execute the processes shown at Steps S4
and S12 to S14 in Fig. 2 or processes equivalent thereto.
[0053] Furthermore, as shown in Fig. 5, in the case of deploying the group GW 50 as an in
dependent node, the group GW 50 includes at least an acquisition unit 501 and a
relaying unit 502. The acquisition unit 501 acquires the group keys from e.g. the HSS
20. The relaying unit 502 relays the group message or group trigger by use of the
group keys. Note that these units 501 and 502 are mutually connected with each other
thorough a bus or the like.
[0054] These units 501 and 502 can be configured by, for example, transceivers which re
spectively conduct communication with the MTC-IWF 21, the HSS 22 and the MME/
SGSN/MSC/RAN, and a controller which controls these transceivers to execute the
processes shown at Steps S4 and S10 to S12 in Fig. 2 or processes equivalent thereto.
[0055] Although the illustration is omitted, each of the SCS 30 and the SME 40 includes, in
addition to functions mounted on each of typical SCS and SME, at least one of a
function of including the above-mentioned indicator in the group message or group
trigger, a function of including the above-mentioned group ID in the group message or
group trigger, and a function of communicating with the group of MTC devices by use
of the above-mentioned group keys.
[0056] Note that the present invention is not limited to the above-mentioned exemplary em
bodiment, and it is obvious that various modifications can be made by those of
ordinary skill in the art based on the recitation of the claims.
[0057] The whole or part of the exemplary embodiment disclosed above can be described as,
but not limited to, the following supplementary notes.
[0058] (Supplementary note 1)
Network node such as HSS creates a unique internal use group ID for each group.
[0059] (Supplementary note 2)
HSS sends the group ID to all the group member of MTC devices and the group GW.
The group GW can be a function deployed in a network node or be an independent
node.
[0060] (Supplementary note 3)
External group ID and its mapping to the unique internal use group ID:
HSS keeps a mapping of the external group ID and unique group ID which is only
used in the network. The external group ID can be either allocated by HSS or by SCS
to which the group subscribes to.
[0061] (Supplementary note 4)
MTC-IWF downloads the group ID mapping via interface S6m and stores it locally.
Novelty is modification of the interface.
[0062] (Supplementary note 5)
A pair of group keys for encryption and integrity protection is generated. The pair of
group keys is the same for all the MTC devices within the group. Group GW and/or
SCS can have the same group key.
[0063] (Supplementary note 6)
Indicator in a group message such that network entities e.g. MTC-IWF can dis
tinguish it from other non-group messages. An indicator for IWF to distinguish group
trigger message from non-trigger group message. This helps MTC-IWF to perform
proper authorization.
[0064] (Supplementary note 7)
The group GW broadcasts the group message to the group of MTC devices, it is
protected by a pair of group keys, such that only the proper MTC devices can receive
and read the group message.
[0065] (Supplementary note 8)
The group message can be broadcasted in one of the two ways shown below:
(A) Contains the group ID: MTC device will check the group ID in the broadcast, if
it is the same with the group ID it holds, it will perform integrity check and decrypt the
message with using the (group ID related) group key.
(B) Do not contain the group ID: MTC device just check all the broadcast messages
with its group key.
[0066] This application is based upon and claims the benefit of priority from Japanese patent
application No. 2012-147983, filed on June 29, 2012, the disclosure of which is in
corporated herein in its entirety by reference.
Reference Signs List
[0067] 10 MTC DEVICE
2 1 MTC-IWF
22 HSS
30 SCS
40 SME
50 GROUP GW
101, 211 RECEPTION UNIT
102, 212 DETERMINATION UNIT
103, 501 ACQUISITION UNIT
104 COMMUNICATION UNIT
213 STORAGE UNIT
214 MAPPING UNIT
215 FORWARDING UNIT
502 RELAYING UNIT

WE CLAIMS:-
A network node placed within a core network, comprising:
a reception means for receiving a message from a transmission source
placed outside the core network, the message including an indicator in
dicating whether or not the message is addressed to a group of one or
more MTC (Machine-Type-Communication) devices attached to the
core network; and
a determination means for determining to authorize the transmission
source, when the indicator indicates that the message is addressed to
the group.
The network node according to Claim 1, wherein the indicator further
indicates whether the message triggers the group to communicate with
the transmission source.
The network node according to Claim 1 or 2,
wherein the message further includes an external ID (identifier) for the
transmission source to identify the group, and
wherein the network node further comprises:
a storage means for storing a mapping of the external ID and an internal
ID for identifying addresses of the MTC devices;
a mapping means for mapping the external ID to the corresponding
internal ID in the message, by use of the mapping; and
a forwarding means for forwarding the message to a network element
capable of broadcasting the message to the MTC devices.
The network node according to any one of Claims 1 to 3, wherein the
network node comprises an MTC-IWF (MTC-Interworking Function).
A MTC (Machine-Type-Communication) device attached to a core
network, and configured to receive a message forwarded by the
network node according to any one of Claims 1 to 4.
A network node placed outside a core network, and configured to
transmit a message to the network node according to any one of Claims
1 to 4 and to include said indicator in the message.
The network node according to Claim 6, wherein the network node
placed outside the core network comprises an SCS (Services Capability
Server) or an SME (Short Message Entity).
A method of controlling a network node that is placed within a core
network, the method comprising:
receiving a message from a transmission source placed outside the core
PCT/JP2013/002661
network, the message including an indicator indicating whether or not
the message is addressed to a group of one or more MTC
(Machine-Type-Communication) devices attached to the core network;
and
determining to authorize the transmission source, when the indicator
indicates that the message is addressed to the group.
A MTC (Machine-Type-Communication) device attached to a core
network, comprising:
a reception means for receiving a message from the core network, the
message including an ID (identifier) for identifying whether or not the
message is addressed to a group of one or more MTC devices; and
a determination means for determining to discard the message, when
the ID does not coincide with an ID allocated for the MTC device
itself.
A network node placed within a core network, and configured to
forward a message to the MTC device according to Claim 9 and to
include said ID in the message.
The network node according to Claim 10, wherein the network node
comprises an MTC-IWF (MTC-Interworking Function).
A network node placed outside a core network, and configured to
transmit a message to the MTC device according to Claim 9 through
the core network and to include said ID in the message.
The network node according to Claim 12, wherein the network node
comprises an SCS (Services Capability Server) or an SME (Short
Message Entity).
A method of controlling a MTC (Machine-Type-Communication)
device attached to a core network, the method comprising:
receiving a message from the core network, the message including an
ID (identifier) for identifying whether or not the message is addressed
to a group of one or more MTC devices; and
determining to discard the message, when the ID does not coincide
with an ID allocated for the MTC device itself.
A gateway that relays a message from a transmission source of the
message placed outside a core network to a group of one or more MTC
(Machine-Type-Communication) devices attached to the core network,
the gateway comprising:
an acquisition means for acquiring a pair of group keys for the group of
MTC devices to securely conduct communication with the transmission
WO 2014/002351 PCT/JP2013/002661
source; and
a relaying means for relaying the message by use of the group keys.
[Claim 16] The gateway according to Claim 15, wherein the relaying means is
configured to:
verify the message with the group keys; and
discard the message upon failing the verification.
[Claim 17] The gateway according to Claim 15 or 16, wherein the gateway is
deployed on a base station to which the MTC devices wirelessly
connect.
[Claim 18] The gateway according to Claim 15 or 16, wherein the gateway is
deployed on a network element connected to one or more base stations
to which the MTC devices wirelessly connect.
[Claim 19] A MTC (Machine-Type-Communication) device attached to a core
network, comprising:
an acquisition means for acquire a pair of group keys for securely
conducting communication with a transmission source that is placed
outside the core network and transmits a message addressed to a group
of one or more MTC devices; and
a communication means for communicate with the transmission source
by use of the group keys.
[Claim 20] A network node placed outside a core network, and configured to com
municate with the MTC device according to Claim 19 through the core
network and to use said group keys for the communication.
[Claim 21] The network node according to Claim 20, wherein the network node
comprises an SCS (Services Capability Server) or an SME (Short
Message Entity).
[Claim 22] A method of controlling gateway that relays a message from a
transmission source of the message placed outside a core network to a
group of one or more MTC (Machine-Type-Communication) devices
attached to the core network, the method comprising:
acquiring a pair of group keys for the group of MTC devices to
securely conduct communication with the transmission source; and
relaying the message by use of the group keys.
[Claim 23] A method of controlling a MTC (Machine-Type-Communication)
device attached to a core network, the method comprising:
acquiring a pair of group keys for securely conducting communication
with a transmission source that is placed outside the core network and
transmits a message addressed to a group of one or more MTC devices;
PCT/JP2013/002661
and
communicating with the transmission source by use of the group keys.