U.S. patent application number 13/992662 was filed with the patent office on 2013-11-28 for traffic encryption key management for machine to machine multicast group.
This patent application is currently assigned to LG ELECTRONICS INC.. The applicant listed for this patent is Inuk Jung, Jinsam Kwak, Wookbong Lee, Kiseon Ryu. Invention is credited to Inuk Jung, Jinsam Kwak, Wookbong Lee, Kiseon Ryu.
Application Number | 20130315389 13/992662 |
Document ID | / |
Family ID | 46207621 |
Filed Date | 2013-11-28 |
United States Patent
Application |
20130315389 |
Kind Code |
A1 |
Jung; Inuk ; et al. |
November 28, 2013 |
TRAFFIC ENCRYPTION KEY MANAGEMENT FOR MACHINE TO MACHINE MULTICAST
GROUP
Abstract
A method for decrypting multicast data by a mobile station in a
wireless communication system is described. The method includes
receiving an identifier of a group from a base station, receiving
parameters for generating a group traffic key from the base
station, wherein the parameters include an authentication key for
the group, a group security seed and a counter, performing a key
derivation function to generate the group traffic key based on the
identifier and the parameters and decrypting multicast data using
the group traffic key.
Inventors: |
Jung; Inuk; (Anyang-si,
KR) ; Kwak; Jinsam; (Anyang-si, KR) ; Ryu;
Kiseon; (Anyang-si, KR) ; Lee; Wookbong;
(Anyang-si, KR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Jung; Inuk
Kwak; Jinsam
Ryu; Kiseon
Lee; Wookbong |
Anyang-si
Anyang-si
Anyang-si
Anyang-si |
|
KR
KR
KR
KR |
|
|
Assignee: |
LG ELECTRONICS INC.
Seoul
KR
|
Family ID: |
46207621 |
Appl. No.: |
13/992662 |
Filed: |
December 8, 2011 |
PCT Filed: |
December 8, 2011 |
PCT NO: |
PCT/KR2011/009490 |
371 Date: |
July 17, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61420779 |
Dec 8, 2010 |
|
|
|
61449723 |
Mar 7, 2011 |
|
|
|
Current U.S.
Class: |
380/31 |
Current CPC
Class: |
H04W 12/04031 20190101;
H04W 12/04033 20190101; H04W 12/04071 20190101; H04W 4/70 20180201;
H04W 12/0401 20190101; H04L 2463/061 20130101; H04W 4/08 20130101;
H04L 63/065 20130101 |
Class at
Publication: |
380/31 |
International
Class: |
H04W 12/04 20060101
H04W012/04 |
Claims
1. A method for decrypting multicast data by a mobile station in a
wireless communication system, the method comprising: receiving an
identifier of a group from a base station; receiving parameters for
generating a group traffic key from the base station, wherein the
parameters include an authentication key for the group, a group
security seed and a counter; performing a key derivation function
to generate the group traffic key based on the identifier and the
parameters; and decrypting multicast data using the group traffic
key.
2. The method of claim 1, further comprising: receiving a trigger
message for updating the group traffic key from the base station;
performing the key derivation function to update the group traffic
key based on updated parameters in the trigger message; and
decrypting the multicast data using the group traffic key
updated.
3. The method of claim 2, wherein the updated parameters in the
trigger message include the authentication key newly derived.
4. The method of claim 2, wherein the updated parameters in the
trigger message include the group security seed is changed.
5. The method of claim 4, wherein the group security seed is
changed when other device is unsubscribed from the group.
6. The method of claim 2, wherein the updated parameters in the
trigger message include the counter incremented by 1.
7. The method of claim 1, wherein the identifier of the group is
M2M (Machine to Machine) device group identifier.
8. The method of claim 7, further comprising: transmitting, to the
base station, control information indicating that M2M capability is
enabled.
9. The method of claim 8, wherein the control information is
transmitted during a basic capability negotiation procedure with
the base station.
Description
TECHNICAL FIELD
[0001] The present disclosure generally relates to a traffic
encryption key management for the devices in machine to machine
multicast group.
BACKGROUND ART
[0002] Protection technologies for the multimedia traffic to
multiple of devices have been introduced in a wireless
communication system. Recently, in machine to machine (M2M)
communication environments, M2M devices tend to have a limited
capability and do not consume multimedia data as traditional
devices do in a general wireless communication system.
DISCLOSURE OF INVENTION
Technical Problem
[0003] In IEEE 802.16e, MBRA (Multicast and Broadcast Rekeying
Algorithm) for MBS (Multicast and Broadcast Service) and MTK (MBS
Transport Key) based multicast traffic encryption have been defined
as technologies covering multicast service for a group of
devices.
[0004] The existing technologies are mainly designed for multimedia
service settings. Since M2M devices have a low mobility and can
operate while they belong to M2M device groups for a device
management, an enhancement to the security mechanism for multicast
traffic needs to be defined.
[0005] This disclosure is to provide a method for generating a
traffic encryption key for M2M Device Group in M2M communication
environments. This disclosure is to provide a reduced security key
hierarchy for multicast data transmission in M2M environments.
Also, this disclosure is to provide a method for updating a traffic
encryption key when other mobile device is unsubscribed from the
M2M Device Group. This disclosure is to provide a method for
assigning M2M Device Group Identifier for transmitting multicast
data to the devices in the M2M Device Group.
Solution to Problem
[0006] In one aspect, a method for decrypting multicast data by a
mobile station in a wireless communication system is described. The
method includes receiving an identifier of a group from a base
station, receiving parameters for generating a group traffic key
from the base station, wherein the parameters include an
authentication key for the group, a group security seed and a
counter, performing a key derivation function to generate the group
traffic key based on the identifier and the parameters and
decrypting multicast data using the group traffic key.
[0007] This, and other aspects, can include one or more of the
following features. The method further includes receiving a trigger
message for updating the group traffic key from the base station,
performing the key derivation function to update the group traffic
key based on updated parameters in the trigger message, and
decrypting the multicast data using the group traffic key updated.
The updated parameters in the trigger message include the
authentication key newly derived. The updated parameters in the
trigger message include the group security seed is changed. The
group security seed is changed when other device is unsubscribed
from the group. The updated parameters in the trigger message
include the counter incremented by 1. The identifier of the group
is M2M (Machine to Machine) device group identifier. The method
further includes transmitting, to the base station, control
information indicating that M2M capability is enabled. The control
information is transmitted during a basic capability negotiation
procedure with the base station.
[0008] Implementations of the described techniques may include
hardware, a method or process, or computer software on a
computer-accessible medium.
Advantageous Effects of Invention
[0009] According to the exemplary embodiments described in this
disclosure, the mobile station can participate in the multicasting
group using M2M Device Group ID. The mobile station can generate
and update the traffic encryption key without heavy intervention of
the base station. The mobile station operating even in idle state
can update the traffic encryption key.
[0010] The details of one or more implementations are set forth in
the accompanying drawings and the description below. Other features
will be apparent from the description and drawings, and from the
claims.
BRIEF DESCRIPTION OF DRAWINGS
[0011] FIG. 1 is a block diagram illustrating a wireless
communication system.
[0012] FIG. 2 is a block diagram of a mobile station and a base
station in the wireless communication system.
[0013] FIG. 3 shows a flow chart illustrating network entry
procedures and initialization procedures in the wireless
communication system.
[0014] FIG. 4 is an exemplary diagram illustrating relationship
between M2M Device Group ID and M2M Device ID.
[0015] FIG. 5 illustrates an exemplary method for assigning an M2M
Device Group ID and an M2M Device ID to a M2M device during the
network entry procedure.
[0016] FIG. 6 is a flow chart of a process for decrypting multicast
data of a mobile station.
[0017] FIG. 7 shows a security key hierarchy for the traffic
key.
[0018] FIG. 8 shows a flow chart of a process for providing L2
Group Security.
[0019] FIG. 9 through FIG. 12 illustrate exemplary processes for
updating the group traffic key.
MODE FOR THE INVENTION
[0020] The technology described below can be used in various
wireless communication systems such as code division multiple
access (CDMA), frequency division multiple access (FDMA), time
division multiple access (TDMA), orthogonal frequency division
multiple access (OFDMA), single carrier frequency division multiple
access (SC-FDMA), etc. The CDMA can be implemented with a radio
technology such as universal terrestrial radio access (UTRA) or
CDMA-2000. The TDMA can be implemented with a radio technology such
as global system for mobile communications (GSM)/general packet
ratio service (GPRS)/enhanced data rate for GSM evolution (EDGE).
The OFDMA can be implemented with a radio technology such as
institute of electrical and electronics engineers (IEEE) 802.11
(Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA),
etc. IEEE 802.16m is an evolution of IEEE 802.16e, and provides
backward compatibility with an IEEE 802.16-based system. The UTRA
is a part of a universal mobile telecommunication system (UMTS).
3rd generation partnership project (3GPP) long term evolution (LTE)
is a part of an evolved UMTS (E-UMTS) using the E-UTRA. The 3GPP
LTE uses the OFDMA in downlink and uses the SC-FDMA in uplink.
LTE-advance (LTE-A) is an evolution of the 3GPP LTE.
[0021] For clarity, the following description will focus on the
IEEE 802.16m. However, technical features of the present invention
are not limited thereto.
[0022] Wireless Communication System
[0023] FIG. 1 is a block diagram illustrating a wireless
communication system. The wireless communication system is widely
deployed to provide various communication services such as voice,
packet data, etc. Referring to FIG. 1, the wireless communication
system includes a plurality of mobile stations (MS) 100 and one or
more of base stations (BS) 200. The mobile station can be fixed or
mobile, and can be referred with other terminologies such as UE
(User Equipment), UT (User Terminal), SS (Subscriber Station),
Wireless Device and AMS (Advanced Mobile Station), etc.
[0024] The base station 200 generally indicates a fixed station
communication with the mobile station 100, and the base station 200
can be referred with other terminologies such as NodeB, BTS (Base
Transceiver System), Access Point, etc.
[0025] FIG. 2 is a block diagram of a mobile station and a base
station in the wireless communication system.
[0026] The mobile station 100 includes a control unit 110, memory
120 and RF (Radio Frequency) unit 130. The mobile station 100 can
include a display unit and a user interface unit as well.
[0027] The control unit 110 carries out the functions, steps and/or
methods described herein. The control unit 110 can execute the
functions related to the layers of radio interface protocols.
[0028] The memory 120 is connected to the control unit 110, and
stores protocols and parameters for performing wireless
communications. Namely, the memory 120 stores an operating system
of the mobile terminal, application programs and general files.
[0029] The RF unit 130 is connected to the control unit 110 to
transmit and receive radio signals.
[0030] Additionally, the display unit displays various information
of the mobile station and can be implemented with well-known
display elements such as LCD (Liquid Crystal Display), OLED
(Organic Light Emitting Diodes), etc. The user interface unit can
include well-known user interfaces such a key pad, a touch screen,
etc.
[0031] The base station 200 includes a control unit 210, a memory
220 and a RF unit 230.
[0032] The control unit 210 carries out the functions, steps and/or
methods described herein.
[0033] The control unit 210 can execute the functions related to
the wireless communication protocol layers.
[0034] The memory 220 is connected to the control unit 210, and
stores protocols and parameters for performing wireless
communications.
[0035] The RF unit 230 is connected to the control unit 210 to
transmit and receive radio signals.
[0036] The control units 110 and 210 can include ASIC
(application-specific integrated circuit), other chipsets, logic
circuits and/or data processing units. The memory 120 and 220 can
include ROM (read-only memory), RAM (random access memory), flash
memory, memory cards, storage media and/or other storage devices.
The RF unit 130 and 230 can include baseband circuits to process
radio signals. If the exemplary embodiments are implemented in the
form of software, the methods (steps, functions, etc.) which will
be described in this disclosure can be implemented as modules. The
modules can be stored in the memory 120 and 220, and can be
executed by the control unit 110 and 210.
[0037] Network Entry and Initialization
[0038] FIG. 3 shows a flow chart illustrating network entry
procedures and initialization procedures in the wireless
communication system.
[0039] Referring to FIG. 3, the mobile station 100 searches a base
station by scanning for a downlink channel, and the mobile station
100 obtains system information on downlink and uplink (S10).
[0040] Then, the mobile station 100 performs a ranging process with
the base station which has been searched (S20). The ranging process
enables the mobile station 100 to get synchronized with the uplink
through the contention-based ranging, where the mobile station 100
selects a randomly selected CDMA ranging code and transmits it to
the base station 200.
[0041] The base station 200 informs adjustment information for the
mobile station via a ranging response message (RNG-RSP). During the
adjustment the status of the ranging response message is configured
as `continue,` and after the adjustment the base station 200
transmits the ranging response message indicating the status is
configured as `success.`
[0042] The RNG-RSP message, which is transferred from the base
station 200 to the mobile station, includes power offset
information, timing offset information and frequency offset
information of the mobile station 100. The mobile station 100
transmits data to the base station 200 based on the information
afterwards.
[0043] When the mobile station 100 indicates that the ranging
request by the ranging code is processed successfully, the mobile
station 100 transmits a ranging request (RNG-REQ) message to the
base station 200 (S21) and the base station 200 transmits RNG-RSP
to the mobile station 100 in response to the RNG-REQ (S22).
[0044] When the mobile station 100 receives the RNG-RSP, the mobile
station 100 transmits, to the base station 200, Subscriber Station
Basic Capability Request (SBC-REQ) message, which includes
information on parameters and authentication methods which the
mobile station supports for the data receiving and transmission
with the base station (S30).
[0045] Upon receiving the SBC-REQ message, the mobile station 200
compares the parameters and authentication methods in the SBC-REQ
message with the parameters and authentication methods that the
base station 200 supports. According to results of the comparison,
the base station 200 determines the parameters and the
authentication method that the mobile station 100 will use for the
data communication with the base station 200, and transmits
Subscriber Station Basic Capability Response (SBC-RSP) message to
the mobile station 100 including the determined parameters and the
determined authentication method (S40).
[0046] After completion of the basic capability negotiation with
the base station 200, the mobile station 100 starts authentication
procedure (S50). During the authentication procedure, the mobile
station 100 and the base station 200 mutually authenticate each
other, and exchange security keys which will be used for protected
data transmission afterwards.
[0047] Thereafter, the mobile station 100 enters into the
registration procedure with the base station 200 by transmitting
Registration Request (REG-REQ) message (S61) and by receiving
Registration Response (REG-RSP) message (S62).
[0048] Once the registration procedure is completed, the mobile
station 100 establishes IP connectivity and transfers operational
parameters. After completion of the network entry procedures and
the initialization procedures described above, the connection
between the mobile station 100 and the base station 200 is
established.
[0049] Machine to Machine: M2M
[0050] Machine-to-Machine (M2M) refers to technologies that allow
both wireless and wired systems to communicate with other devices
of the same ability. Thus, M2M communication indicates a wired and
wireless communication between devices rather than a general
communication between a device controlled by user and other device.
Also, M2M devices used in cellular network lacks performance or
capability when compared to general devices.
[0051] M2M communication environments have different
characteristics than traditional communication environments, such
as a large number of devices in a cell, low data traffic, less
frequent data transmission, limited number of data characteristics,
insensitive to time delay, etc. M2M devices are, for example, a
vending machine, a fixed metering machine and a fixed surveillance
video. A large number of devices in a cell can be categorized by
device type, class, service type, etc. M2M devices can have the
following features depending on the services they support:
[0052] 1. M2M devices transmit data less frequently. Data can be
periodically transmitted.
[0053] 2. M2M devices have a low mobility or are stationary.
[0054] 3. M2M devices are less sensitive generally towards latency
in signal transmission.
[0055] Many M2M devices showing the above features can communicate
with each other or even with the base station using multi-hop
configuration or hierarchical structure.
[0056] Terms for M2M system are as follows:
[0057] (1) Machine-to-Machine (M2M) communication: Information
exchange between user devices through a Base Station, or between a
device and a server in the core network through a Base Station,
that may be carried out without any human interaction.
[0058] (2) M2M ASN: An Access Service Network that supports M2M
service.
[0059] (3) M2M device: An MS that is capable of providing M2M
communication.
[0060] (4) M2M Server: An entity that communicates with M2M
devices. The M2M server runs M2M applications and provides M2M
specific services for one or more M2M devices.
[0061] (5) M2M feature: A unique characteristic of an M2M
application. One or more features may be needed to support an
application.
[0062] (6) M2M device group: A group of M2M devices that share one
or more features in common.
[0063] M2M device group ID (MGID) and MGID Assignment
[0064] In a wireless system supporting M2M communication, a first
identifier and a second identifier are assigned to each M2M device.
The first identifier is used to identify the M2M Device Group that
the M2M device belongs to in a cell, and the second identifier is
used to uniquely identify the M2M device among devices in the M2M
Device Group.
[0065] The first identifier is referred to as M2M Device Group ID
(MGID) or Primary M2M Device ID, and the second identifier is
referred to as M2M Device ID (MDID) or Secondary M2M Device ID.
[0066] A M2M communication support system assigns MGM Group ID and
M2M Device ID to the M2M devices during the initial network entry
procedure. The M2M communication system can be the base station or
a network entity connected to the networks. The network entity can
be M2M server.
[0067] FIG. 4 is an exemplary diagram illustrating relationship
between M2M Device Group ID and M2M Device ID.
[0068] Referring to FIG. 4, M2M Device Group IDs (MGIDs) from 1 to
N are assigned to each M2M device group, and each M2M Device Group
includes M2M device IDs (MDIDs).
[0069] MGID Assignment
[0070] FIG. 5 illustrates an exemplary method for assigning an M2M
Device Group ID and an M2M Device ID to a M2M device during the
network entry procedure.
[0071] The steps S110, S121, S122, S140, S150 and S161 in FIG. 5
corresponds respectively to the steps S10, S21, S22, S40, S50 and
S61 in FIG. 3. The corresponding steps have already been described
above, thus other steps will be described with reference to FIG.
5.
[0072] During the basic capability negotiation of the initial
network entry procedure, the mobile station 100 transmits, to the
base station 200, an SBC-REQ message including information that the
mobile station 100 is an M2M device or has an M2M capability
(S130). For example, the mobile station 100 can set M2M capability
field as `1` in the SBC-REQ message.
[0073] The base station 200, which has received the SBC-REQ
including the information, notices that the mobile station 100 is
an M2M device and assigns M2M Device Group ID and M2M Device ID for
the mobile station.
[0074] The base station 200 transmits, to the mobile station 100, a
REG-RSP message including the M2M Device Group ID and the M2M
Device ID (S162).
[0075] As described above, the base station 200 notices that the
mobile station 100 is an M2M device through the M2M capability
field set as `1` in the SBC-REQ message, and assigns an M2M Device
Group ID and an M2M Device ID for the mobile station 100 via the
REG-RSP message.
[0076] FIG. 6 is a flow chart of a process for decrypting multicast
data of a mobile station.
[0077] Referring to FIG. 6, the mobile station 100, which belongs
to a certain M2M Device Group, enters into a network entry
procedure (S100) as the mobile station 100 approaches a cell of the
base station 200. After completion of the network entry (S100) and
a key derivation (S400) in FIG. 6, the mobile station 100 can
successfully decrypt the multicast data for the devices in the M2M
Device Group using the traffic encryption key generated by the key
derivation (S400).
[0078] The mobile station 100 performs the network entry procedure
(S100). The step S100 corresponds to the steps of S10 through S62
in FIG. 3, or the steps of S110 through S162 in FIG. 5.
[0079] The base station 200 can perform additional signaling with
M2M Server 300 or AAA server 400 if necessary (S200).
[0080] The base station 200 can exchange messages for device
authentication with AAA server 400 (S210).
[0081] Also, the base station 200 can obtain MAK (M2M service
Authorization Key) for the mobile station 100 (S220). The MAK is
generated by network side and is provided to all authorized M2M
devices. The MAK can be used as an authorization key for the M2M
Device Group, which works as a group master key or GMK. In some
examples, the base station can locally generate the MAK for cell
specific group security management, where the MAK is unique only
within the base station. In some examples, the base station can
request a cell common MAK from the M2M server 300 for cell common
group security management (S230), where the MAK is unique within
the entire network or multiple cells.
[0082] After the mobile station 100 is authorized and
authenticated, the mobile station can performs a group join
procedure. If the mobile station 100 is accepted to join a group,
the base station informs the device of an identifier of the M2M
Device Group, i.e. the M2M Device Group ID (MGID) (S310).
[0083] Then, the base station 200 transmits security parameters to
the mobile station 100 (S320). The security parameters are used for
generating a traffic encryption key. The security parameters
include the MAK, a group security seed and a counter.
[0084] The group security seed can be a random value generated by
network side, which can be called M2M service Group Security Seed
or MGSS and provided through DSA procedure.
[0085] Also, the counter can be an index of the currently used
traffic encryption key. The counter can be expressed as
M2MGTEK_COUNT. The counter is used as one of parameters for the key
derivation function, thus the update of the traffic encryption key
depends on the counter.
[0086] Then, the mobile station 100 performs a key derivation
function to generate the traffic encryption key based on the MGID,
the MAK, the group security seed and the counter (S410). The
traffic encryption key will be used for encrypting multicast data
to be transferred to the devices in the M2M Device Group. The
traffic encryption key can be referred as M2M service Group Traffic
Encryption Key or MGTEK. The step of performing the key derivation
function (S410) relates to the key hierarchy for the MGTEK shown in
FIG. 7. Referring to FIG. 7, the M2M Authorization Key or MAK (10)
is generated by network side and the security parameters (20) such
as MGID, MAK, MGSS and M2MGTEK_COUNT are obtained from the base
station 200. The key derivation function (30) derives the traffic
encryption key or MGTEK using the MAK, and the parameters (20). The
key derivation function (30) is one of pseudo random functions
designed to generate the same cryptographic key on both sides when
they give the same input values. The key derivation function (30)
used for the techniques described in this disclosure can be
`Dot16KDF` as shown below and in FIG. 7.
M2MGTEK<=Dot16KDF(MAK, MGSS|M2MGTEK_COUNT|MGID|"M2MGTEK",
128)[Equation 1]
[0087] Then, the mobile station 100 can acknowledge the acquisition
of the traffic encryption key towards the base station 200 (S420).
The base station 200 can check whether MGTEK is properly generated
on the mobile station side and/or on the base station side
(S430).
[0088] Then, the base station 200 can transmit multicast traffic
data encrypted using the MGTEK (S500). For any group related data
transmission, the base station 200 can use the MGTEK, which can
require additional features such as group SAID (Security
Association) ID mapping. For example, the base station 200 can
combine device specific security with Group security application
using MGTEK.
[0089] Meanwhile, the mobile station 100 receives encrypted
multicast data from the base station 200. The mobile station 100
decrypts the encrypted multicast data received from the base
station 200 using the group traffic key generated.
[0090] FIG. 8 shows a flow chart of a process for providing L2
Group Security. The steps having the same reference numeral in FIG.
8 are same as the corresponding steps in FIG. 6. Referring to FIG.
8, the base station or the mobile device does not have to take any
actions to set up the M2M Device Group security functions. All
security measures are done through L3. The base station can request
for a group formation (S240), and the AAA server 400 generates all
necessary keys (S250) and transmits via the base station.
Encryption of multicast data is also done at server side (S520).
The base station only forwards the multi-cast packets.
[0091] Updating Group Traffic Key
[0092] FIG. 9, FIG. 10 and FIG. 11 illustrate exemplary processes
for updating the group traffic key.
[0093] The traffic encryption key for a certain M2M Device Group
can be updated using one or more of the security parameters for the
key derivation function. If the base station can inform the mobile
station of which parameter(s) are changed through a trigger
message, the mobile station can derive the update traffic key
again.
[0094] Referring to FIG. 9, while the base station transmits
encrypted data using the traffic key (S500), an event which leads a
change in one or more of security parameters can happen (S610).
Then, the base station 200 transmits a trigger message including
the changed parameter(s) to the mobile station (S620).
[0095] Then, the mobile station 100 performs the key derivation
function to update the MGTEK using the parameters received through
the trigger message (S630).
[0096] After successful update of the MGTEK, the mobile station 100
can receive and decrypt the multicast data using the group traffic
key updated (S700).
[0097] Type of Event
[0098] In various examples, the event causing the change in one or
more of security parameters can be an exhaustion of PN space, an
expiry of MGTEK/MAK lifetime or a mismatch detection of EKS or
M2MGTEK_COUNT.
[0099] In one example, the changed security parameters to be
included in the trigger message include the authorization key, i.e.
MAK, which has been newly derived in the network. This event can
happen the MAK lifetime is expired. The M2MGTEK is updated either
upon the expiration of PN space or the M2MGTEK lifetime, whichever
comes first. In case the PN space expires or the M2MGTEK lifetime,
the current M2MGTEK_COUNT increments by one by which the devices
perform local derivation to generate the new M2MGTEK.
[0100] In one example, the changed security parameters to be
included in the trigger message include the group security seed,
i.e. MGSS. The group security seed can be changed when other device
is unsubscribed from the M2M Device Group where the mobile device
belongs. If a device cancels subscription from a group, a newly
generated MGSS is provided to each mobile station in the group via
the unsolicited PKM-RSP message and the base station initializes
the M2MGTEK_COUNT. The MGSS value can be encrypted within the
PKM-RSP message. The base station excludes the unsubscribed device
from such security context update. For mobile stations in connected
mode, the base station transmits the new security context via the
unsolicited PKM-RSP message. For mobile stations in idle mode, the
base station pages the entire group (i.e., MGID) via the
MOB_PAG-ADV message with `Action Code` set to 0b10. For each mobile
station that successfully performed network re-entry, the ABS
transmits an unsolicited PKM-RSP message including the new
MGSS.
[0101] In one example, the changed security parameters to be
included in the trigger message include the counter, i.e.
M2MGTEK_COUNT, which has been incremented by 1. In this example,
the traffic key update based on M2MGTEK_COUNT as seed for
generating the new updated MGTEK. The M2MGTEK_COUNT can be
transmitted clearly since MGTEK is not exposed. This event can
happen the PN space is exhausted.
[0102] In one example, the mobile station can detect whether the
traffic key has been changed or not. Referring to FIG. 11, if the
base station transmits multicast data with the updated traffic key
(S650), the mobile station detects whether the multicast data is
decrypted using the old traffic key, by checking Encryption Key
Sequence or EKS (S660). If the mobile station is not able to
decrypt multicast data (S660), the mobile station initiate a key
update request by transmitting the PKM-REQ message to the base
station (S670). The base station transmits respond with the current
MGSS and the M2MGTEK_COUNT that are in use via the PKM-RSP message
(S680). Table 1 shows PKM attributes of PKM-REQ/RSP message.
TABLE-US-00001 TABLE 1 Type PKM attribute . . . . . . 47
GKEK-Parameters 48 MIH Cycle 49 MIH Delivery Method and Status Code
53 M2M Multi-cast SADescriptor 54 M2MGTEK -Parameters 55-255
Reserved
[0103] Type of Trigger Message
[0104] Also, in various examples, the trigger message informing the
mobile station of the change in one or more of security parameters
can be a MAC message or a paging advertisement message.
[0105] In one example, if the mobile station is in the state of
connected (active), the base station can use MAC message as a
trigger message. Referring to FIG. 9, the base station transmits
multicast message to inform the updated parameters (S620 in FIG.
9). The MAC message to be used as a trigger message is not limited
thereto.
[0106] In one example, if the mobile station is in idle mode, the
base station can use Paging Advertisement message as a trigger
message. Referring to FIG. 10, the base station transmits a paging
advertisement message as a trigger message including the updated
M2MGTEK_COUNT to inform the mobile station (S620 in FIG. 10). The
paging advertisement message for informing the updated parameters
can be MOB_PAG-ADV message as shown in Table 2.
TABLE-US-00002 TABLE 2 Size Syntax (bit) Notes . . . Action Code 2
Paging action instruction to MS 0b00 = No action required 0b01 =
Perform ranging to establish location and acknowledge message 0b10
= Enter network 0b11 = Receiving Multi cast traffic If (Action Code
== 0b11) { Multi-cast security key update 1 0: no update on
multi-cast security key 1: Multi-cast security key update scheduled
Multi-cast Group ID (MGID) 15 The multi-cast group ID, which the
multi-cast traffic is scheduled for If Multi-cast security key
update=1) { M2MGTEK_COUNT TBD The change count of the M2MGTEK,
which is to be updated Update_time TBD This indicates the time
offset of when the updated M2MGTEK will be applied for multi-cast
traffic MGSS TBD Randomly generated value by BS } Multicast
transmission start time (MTST) TBD Least significant TBD bits of
the frame number in which the ABS starts sending DL multicast data.
Shall be present when the MTST needs to be included in this
message. } . . .
[0107] Direct Informing
[0108] Compare to the previously described examples, the base
station 200 can inform the mobile station 100 of the updated
traffic key (MGTEK).
[0109] Referring to FIG. 12, the base station 200 can detects
whether the traffic key or the security parameters have been
changed (S810).
[0110] The base station 200 can transmit a paging advertisement
message to inform all idle device of scheduled MGTEK update (S820).
Also, the base station 200 can set the activation time related to
the scheduled MGTEK update. The base station 200 transmits
multicast data encrypted with the original MGTEK until the
activation time (S830). The multicast data can have information on
the new MGTEK to be updated and the activation time set.
[0111] The mobile station 100 updates and uses MGTEK until the
activation time (S840), (S850). After the activation time, the base
station starts transmitting the multicast data encrypted with the
MGTEK (S860, S870).
[0112] The aforementioned embodiments are achieved by combination
of structural elements and features of the present invention in a
predetermined type. Each of the structural elements or features
should be considered selectively unless specified separately. Each
of the structural elements or features may be carried out without
being combined with other structural elements or features. Also,
some structural elements and/or features may be combined with one
another to constitute the embodiments of the present invention. The
order of operations described in the embodiments of the present
invention may be changed. Some structural elements or features of
one embodiment may be included in another embodiment, or may be
replaced with corresponding structural elements or features of
another embodiment. Moreover, it will be apparent that some claims
referring to specific claims may be combined with another claims
referring to the other claims other than the specific claims to
constitute the embodiment or add new claims by means of amendment
after the application is filed.
[0113] The embodiments of the present invention have been described
based on the data transmission and reception between the mobile
station and the base station. A specific operation which has been
described as being performed by the base station may be performed
by an upper node of the base station as the case may be. In other
words, it will be apparent that various operations performed for
communication with the user equipment in the network which includes
a plurality of network nodes along with the base station can be
performed by the base station or network nodes other than the base
station. The base station may be replaced with terms such as a
fixed station, Node B, eNode B (eNB), and access point. The mobile
station may be replaced with terms such as user equipment (UE) and
mobile subscriber station (MSS).
[0114] The embodiments according to the present invention can be
implemented by various means, for example, hardware, firmware,
software, or their combination. If the embodiment according to the
present invention is implemented by hardware, the embodiment of the
present invention can be implemented by one or more application
specific integrated circuits (ASICs), digital signal processors
(DSPs), digital signal processing devices (DSPDs), programmable
logic devices (PLDs), field programmable gate arrays (FPGAs),
processors, controllers, microcontrollers, microprocessors,
etc.
[0115] If the embodiment according to the present invention is
implemented by firmware or software, the embodiment of the present
invention can be implemented by a type of a module, a procedure, or
a function, which performs functions or operations described as
above. A software code may be stored in a memory unit and then may
be driven by a processor. The memory unit may be located inside or
outside the processor to transmit and receive data to and from the
processor through various means which are well known.
[0116] It will be apparent to those skilled in the art that the
present invention can be embodied in other specific forms without
departing from the spirit and essential characteristics of the
invention. Thus, the above embodiments are to be considered in all
respects as illustrative and not restrictive. The scope of the
invention should be determined by reasonable interpretation of the
appended claims and all change which comes within the equivalent
scope of the invention are included in the scope of the
invention.
* * * * *