U.S. patent application number 14/409646 was filed with the patent office on 2015-07-16 for update of security for group based feature in m2m.
This patent application is currently assigned to NEC Corporation. The applicant listed for this patent is NEC Corporation. Invention is credited to Anand Raghawa Prasad, Xiaowei Zhang.
Application Number | 20150200942 14/409646 |
Document ID | / |
Family ID | 48521382 |
Filed Date | 2015-07-16 |
United States Patent
Application |
20150200942 |
Kind Code |
A1 |
Zhang; Xiaowei ; et
al. |
July 16, 2015 |
UPDATE OF SECURITY FOR GROUP BASED FEATURE IN M2M
Abstract
A network node (21), which is placed within a core network,
receives a message from a transmission source (30) placed outside
the core network. The message includes an indicator indicating
whether or not the message is addressed to a group of one or more
MTC devices attached to the core network. The network node (21)
determines to authorize the transmission source (30), when the
indicator indicates that the message is addressed to the group.
Further, the message includes an ID for identifying whether or not
the message is addressed to the group. The MTC device determines to
discard the message, when the ID does not coincide with an ID
allocated for the MTC device itself. Furthermore, the MTC device
communicates with the transmission source (30) by use of a pair of
group keys shared therewith.
Inventors: |
Zhang; Xiaowei; (Tokyo,
JP) ; Prasad; Anand Raghawa; (Tokyo, JP) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
NEC Corporation |
Tokyo |
|
JP |
|
|
Assignee: |
NEC Corporation
Tokyo
JP
|
Family ID: |
48521382 |
Appl. No.: |
14/409646 |
Filed: |
April 19, 2013 |
PCT Filed: |
April 19, 2013 |
PCT NO: |
PCT/JP2013/002661 |
371 Date: |
December 19, 2014 |
Current U.S.
Class: |
726/4 |
Current CPC
Class: |
H04W 12/08 20130101;
H04W 4/08 20130101; H04L 63/10 20130101; H04L 63/104 20130101; H04W
4/70 20180201; H04W 12/0806 20190101; H04L 67/10 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04L 29/08 20060101 H04L029/08 |
Foreign Application Data
Date |
Code |
Application Number |
Jun 29, 2012 |
JP |
2012-147983 |
Claims
1. A network node placed within a core network, comprising: a
reception unit that receives 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 (Machine-Type-Communication) devices attached to
the core network, and an external ID (identifier) for the
transmission source to identify the group; a determination unit
that determines to authorize the transmission source, when the
indicator indicates that the message is addressed to the group; a
storage unit that stores a mapping of the external ID and an
internal ID for identifying addresses of the MTC devices; a mapping
unit that maps the external ID to the corresponding internal ID in
the message, by use of the mapping; and a forwarding unit that
forwards the message to a network element capable of broadcasting
the message to the MTC devices.
2. The network node according to claim 1, wherein the indicator
further indicates whether the message triggers the group to
communicate with the transmission source.
3. (canceled)
4. The network node according to claim 1, wherein the network node
comprises an MTC-IWF (MTC-Interworking Function).
5. A MTC (Machine-Type-Communication) device attached to a core
network, and configured to receive a message forwarded by the
network node according to claim 1.
6. A network node placed outside a core network, and configured to
transmit a message to the network node according to claim 1 and to
include said indicator in the message.
7. 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).
8. 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 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 an external ID (identifier) for the transmission source to
identify the group; determining to authorize the transmission
source, when the indicator indicates that the message is addressed
to the group; storing a mapping of the external ID and an internal
ID for identifying addresses of the MTC devices; mapping the
external ID to the corresponding internal ID in the message, by use
of the mapping; and forwarding the message to a network element
capable of broadcasting the message to the MTC devices.
9. A MTC (Machine-Type-Communication) device attached to a core
network, comprising: a reception unit that receives 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 unit that determines
to discard the message, when the ID does not coincide with an ID
allocated for the MTC device itself.
10. 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.
11. The network node according to claim 10, wherein the network
node comprises an MTC-IWF (MTC-Interworking Function).
12. 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.
13. The network node according to claim 12, wherein the network
node comprises an SCS (Services Capability Server) or an SME (Short
Message Entity).
14. 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.
15. 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 unit that acquires
a pair of group keys for the group of MTC devices to securely
conduct communication with the transmission source; and a relaying
unit that relays the message by use of the group keys.
16. The gateway according to claim 15, wherein the relaying unit is
configured to: verify the message with the group keys; and discard
the message upon failing the verification.
17. The gateway according to claim 15, wherein the gateway is
deployed on a base station to which the MTC devices wirelessly
connect.
18. The gateway according to claim 15, wherein the gateway is
deployed on a network element connected to one or more base
stations to which the MTC devices wirelessly connect.
19. A MTC (Machine-Type-Communication) device attached to a core
network, comprising: an acquisition unit that acquires 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 unit that communicates with the
transmission source by use of the group keys.
20. A network node placed outside a core network, and configured to
communicate with the MTC device according to claim 19 through the
core network and to use said group keys for the communication.
21. The network node according to claim 20, wherein the network
node comprises an SCS (Services Capability Server) or an SME (Short
Message Entity).
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.
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; and communicating with the transmission source by use of
the group keys.
Description
TECHNICAL FIELD
[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
[0004] [0005] NPL 1: 3GPP TS 23.682, "Architecture enhancements to
facilitate communications with packet data networks and
applications (Release 11)", v11.1.0, 2012-06 [0006] NPL 2: 3GPP TR
23.8xy, "Machine-Type and other Mobile Data Applications
Communications Enhancements; (Release 12)", V0.1.0, 2012-05 [0007]
NPL 3: 3GPP TR 33.868, "Security aspects of Machine-Type
Communications; (Release 11)", v0.8.0
SUMMARY OF INVENTION
Technical Problem
[0008] 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.
[0009] 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
[0010] 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.
[0011] 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.
[0012] 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 determining to discard the message, when
the ID does not coincide with an ID allocated for the MTC device
itself.
[0013] 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.
[0014] 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.
[0015] 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 communication means for communicate with the
transmission source by use of the group keys.
[0016] 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.
[0017] 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
[0018] 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
[0019] FIG. 1 is a block diagram showing an example of system
architecture according to an exemplary embodiment of the present
invention.
[0020] 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.
[0021] FIG. 3 is a block diagram showing a configuration example of
a network node placed according to the exemplary embodiment of the
present invention.
[0022] FIG. 4 is a block diagram showing a configuration example of
a MTC device according to the exemplary embodiment of the present
invention.
[0023] 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
1. Discussion
[0024] SA2 has started study on group based feature in TR 23.8xy
v0.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
requirements that SA2 provided.
[0025] The architectural requirements for group based messaging
from SA2 are given below:
[0026] 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.
[0027] The group based messaging feature shall not require
additional new functionality for UEs that do not use this
feature.
[0028] 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.
[0029] The system shall provide an interface for the SCS to send a
group message. This interface shall be able to carry the following
information: [0030] the application layer content of the group
message, [0031] the group identification for which the group
message is intended, and [0032] the geographical area and RAT(s) in
which the group message shall be distributed.
[0033] The system shall be protected against overload resulting
from devices responding to the distributed group message.
[0034] Group based messaging shall be supported in GERAN, UTRAN,
and E-UTRAN access.
[0035] 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.
[0036] 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 [0037] 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. [0038] The group message should
have confidentiality and integrity protection and MTC devices which
receive the message should be able to verify it. [0039] 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 identification 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.
[0040] With the above analysis, the security requirements for MTC
group based feature are concluded as below: [0041] MTC-IWF should
verify if the SCS is authorized to send group message to a given
MTC group. [0042] MTC-IWF should be able to distinguish group
(trigger) message from other messages. [0043] Group message that
are distributed to the group of MTC devices should have
confidentiality, integrity protection and replay protection. [0044]
MTC device which receives the group message should be able to
verify if the group message is sent from an authorized SCS. [0045]
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.
2. Proposal
[0046] We propose SA3 to
[0047] 1) Study the threats and security requirements for group
based feature
[0048] 2) Include the analysis and security requirements above in
TR 33.868 for release 12, given in a separate pCR as follows.
5.x Key Issue--Group Based Messaging
5.x.1 Issue Details
[0049] 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.
5.x.2 Threats
[0050] 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.
5.x.3 Security Requirements
[0051] MTC-IWF should verify if the SCS is authorized to send group
message to a given MTC group. [0052] MTC-IWF should be able to
distinguish group (trigger) message from other messages. [0053]
Group message that are distributed to the group of MTC devices
should have confidentiality, integrity protection and replay
protection. [0054] MTC device which receives the group message
should be able to verify if the group message is sent from an
authorized SCS. [0055] 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.
[0056] Hereinafter, an exemplary embodiment of the present
invention will be described with reference to FIGS. 1 to 5.
[0057] 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)).
[0058] 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).
[0059] Further, the SCS 30 and the SME 40 connect to the core
network to communicate with the MTC devices 10.
[0060] Furthermore, the core network includes an MTC-IWF 21 and an
HSS (Home Subscriber Server) 22 in the HPLMN (Home Public Land
Mobile Network). In the core network, the MTC-IWF 21 serves as a
network node which receives a group message or group trigger from
its transmission source. Typically, the MTC-IWF 21 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 21 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.
[0061] 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.
[0062] 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.
(1) Group Message Sending and Receiving
[0063] (A) SCS 30 sends a group message over Tsp interface to
MTC-IWF 21 (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 21 can distinguish 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 21 can also distinguish the
group trigger from the group message or the non-group message.
[0064] (B) MTC-IWF 21 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 21 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 21 from HSS
22.
[0065] (C) MTC-IWF 21 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.
[0066] (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.
(2) Group ID, Group Key Management and Group Message Security
[0067] HSS 22 generates a unique group ID for the group of MTC
devices (Steps S1 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).
[0068] 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.
[0069] The MTC-IWF 21 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 21 refers to the mapping, thereby mapping the external
group ID to the corresponding internal group ID in the group
message.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] There are few options of which network node can have the
same group key and how the group message is sent:
[0074] (A) MTC Device--Group GW
[0075] 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.
[0076] (B) MTC Device--SCS (Step S7)
[0077] 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 above-mentioned (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.
[0078] (C) MTC Device--Group GW-SCS (Step S11)
[0079] 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 above-mentioned (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.
(3) The Group Message that can be Broadcasted with or without Group
ID
[0080] 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.
[0081] 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.
[0082] As shown in FIG. 3, the MTC-IWF 21 includes at least a
reception unit 211 and a determination 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
determination 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 21 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.
[0083] These units 211 to 215 can be configured by, for example,
transceivers which respectively 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.
[0084] 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 acquisition 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.
[0085] 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.
[0086] Furthermore, as shown in FIG. 5, in the case of deploying
the group GW 50 as an independent 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.
[0087] These units 501 and 502 can be configured by, for example,
transceivers which respectively 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.
[0088] 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.
[0089] Note that the present invention is not limited to the
above-mentioned exemplary embodiment, 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.
[0090] The whole or part of the exemplary embodiment disclosed
above can be described as, but not limited to, the following
supplementary notes.
(Supplementary Note 1)
[0091] Network node such as HSS creates a unique internal use group
ID for each group.
(Supplementary Note 2)
[0092] 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.
(Supplementary Note 3)
[0093] External group ID and its mapping to the unique internal use
group ID:
[0094] 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.
(Supplementary Note 4)
[0095] MTC-IWF downloads the group ID mapping via interface S6m and
stores it locally. Novelty is modification of the interface.
(Supplementary Note 5)
[0096] 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.
(Supplementary Note 6)
[0097] Indicator in a group message such that network entities e.g.
MTC-IWF can distinguish 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.
(Supplementary Note 7)
[0098] 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.
(Supplementary Note 8)
[0099] The group message can be broadcasted in one of the two ways
shown below:
[0100] (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.
[0101] (B) Do not contain the group ID: MTC device just check all
the broadcast messages with its group key.
[0102] This application is based upon and claims the benefit of
priority from Japanese patent application No. 2012-147983, filed on
Jun. 29, 2012, the disclosure of which is incorporated herein in
its entirety by reference.
REFERENCE SIGNS LIST
[0103] 10 MTC DEVICE [0104] 21 MTC-IWF [0105] 22 HSS [0106] 30 SCS
[0107] 40 SME [0108] 50 GROUP GW [0109] 101, 211 RECEPTION UNIT
[0110] 102, 212 DETERMINATION UNIT [0111] 103, 501 ACQUISITION UNIT
[0112] 104 COMMUNICATION UNIT [0113] 213 STORAGE UNIT [0114] 214
MAPPING UNIT [0115] 215 FORWARDING UNIT [0116] 502 RELAYING
UNIT
* * * * *