1. A Machine Type Communication Inter Working Funct ion (MTC- IWF) entity comprising: control means for, in response to receiving from a Service Capabilit5 y Server (SCS) a first request for quality of service to be applied to a specific communicat ion of a Machine Type Communi cation (MTC) device, sending to a Policy and Charging Rule Function (PCRF) entity a second request for applying the quality of service to the specific communication. 10

2. The MTC- IWF ent ity according to Claim 1, wherein the first request specifies the quality of service by indicating at least one of a QoS Class Identifier (QCI), an Allocat ion and Retention Priority (ARP), a Maximum Bit Rate (MBR), a Guaranteed Bi t Rate (GBR) , and a priority level . 15

3. The MTC- IWF ent ity according to Claim 1 or 2, wherein the first request specifies the specific communication by indicating: (a) an applicat ion name; or (b) at least one of a source address, a dest ination address, a port number , and a protocol identifier for identifying a packet flow of the specific 20 communicat ion.

4. The MTC- IWF ent ity according to any one of Claims 1 to 3, wherein the first request contains an external ident ifier associated with the MTC device, 25 the control means exchanges a control message with a Home Subscriber Server (HSS) and thereby obtaining, based on the external ident ifier , an internal identifier that is associated with the MTC device and is used in a Public Land Mobile Network (PLMN), and the second request contains the internal identifier for identifying the MTC 30 device.

5. The MTC- IWF enti ty according to any one of Claims 1 to 4, wherein the control means exchanges a control message with a Diameter Routing Agent (DRA) and thereby deciding a PCRF enti ty to which the second request is to be sent . 34

6. The MTC- IWF enti ty according to any one of Claims 1 to 5, wherein the control means decides a charging polity to be applied to the specific communicat ion in response to receiving the first request. 5

7. A control method performed by a MTC Inter Working Function (MTC- IWF) entity, the control method comprising: in response to receiving from a Service Capabi lity Server (SCS) a first request for quality of service to be applied to a specific communication of a 10 Machine Type Communication (MTC) device, sending to a Policy and Charging Rule Function (PCRF) entity a second request for applying the quality of service to the specific communication.

8. A non-transi tory computer readable medium storing a program for 15 causing a computer to perform a control method re lated to a Machine Type Communication Inter Working Function (MTC- IWF), wherein the control method comprises: in response to receiving from a Service Capabi lity Server (SCS) a first request for quality of service to be applied to a specific communication of a 20 Machine Type Communication (MTC) device, sending to a Policy and Charging Rule Function (PCRF) entity a second request for applying the quality of service requested by the first request to the specific communication.

9. A Policy and Charging Rules Funct ion (PCRF) entity comprising: 25 control means for, in response to receiving from a Machine Type Communication Inter Working Function (MTC- IWF) entity a request for quality of service to be applied to a specific communication of a Machine Type Communication (MTC) device, performing control for applying the quality of service to the specific communication. 30

10. The PCRF enti ty according to Claim 9, wherein the control means controls at least one of a PCRF node having a Policy and Charging Enforcement Function (PCEF) and a TDF node having a Traffic Detection Function (TDF) in order to apply the quality of service to the specific communicat ion. 35

11. The PCRF enti ty according to Claim 10, wherein in response to receiving the request , the control means provides, to the TDF node, an Application Detection and Control (ADC) rule for detecting a specific packet flow related to the specific communicat ion from user traffic sent o5 r received by the MTC device through a bearer already set up , and in response to detection of the specific packet flow by the TDF node, the control means provides, to the PCEF node, a Policy and Charging Control (PCC) rule to be applied to the specific communication. 10

12. The PCRF enti ty according to Claim 11, wherein the ADC rule contains an application name specifying the specific communicat ion, and the PCC rule indicates at least one of a source address, a destination 15 address, a port number , and a protocol identifier of the specific packet flow, which have been detected by the TDF node for the specific packet flow based on the appl ication name.

13. The PCRF enti ty according to Claim 11 or 12, wherein the control 20 means notifies the TDF node of a period when the ADC rule is to be enforced.

14. The PCRF enti ty according to Claim 13, wherein the request contains designation of a period when the quality of service is to be applied to the specific communication, and 25 the control means not ifies the TDF node of the period when the ADC rule is to be enforced, which is determined based on the period when the quality of service is to be applied.

15. A control method performed by a Policy and Charging Rules Function 30 (PCRF) entity, the control method comprising: in response to receiving from a Machine Type Communicat ion Inter Working Funct ion (MTC- IWF) enti ty a request for quality of service to be applied to a specific communication of a Machine Type Communication (MTC) device, 36 performing control for applying the quality of service to the specific communicat ion.

16. A non-transitory computer readable medium storing a program for causing a computer to perform a control method related to a Policy and Chargin5 g Rules Function (PCRF), wherein the control method comprises: in response to receiving from a Machine Type Communicat ion Inter Working Funct ion (MTC- IWF) enti ty a request for quality of service to be applied to a specific communication of a Machine Type Communication (MTC) device, 10 performing control for applying the quality of service to the specific communicat ion.

DESCRIPTION
MTC- IWF ENTITY, PCRF ENTITY, AND COMMUNICATION METHOD
Technical Fiel5 d
[0001]
The present application relates to control of quality of services in a
wireless communication system.
Background Art
10 [0002]
The Third Generation Partnership Project (3GPP) has examined the
standardization of the Machine Type Communication (MTC). The MTC is also
referred to as a Machine-to-Machine (M2M) network or a sensor network. The
3GPP defines mobile stations (MSs, USs) implemented in machines and sensors for
15 the MTC as "MTC devices". The MTC devices are typically placed in various
types of equipment including machines (e.g., vending machines, gas meters,
electric meters, vehicles, railway vehicles) and sensors (e.g. , environmental,
agricultural, or traffic sensors). The MTC devices are connected to a Public Land
Mobile Network (PLMN) and communicate with an MTC application server (AS).
20 The MTC application server is placed outside the PLMN (i.e., placed in an external
network), executes an MTC application, and communicates with MTC UE
appl ications implemented in the MTC devices. The MTC application server is
typically controlled by an MTC service provider (M2M service provider).
[0003]
25 The 3GPP specifies network elements including a Service Capability
Server (SCS) and a Machine Type Communication Inter Working Function
(MTC- IWF), reference points, and procedures to allow the MTC application server
to communicate with the MTC devi ces (see Non-patent literature 1). The reference
points are also referred to as "interfaces".
30 [0004]
The SCS is an entity to connect the MTC application server to the 3GPP
PLMN and to allow the MTC application server to communicate with a UE (i.e.,
MTC device) through PLMN services defined by the 3GPP. Further, the SCS
allows the MTC application server to communicate with the MTC- IWF. The SCS
3
is assumed to be controlled by an operator of the PLMN or the MTC service
provider.
[0005]
The MTC- IWF is a cont rol-plane entity that belongs to the PLMN. The
MTC- IWF has a signaling interface (reference point) wi th the SCS and ha5 s
signaling interfaces (reference points) with nodes in the PLMN (e.g., Home
Subscriber Server (HSS), a Short Message Service -Service Center (SMS-SC), a
Serving GPRS Support Node (SGSN), a Mobility Management Entity (MME), and
a Mobile Switching Center (MSC)). The MTC-IWF serves as a control -plane
10 interface to allow the 3GPP PLMN and the M2M service layer including the SCS to
interwork with each other while hiding the details of the topology of the 3GPP
PLMN.
[0006]
Non Patent Literature 2 discloses in Sect ion 7.4.2 the PCRF init iated
15 IP-CAN Session Modification procedure. In one example, a Policy and Charging
Rules Function (PCRF) ini tiates an IP-CAN Session Modification procedure in
response to the detect ion of application traffic (e.g. , streaming video service, VoIP
service, P2P file sharing service, specific HTTP traffic) by a Traffic Detection
Function (TDF). In another example , the PCRF initiates the IP-CAN Session
20 Modification procedure in response to service information (e.g., a change in
priority level) provided or revoked by an Application Function (AF). Non Patent
Li terature 3 discloses in Section 4.3.1 the IP-CAN Session Modification procedure,
which is like the one disclosed in Non Patent Literature 2.
Citation List
25 Non Patent Literature
[0007]
[Non Patent Literature 1] 3GPP TS 23.682 V11.5.0 (2013-09) “3rd Generation
Partnership Project; Technical Specification Group Services and System Aspects;
Architecture enhancements to facilitate communicat ions with packet data networks
30 and applications (Release 11) ”, September 2013
[Non Patent Literature 2] 3GPP TS 23.203 V11.11.0 (2013-09) “3rd Generation
Partnership Project; Technical Specification Group Services and System Aspects;
Policy and charging control architecture (Release 11)”, September 2013
4
[Non Patent Literature 3] 3GPP TS 29.213 V11.8.0 (2013-09) “3rd Generation
Partnership Project; Technical Specification Group Core Network and Terminals;
Policy and Charging Control signaling flows and Qual ity of Service (QoS)
parameter mapping (Release 11)”, September 2013
Summary of Inventio5 n
Technical Problem
[0008]
The present inventor has examined various use cases of the MTC
appl ication. For example, it is contemplated that a Publ ic Land Mobile Network
10 (PLMN) dynamically adjust s the quality of service of a specific communication
(service data flow) regarding a UE (MTC device), such as a QoS policy (e.g. , QoS
Class Identifier (QCI), Allocation and Retention Priority (ARP), Maximum Bit
Rate (MBR), Guaranteed Bit Rate (GBR)), in response to a request by an MTC
appl ication server. In order to implement this use case, for example, it may be
15 preferable that the MTC- IWF is able to request a network element in the PLMN to
control the quality of service (QoS control) of a specific communication, in
response to receiving from the SCS a request for the quality of service. However,
Non Patent Literatures 1 to 3 fail to teach such control operat ion or control
procedure.
20 [0009]
In view of the above, one object of embodiments disclosed in this
specification is to provide an MTC-IWF enti ty, a PCRF entity, a control method
and a program for facilitating controlling quality of service of a specific
communicat ion in a PLMN in response to a request by an SCS for the quality of
25 service. The other objects or problems and novel features will bec ome apparent
from the description of the specification or the accompanying drawings.
Solution to Problem
[0010]
In one aspect, an MTC-IWF enti ty includes a control unit . The control
30 unit is configured to, in response to receiving from an SCS a first request for
qual ity of service to be applied to a specific communication of an MTC device,
send to a PCRF entity a second request for applying the quality of service to the
specific communication.
[0011]
5
In one aspect, a method performed by an MTC- IWF entity includes, in
response to receiving from an SCS a first request for quality of service to be
appl ied to a specific communicat ion of an MTC device, sending to a PCRF ent ity a
second request for applying the quality of service to the specific communication.
[00125 ]
In one aspect, a program contains instruct ions for causing a computer to
execute the method performed by an MTC-IWF entity described in the immediately
above paragraph.
[0013]
10 In one aspect, a PCRF enti ty includes a control unit. The control unit is
configured to, in response to receiving from an MTC- IWF entity a request for
qual ity of service to be applied to a specific communication of an MTC device,
perform control for applying the quality of service to the specific communication.
[0014]
15 In one aspect, a method performed by a PCRF ent ity includes, in response
to receiving from an MTC- IWF entity a request for quality of service to be applied
to a specific communication of an MTC device, performing control for applying
the quality of service to the specific communication.
[0015]
20 In one aspect, a program contains instruct ions for causing a compute r to
execute the method performed by a PCRF entity described in the immediately
above paragraph.
[0016]
In one aspect, a PCRF enti ty includes a control unit. The control unit is
25 configured to, in response to detection of a specific packet flow from user traffic
sent or received by a mobile station through a bearer already set up, provides, to a
PCRF node having a Policy and Charging Enforcement Function (PCEF) , a first
Policy and Charging Control (PCC) rule to be applied to the specific packet flow.
In one example, the mobile station may be an MTC device. In this case, the
30 control unit may provide the first PCC rule to the PCEF node in response to
receiving from an MTC- IWF entity a request for quality of service to be applied to
a specific communication of the MTC device.
[0017]
6
In one aspect, a method performed by a PCRF ent ity includes, in response
to detection of a specific packet flow from user traffic sent or received by a mobile
station through a bearer already set up, providing, to a PCRF node having a Policy
and Charging Enforcement Function (PCEF) , a first Policy and Charging Control
(PCC) rule to be appl ied to the specific packet flow. In one example, the mobil5 e
station may be an MTC device. In this case, the providing may include providing
the first PCC rule to the PCEF node in response to receiving from an MTC- IWF
entity a request for quality of service to be appl ied to a specific communication of
the MTC device.
10 [0018]
In one aspect, a program contains instruct ions for causing a computer to
execute the method performed by a PCRF entity described in the immediately
above paragraph.
Advantageous Effects of Invention
15 [0019]
According to the aspects described above, it is possible to provide an
MTC- IWF entity, a PCRF ent ity, a control method and a program for faci litating
control ling quality of service of a specific communicat ion in a PLMN in response
to a request by an SCS for the quality of service.
20 Brief Description of Drawings
[0020]
Fig. 1 is a diagram showing a wireless communication system according to
first and second embodiments.
Fig. 2 is a sequence diagram showing one example of control of quality of
25 service according to the first embodiment .
Fig. 3 is a sequence diagram showing one example of control of quality of
service according to the second embodiment.
Fig. 4 is a block diagram showing a configuration example of several
entities or nodes according to the second embodiment.
30 Fig. 5 is a diagram showing a wireless communication system according to
another embodiment 2.
Fig. 6 is a sequence diagram showing one example of an operation
according to another embodiment 2.
Description of Embodiments
7
[0021]
Specific embodiments will be explained hereinafter in detail with
reference to the drawings. The same symbols are assigned to the same or
corresponding elements throughout the drawings, and repetitive explanations will
be omitted as necessary5 .
[0022]
First embodiment
Fig. 1 is a diagram showing a configuration example of a wireless
communicat ion system according to this embodiment . The wireless
10 communicat ion system according to this embodiment is, for example, a 3GPP
wireless communication system (EPS). The EPS is also referred to as a Long
Term Evolution (LTE) system. Hereinafter , the case where the wireless
communicat ion system according to this embodiment is the EPS is described by
way of illustration. Note that , however, this embodiment is also applicable to
15 another wireless communication system such as Universal Mobi le
Telecommunicat ions System (UMTS).
[0023]
A UE 3 executes an MTC UE appl ication 31 and serves as an MTC device.
The UE 3 as an MTC device is connected to an MME 53 through a Radio Access
20 Network (RAN) 54 and communicates with an MTC appl ication server 4. The
RAN 54 includes an Evolved UMTS Terrestrial Radio Access Network
(E-UTRAN).
[0024]
The UE 3 may be an MTC gateway device. The MTC gateway device has
25 a 3GPP mobile communication function (i.e., functions of a UE) and is connected
to an adjacent device (e.g., a sensor, a radio frequency ident ification (RFID) tag, a
car navigation device) by a personal/local area connection technology. Specific
examples of the personal /local area connection technology include IEEE 802.15,
ZigBee (registered trademark) , Bluetooth (registered trademark) , and IEEE
30 802.11a. The adjacent device, which is connected to the MTC gateway device, is
typically a device that does not have the 3GPP mobile communication function, but
may be a device that has the 3GPP mobile communicat ion funct ion (i.e., an MTC
device).
[0025]
8
In this specification, the term "MTC device" and the term "MTC gateway
device" are not particularly distinguished from each other. Accordingly, the term
"MTC device" used in this specification includes the MTC gateway device.
Therefore, the UE 3 as the MTC device also means the UE 3 as the MTC gateway
device5 .
[0026]
An MTC Inter Working Function (MTC- IWF) entity 1 is a control -plane
entity that belongs to the PLMN. The MTC- IWF entity 1 communicates with
other network elements through signaling interfaces (reference points). The
10 MTC- IWF entity 1 serves as a control -plane interface or gateway to allow a 3GPP
PLMN and an M2M service layer including an SCS 2 to interwork with each other
while hiding the details of the topology of the 3GPP PLMN. Hereinafter, the
signaling interfaces (reference points) of the MTC-IWF enti ty 1 and the other
network elements are described.
15 [0027]
The MTC- IWF entity 1 communicates with a Service Capabili ty Server
(SCS) 2 through a Tsp reference point. The SCS 2 connects the MTC appl ication
server 4 to the PLMN and allows the MTC appl ication server 4 to communicate
with the UE 3 (i .e., MTC device) through PLMN services defined by the 3GPP.
20 The MTC application server 4 is also referred to as an M2M application server.
Further, the SCS 2 al lows the MTC application server 4 to communicate with the
MTC- IWF entity 1. The SCS 2 is controlled by an operator of the PLMN or by an
MTC service provider. The SCS 2 is also referred to as an MTC server or an
M2M server. The SCS 2 may be a single, stand-alone physical ent ity or may be a
25 functional entity added to another network element (e.g., MTC application server
4). The Tsp reference point is used, for example, to send a device trigger
transmission request (Device Trigger Request (DTR)) from the SCS 2 to the
MTC- IWF entity 1 and to report a device trigger result from the MTC- IWF entity 1
to the SCS 2.
30 [0028]
The MTC- IWF entity 1 communicates with a Home Subscriber Server
(HSS) 51 through an S6m reference point. The HSS 51 is a control -plane node
placed in a core network of the PLMN ( i .e., Evolved Packet Core (EPC) in the
EPS) and manages subscriber information of the UE 3. The S6m reference point
9
is used, for example, to send an inquiry as to the subscriber information from the
MTC- IWF entity 1 to the HSS 51 and to send the subscriber information from the
HSS 51 to the MTC- IWF entity 1.
[0029]
The MTC- IWF entity 1 communicates with a Mobility Management Enti 5 ty
(MME) 53 through a T5b reference point . The MME 53 is a core network node of
the EPS and performs mobility management (e.g., posit ion registration) of the UE
3, bearer management (e.g., bearer establishment, bearer configuration
modification, and bearer release) , and the l ike. The MME 53 sends and receives
10 control messages to and from a node (i.e., eNodeB) in the RAN 54, and sends and
receives NAS messages to and from the UE 3. The NAS messages are not
terminated at the RAN 54 and transparently transmitted and received between the
UE 3 and the MME 53 without depending on the radio access technology used in of
the RAN.
15 [0030]
The above-described Tsp, S6m, and T5b reference points are defined in
Non Patent Literature 1. However, Non Patent Literature 1 does not define
reference points between the MTC-IWF entity 1 and a PCRF ent ity 5, and between
the MTC-IWF ent ity 1 and a Diameter Routing Agent (DRA) 52.
20 [0031]
A Policy and Charging Rules Function (PCRF) entity 5 is a control -plane
entity that is placed in a core network (i .e. , EPC) of the EPS. The PCRF entity 5
determines a Policy and Charging Control (PCC) rule to be appl ied to a service
data flow of the UE 3 and sends the determined PCC rule to a P-GW 56 having a
25 Policy and Charging Enforcement Function (PCEF). The PCC rule contains a
QoS policy to be applied to a service data flow of the UE 3, a charging rule, and a
service data flow (SDF) template for detect ing the service data flow. Further, the
PCRF enti ty 5 provides an Applicat ion Detection and Control (ADC) rule to a
Traffic Detection Function (TDF) entity 57. The ADC rule is used in the TDF
30 entity 57 in order to detect specific application traffic (e.g., streaming video
service, VoIP service, P2P file sharing service, specific HTTP traffic) from user
data traffic sent or received by the UE 3. The ADC rule contains identification
information of Layers 4-7 of the OSI reference model which is required for
identifying the application traffic.
10
[0032]
The PCRF entity 5 has a signaling interface (i.e., Gx reference point) with
the Policy and Charging Enforcement Function (PCEF) placed in the P-GW 56.
The PCRF entity 5 has a signaling interface (i.e., Sd reference point) wi th the
Traffic Detection Function (TDF) entity 57. Further, the PCRF enti ty 5 has 5 a
signaling interface (i .e., Gxc reference point) with a Bearer Binding and Event
Reporting Function (BBERF) placed in an S-GW 55.
[0033]
Further, the PCRF entity 5 has a signaling interface 11 with the MTC- IWF
10 entity 1. The signal ing interface 11 may be an Rx reference point. The Rx
reference point is an interface between the PCRF and an Application Function
(AF). In this case, the PCRF entity 5 may receive application-level service
information from the MTC- IWF entity 1, determine a PCC rule, and provide the
PCC rule to the P-GW 56.
15 [0034]
A Diameter Routing Agent (DRA) 52 is a control -plane entity that is
placed in a core network (EPC) of the EPS. The DRA 52 makes it possible to
place a plurality of PCRF ent ities in the core network (EPC). Specifically, the
DRA 52 associates a subscriber (UE 3) using the PLMN wi th a PCRF enti ty that
20 performs QoS control and charging control on an IP-CAN session of the subscriber.
The details of the function of the DRA are described in the 3GPP TS 29.213 and
the IETF RFC 3588.
[0035]
The DRA 52 may be implemented as a Redirect DRA or as a Proxy DRA.
25 When the DRA 52 is implemented as a Redirect DRA, in response to receiving a
Diameter request message from a client (e.g., Application Funct ion (AF), t he
S-GW 55 as BBERF, the P-GW 56 as PCEF, and the MTC- IWF entity 1), the DRA
52 sends a Diameter Attribute-value pair (Diameter AVP) back to the client . The
Diameter AVP (i.e. , Redirect -Host -Usage AVP) sent from the DRA 52 indicates a
30 PCRF entity to which the client should send the Diameter request message. When
the DRA 52 is implemented as a Proxy DRA, in response to receiving a Diameter
request message from a client (e.g., Application Function (AF), the S -GW 55 as
BBERF, the P-GW 56 as PCEF, and the MTC- IWF entity 1), the DRA 52 transfers
the received Diameter request message to an appropriate PCRF entity.
11
[0036]
Note that , when there is only one MTC- IWF enti ty 1 in the PLMN, or when
the MTC-IWF ent ity 1 knows in advance the PCRF entity 5 that manages the
IP-CAN session of the UE 3 as an MTC device, for example, a signaling interface
12 between the MTC-IWF entity 1 and the DRA 52 may be omit ted. In othe5 r
words, the MTC- IWF entity 1 does not necessarily perform signaling with the DRA
52.
[0037]
A Serving Gateway (S-GW) 55 is a user-plane packet -transfer node placed
10 in a core network of the EPS, and it transfers user data packet s of the UE 3. The
S-GW 55 serves as a gateway to the RAN 54. The S-GW 55 has a user-plane
tunneling interface (i .e. , S1-U reference point) wi th the RAN 54 (i .e., E-UTRAN)
and has a user-pale tunneling interface (i.e., S5/S8 reference point) wi th the P-GW
56. The S-GW 55 has a signaling interface (i .e., S11 reference point) with the
15 MME 53.
[0038]
Further, the S-GW 55 may have a Bearer Binding and Event Reporting
Function (BBERF). The S-GW 55 serving as a BBERF receives a QoS rule from
the PCRF entity 5, detects a service data flow (i.e. , IP packet flow) of the UE 3,
20 which is to be control led based on the QoS rule, and associates the detected service
data flow with an appropriate IP-CAN bearer (EPS bearer) corresponding to the
QoS rule. Further, the S-GW 55 serving as a BBERF reports an event to the
PCRF enti ty 5 based on an event trigger installed by the PCRF entity 5.
[0039]
25 A Packet Data Network Gateway (P-GW) 56 is a user-plane packet-transfer
node that is placed in a core network (EPC) of the EPS and transfers user data
packets of the UE 3. The P-GW 56 serves as a gateway to an external Packet Data
Network (PDN) and provides the UE 3 wi th connectivi ty to the external PDN.
The external PDN includes the SCS 2 and the MTC application server 4, for
30 example. Further, the P-GW 56 has a Charging Trigger Function (CTF), a
Charging Data Function (CDF) , and a Policy and Charging Enforcement Function
(PCEF). The P-GW 56 serving as the PCEF performs Quality of Service (QoS)
control and Flow based Bearer Charging (FBC) per service data flow (i.e., IP
packet flow) of the UE 3 in accordance with a Policy and Charging Control (PCC)
12
rule supplied from the PCRF enti ty 5. The FBC is implemented by the CTF, the
CDF, and the PCEF of the P-GW 56.
[0040]
In other words, the P-GW 56 differentiates a plurality of service data flows
sent or received by the UE 3 using an SDF template or a Traffic Flow Templat5 e
(TFT) and maps each service data flow to an EPS bearer (IP Connectivity Access
Network ( IP-CAN) bearer) corresponding to the QoS of the service data flow.
Further, the P-GW 56 monitors a service data flow as a chargeable event that
triggers the generation and close of a Charging Data Record (CDR), counts the
10 number of packets in the service data flow, and generates the CDR containing the
charging information related to the service data flow. Note that the chargeable
event is an activity that uses resources or services served by a communicat ion
network. The chargeable event is , for example, user to user communication (e.g.,
a single call, a data communication session or a short message), user to network
15 communicat ion (e.g., service profile administration)), inter -network
communicat ion (e.g., transferring cal ls, signal ing, or short messages), or mobility
(e.g. , roaming or inter -system handover). The CDR is formatted charging
information (e.g. , a call time, a data transfer amount etc.).
[0041]
20 A Traffic Detection Funct ion (TDF) ent ity 57 has a deep packet inspect ion
(DPI) function. The TDF entity 57 receives an Application Detection and Control
(ADC) rule from the PCRF enti ty 5 through a Sd reference point, performs deep
packet inspection on user packet s in accordance with the ADC rule, and detects an
appl ication traffic (e.g., streaming video service, VoIP service, P 2P file sharing
25 service, specific HTTP traffic) specified by the ADC rule. Then, the TDF ent ity
57 reports to the PCRF enti ty 5 the detection result of the application traffic
through the Sd reference point . The function of the TDF entity 57 may collocate
with a PCEF. In other words, the TDF entity 57 may be placed in the P-GW 56.
In still other words, the P-GW 56 may have a PCEF enhanced with ADC.
30 [0042]
Hereinafter, control of service qual ity of a specific communication of the
UE 3 is described. In the example of Fig. 1, the MTC- IWF ent ity 1 has a
signaling interface (reference point) 11 wi th the PCRF entity 5. In response to
receiving a first QoS request from the SCS 2 through a Tsp reference point, the
13
MTC- IWF entity 1 sends a second QoS request to the PCRF enti ty 5 through the
signaling interface 11.
[0043]
The first QoS request , which is sent from the SCS 2 to the MTC-IWF
entity 1, requests quality of service to be applied to a specific communication o5 f
the UE 3 as an MTC device. The specific communication of the UE 3 may be
communicat ion with a specific system, communicat ion on a specific protocol, or
traffic of a specific application. In other words, the specific communication of
the UE 3 may be specified by any one or combination of identification information
10 on Layer 3-7 of the OSI reference model .
[0044]
In order to specify the qual ity of service, the first QoS request may
indicate at least one of a QoS Class Identifier (QCI), an Al location and Retention
Priority (ARP), a Maximum Bit Rate (MBR), Guaranteed Bit Rate (GBR), and a
15 priority level (e.g., high priority, medium priority, and low priority). Further, the
first QoS request may contain an application name (e.g. , YouTube (registered
trademark), Skype (registered trademark)) in order to specify the specific
communicat ion of the UE 3. Further, the first QoS request may contain at least
one of a source address, a dest ination address, a port number , and a protocol
20 identifier for ident ifying a packet flow of the specific communication of the UE 3.
Furthermore, the first QoS request may indicate intended use (e.g., background
communicat ion, automatic software update, automatic meter reading) of the
specific communication.
[0045]
25 The first QoS request may contain an external identifier (external ID)
associated with the UE 3 in order to specify the target UE 3. The external ID is
used to identify the UE 3 outside the PLMN containing the SCS 2 and the MTC
appl ication server 4. The external ID may be, for example, a Mobile Subscriber
ISDN Number (MSISDN).
30 [0046]
The first QoS request may contain an ident ifier of the SCS 2 in order to
indicate the sender SCS 2. Further, the first QoS request may contain a
transact ion identifier (e.g., sequence number) in order to dis tinguish among a
plurality of first QoS requests sent from the SCS 2.
14
[0047]
The second QoS request , which is sent from the MTC- IWF enti ty 1 to the
PCRF enti ty 5, may indicate information similar to the informat ion contained in
the first QoS request in order to specify the qual ity of service. Specifically, the
second QoS request may indicate at least one of a QCI, an ARP, a MBR, a GBR5 ,
and a priority level . Further, the second QoS request may contain at least one of
a source address, a destination address, a port number , and a protocol identifier for
identifying a packet flow of the specific communicat ion of the UE 3.
Furthermore, the second QoS request may indicate intended use of the specific
10 communicat ion.
[0048]
The second QoS request may contain an internal ident ifier (internal ID)
associated with the UE 3 in order to specify the target UE 3. The internal ID is
used to identify the UE 3 inside the PLMN. The internal ID may be, for example,
15 an International Mobile Subscriber Ident ity ( IMSI). The MTC-IWF enti ty 1 may
obtain the internal ID of the UE 3 by asking the HSS 51 about the internal ID
corresponding to the external ID of the UE 3.
[0049]
In the case where a plurality of PCRF enti ties 5 are placed in the PLMN,
20 the MTC-IWF ent ity 1 needs to select the PCRF enti ty 5 that manages service
flows of the UE 3 from the plurality of PCRF ent ities 5. Thus, the MTC- IWF
entity 5 may exchange control messages with the DRA 52 and thereby obtaining an
address of an appropriate PCRF entity 5 from the DRA 52.
[0050]
25 The PCRF entity 5 performs the control for applying the quality of service
requested by the second QoS request to the specific communicat ion of the UE 3 in
response to receiving the second QoS request from the MTC- IWF enti ty 1. In
order to apply the quality of service requested by the second QoS request to the
specific communication of the UE 3, the PCRF ent ity 5 may control at least one of
30 the P-GW 56 serving as a PCEF and the entity 57 serving as a TDF.
[0051]
To be specific, the PCRF ent ity 5 may generate a PCC rule based on the
qual ity of service indicated by the second QoS request, the identifier of the UE 3,
and the identification information (e.g. , an application name, a source address, a
15
port number, or a protocol ident ifier, or any combination of those) of the specific
communicat ion and provide the generated PCC rule to the P-GW 56. The
provision of the PCC rule to the P-GW 56 triggers the modificat ion of an IP-CAN
session regarding the UE 3. For example, the modification of the IP-CAN session
includes updat ing of the QoS of the IP-CAN bearer (EPS bearer) that has alread5 y
been set up, or includes updat ing of the SDF template or the Traffic Flow Template
(TFT). Further, when the QoS policy to be applied to the service data flow (IP
packet flow) of the specific communication of the UE 3 is different from the QoS
policy of the EPS bearer that has already been set up, the modification of the
10 IP-CAN bearer may include generation of a new dedicated EPS bearer for
transferring the service data flow of the specific communication of the UE 3.
[0052]
Further, the PCRF entity 5 may generate an ADC rule based on the
identification information (e.g., application name) of the specific communication
15 indicated by the second QoS request and provide the generated PCC rule to the
TDF enti ty 57. Then, in response to detection of a packet flow of the specific
communicat ion from user traffic sent or received by the UE 3 through the EPS
bearer that has already been set up, the PCRF ent ity 5 may generate a PCC rule to
be applied to the packet flow of the specific communication. For example, when
20 the specific communication of the UE 3 is specified by informat ion on Layers 5-7
(e.g. , application name) of the OSI reference model in the second QoS request , the
PCRF enti ty 5 cannot generate a sufficient PCC rule only from the information
contained in the second QoS request in some cases. This is because information
about Layers 3 and 4 required for a PCC rule (to be specific, SDF template or TFT)
25 such as an IP address of a node with which the UE 3 communicates is not known.
Accordingly, the PCRF ent ity 5 may detect traffic of the specific communication
(i.e., traffic of the specific application) from the user data flow of the UE 3 by
means of the deep packet inspection (DPI) function in the TDF entity 57. The
PCRF enti ty 5 thus obtains information required for determining a PCC rule, which
30 is information on Layers 3 and 4 such as an IP address of a node with which the UE
3 communicates and a port number .
[0053]
Fig. 2 is a sequence diagram showing one example of Quality of Service
control (QoS control) for the UE 3 based on a request from the SCS 2. In Step
16
S101, the SCS 2 sends a first QoS request to the MTC- IWF enti ty 1 through the
Tsp reference point . The first QoS request contains an external ID of the UE 3
for ident ifying the UE 3, for which the control is to be performed. Further, the
first QoS request contains information for identifying a specific communication of
the UE 3, which includes, for example, an application name, a port number, or a5 n
IP address of a node with which the UE 3 communicates, or any combination of
those. Furthermore, the first QoS request indicates information for identifying
the required quality of service, which includes, for example, a QCI, an ARP, a
MBR, a GBR, or a priority level, or any combination of those.
10 [0054]
In Step S102, in response to receiving the first QoS request from the SCS 2,
the MTC-IWF ent ity 1 asks the HSS 1 about an internal ID corresponding to the
external ID of the UE 3 indicated by the first QoS request . The MTC- IWF entity
1 may request the HSS 51 to send subscriber information corresponding to the
15 external ID of the UE 3. Note that, when the MTC-IWF ent ity 1 already knows
the internal ID of the UE 3, Step S102 can be skipped.
[0055]
In Step S103, the MTC-IWF entity 1 asks the DRA 52 about a PCRF enti ty
5 that manages the IP-CAN session of the UE 3. The MTC-IWF enti ty 1 may
20 request the DRA 52 to send an address of the PCRF entity 5 that manages the
IP-CAN session of the UE 3. Note that, when there is only one PCRF enti ty 5
placed in the PLMN or the MTC- IWF enti ty 1 already knows the PCRF enti ty 5
that manages the UE 3 as an MTC device, Step S103 can be skipped.
[0056]
25 In Step S104, the MTC-IWF enti ty 1 sends a second QoS request to the
PCRF enti ty 5 through the signaling interface 11. In the example of Fig. 2, the
second QoS request contains the internal ID of the UE 3 for identifying the UE 3,
for which control is to be performed. Further, the second QoS request contains
information for ident ifying the specific communicat ion of the UE 3, which
30 includes, for example, an appl ication name, a port number, or an IP address of a
node with which the UE3 communicates, or any combination of those.
Furthermore, the second QoS request indicates information for identifying the
required quality of service, which includes, for example, a QCI, an ARP, a MBR, a
GBR, or a priority level, or any combination of those.
17
[0057]
In Step S105, in response to receiving the second QoS request from the
MTC- IWF entity 1, the PCRF entity 5 determines a PCC rule to be appl ied to the
specific communication of the UE 3. This PCC rule contains an SDF template
(i.e., packet filter) for ident ifying a packet flow related to the specifi5 c
communicat ion of the UE 3 and also contains information for QoS control (e.g. ,
QCI, ARP, MBR, GBR). Further, the PCC rule may contain informat ion for
charging control (e.g. , Charging key, Charging method, Measurement method) on
the specific communication of the UE 3. In Step S106, the PCRF ent ity 5 sends
10 the determined PCC rule to the P-GW 56 (PCEF) in order to enforce the
determined PCC rule on the specific communication of the UE 3.
[0058]
In Step S107, the P-GW 56 serving as a PCEF receives the PCC rule and
then applies it to the communicat ion of the UE 3. To be specific, the P-GW 56
15 initiates an IP-CAN Session Modification procedure in response to receiving the
PCC rule. As described earlier, the modification of the IP-CAN session may
include updating of the QoS of the IP-CAN bearer (EPS bearer) that has already
been set up, or include updat ing of the SDF template or the Traffic Flow Template
(TFT), for example. Further, when the QoS policy to be applied to the service
20 data flow (IP packet flow) related to the specific communication of the UE 3 is
different from the QoS policy of the EPS bearer that has already been set up, the
modification of the IP-CAN bearer may include generat ion of a new dedicated EPS
bearer for transferring the service data flow of the specific communication of the
UE 3.
25 [0059]
As is understood from the above description, in this embodiment, the
MTC- IWF entity 1 and the PCRF entity 5 operate to adjust quality of service (QoS)
of a specific communication (e.g., specific application traffic) of the UE 3 based
on a request by the SCS 2 for the quality of service (QoS). Thus, according to
30 this embodiment, it is possible to facilitate controlling the quali ty of service of the
specific communication of the UE 3 in the PLMN in response to the request by the
SCS 2 for the quality of service.
[0060]
Second embodiment
18
In this embodiment, another specific example of Quality of Service control
(QoS control) for the UE 3 based on a request from the SCS 2 is described. A
configuration example of the wireless communication system according to this
embodiment is the same as the one shown in Fig. 1.
[00615 ]
Fig. 3 is a sequence diagram showing one example of Quality of Service
control (QoS control) for the UE 3 based on a request from the SCS 2. In the
example of Fig. 3, the first QoS request , which is sent from the SCS 2, and the
second QoS request , which is sent from the MTC- IWF entity 1, identify a specific
10 communicat ion of the UE 3 by means of information on Layers 5-7 (e.g.,
appl ication name) of the OSI reference model . Accordingly, in order to detect
traffic of the specific communication (i.e., traffic of a specific appl ication) from
the user data flow of the UE 3, the PCRF entity 5 uses the deep packet inspection
(DPI) function in the TDF enti ty 57. The PCRF enti ty 5 thus obtains information
15 required for determining a PCC rule, which is information on Layers 3 and 4 (e.g.,
an IP address of a node with which the UE 3 communicates and a port number)
related to the specific communication of the UE 3.
[0062]
In Step S201, the SCS 2 sends a first QoS request to the MTC-IWF ent ity 1
20 through the Tsp reference point. The first QoS request contains informat ion on
Layers 5-7 (e.g., appl ication name) for identifying a specific communicat ion of the
UE 3. Further, like the one described above with respect to Fig. 2, the first QoS
request may contain an external ID of the UE 3 and information for identifying the
required qual ity of service (e.g., QCI, ARP, MBR, GBR or priority level).
25 [0063]
In Step S202, the MTC-IWF enti ty 1 sends a second QoS request to the
PCRF enti ty 5 through the signaling interface 11. The second QoS request
contains information on Layers 5-7 (e.g., application name) for identifying the
specific communication of the UE 3. Further, as the one described above with
30 respect to Fig. 2, the second QoS request may contain an internal ID of the UE 3
and information for ident ifying the required quality of service (e.g. , QCI, ARP,
MBR, GBR or priority level). Further, prior to Step S202, an inquiry to the HSS
51 and an inquiry to the DRA 52 (Steps S102 and S103 in Fig. 2) may be made.
[0064]
19
In Step S203, in response to receiving the second QoS request, the PCRF
entity 5 determines an ADC rule to be used for detecting traffic of the specific
communicat ion (i .e., traffic of a specific application) from the user data flow of
the UE 3. This ADC rule contains an identifier (e.g. , IP address) of the target UE
3 and an identifier (e.g., application name) of an application to be detected. I5 n
Step S204, the PCRF entity 5 provides the determined ADC rule to the TDF entity
57.
[0065]
In Step S205, the TDF entity 57 starts DPI on the user data flow of the UE
10 3 in order to detect specific application traffic in accordance with the received
ADC rule. Then, in Step S206, in response to detect ion of the specific
appl ication traffic, the TDF entity 57 sends a detection report to the PCRF entity 5.
The detection report contains information on Layers 3 and 4 (e.g., an IP address of
a node with which the UE 3 communicates and a port number) related to the
15 specific application traffic.
[0066]
In Step S207, the PCRF enti ty 5 determines a PCC rule to be applied to the
specific communication of the UE 3 based on the detection report from the TDF
entity 57. This PCC rule contains an SDF template (i .e., packet filter) for
20 identifying a packet flow related to the specific communication of t he UE 3 and
information for QoS control (e.g., QCI, ARP, MBR, GBR). Further, the PCC rule
may contain informat ion for charging control (e.g., Charging key, Charging
method, Measurement method) on the specific communication of the UE 3. In
Step S208, the PCRF entity 5 sends the determined PCC rule to the P-GW 56
25 (PCEF) in order to enforce the determined PCC rule on the specific communication
of the UE 3.
[0067]
In Step S209 the P-GW 56 serving as a PCEF receives the PCC rule and
appl ies it to the communication of the UE 3. To be specific, the P-GW 56
30 initiates an IP-CAN Session Modification procedure in response to receiving the
PCC rule.
[0068]
Fig. 4 is a block diagram showing a configuration ex ample of the
MTC- IWF entity 1, the PCRF entity 5, the P-GW 56, and the TDF entity 57
20
according to this embodiment. In the example of Fig. 4, the MTC- IWF entity 1
includes a control uni t 101. The control unit 101 is configured to send the second
QoS request to the PCRF ent ity 5 in response to receiving the first QoS request
from the SCS 2.
[00695 ]
In the example of Fig. 4, the PCRF ent ity 5 includes a control unit 501.
The control unit 501 is configured to, in response to receiving the second QoS
request , determine an ADC rule for detect ing specific application traffic of the UE
3 and provide the determined ADC rule to the TDF entity 57. The control unit
10 501 is further configured to receive a detection report related to the specific
appl ication traffic of the UE 3 from the TDF entity 57 , determine a PCC rule to be
appl ied to the specific appl ication traffic of the UE 3, and provide the determined
PCC rule to the P-GW 56.
[0070]
15 In the example of Fig. 4, the TDF enti ty 57 includes a signaling unit 571
and a detect ion unit 572. The signaling unit 571 is configured to receive an ADC
rule from the PCRF entity 5 (control unit 501) and send a detection report related
to the application traffic detected based on the ADC rule. The detection uni t 572
is configured to perform DPI on the user data traffic of the UE 3 in order to detect
20 the application traffic specified by the ADC rule.
[0071]
In the example of Fig. 4, the P-GW 56 includes a signaling unit 561 and a
packet processing uni t 562. The signaling unit 561 is configured to receive a
PCC rule from the PCRF ent ity 5 (control unit 501). The packet processing unit
25 562 is configured to apply the service data flow and the QoS policy specified by
the PCC rule to the IP-CAN bearer (EPS bearer). Specifically, the packet
processing unit 562 is configured to modify the QoS policy of the dedicated bearer
with the UE 3, modify the SDF template and the TFT applied to the dedicated
bearer for the UE 3, or set up a new dedicated EPS bearer for the UE 3.
30 [0072]
According to this embodiment , the SCS 2 can specify the specific
communicat ion of the UE 3, to which the QoS request is targeted, by information
on Layers 5-7 of the OSI reference model in the first QoS request. For example,
the specific communication of the UE 3, to which the QoS request is targeted, may
21
be specified by an application name (e.g., YouTube (registered trademark), Skype
(registered trademark)) in the first QoS request. In another example, the specific
communicat ion of the UE 3 may be specified by its intended use (e.g. , background
communicat ion, automatic software update, automatic meter reading) in the first
QoS request . Thus, when the SCS 2 sends a QoS request to the PLMN (MTC- IW5 F
entity 1), it is possible to flexibly specify the specific communication of the UE 3,
to which the QoS request is targeted, by using information of the upper layer
(Layers 5-7).
[0073]
10 Another embodiment 1
In the case where a plurality of HSSs 51 are placed in the PLMN, the
MTC- IWF entity 1 may perform HSS search to identify the HSS 51 to which an
inquiry about the internal ID of the UE 3 is to be made. In one example, the
MTC- IWF entity 1 may be preset with an address of the HSS 51 that manages
15 subscriber informat ion of the UE 3 as an MTC device. In another example, the
MTC- IWF entity 1 may use a Subscription Locator Function (SLF) or a Diameter
Routing Agent (DRA).
[0074]
In the above-described second embodiment , an example of applying a PCC
20 rule based on a QoS request specifying an appl ication by means of informat ion on
Layers 5-7 is described. Specifically, the PCRF enti ty 5 according to the second
embodiment uses DPI in the TDF in response to the QoS request specifying an
appl ication by information on Layers 5-7, and thereby obtaining information on
Layers 3 and 4 required for deciding a PCC rule (SDF template) . This operation
25 of the PCRF entity 5 may be performed for a QoS request from another node or
entity (e.g. , Application Function) which is different from the SCS 2 and the
MTC- IWF entity 1. Thus, when the node or ent ity (e.g., Application Function)
makes a QoS request to the PCRF entity 5, it is possible to flexibly specify a
specific communicat ion of the UE 3, to which the QoS request is targeted, by using
30 information of the upper layer (Layers 5-7).
[0075]
In the above-described second embodiment , an example in which the TDF
entity 57 detects appl ication traffic is described. However, it may cause an
increase in processing load of the TDF ent ity 57 to always perform the DPI for
22
detecting application traffic. Thus, the PCRF ent ity 5 may not ify the PCRF entity
57 of a period for which the DPI is to be performed, which is a period for which
the ADC rule is to be enforced, together with the ADC rule. Further, the period
for which the DPI is to be performed (period for which the ADC rule is to be
enforced) may be specified by the first QoS request , which is sent from the SCS 5 2
to the MTC- IWF enti ty 1, and the second QoS request , which is sent from the
MTC- IWF enti ty 1 to the PCRF entity 5. In other words, the first and second QoS
requests may specify a period for which a special QoS policy is to be applied to a
specific communication of the UE 3. Thus, the SCS 2 can apply a special QoS
10 policy for a desired period (time) , and the load on the TDF ent ity 57 can be
reduced.
[0076]
The operations of the MTC-IWF enti ty 1, the SCS 2, the UE 3, the PCRF
entity 5, the S-GW 55, the P-GW 56, the TDF enti ty 57, and the like described in
15 the first and second embodiments may be implemented by causing a computer
system including at least one processor (e.g. , microprocessor, Micro Processing
Unit (MPU), Central Processing Unit (CPU)) to execute a program. To be
specific, one or more programs containing instructions that cause a computer to
perform algorithms described using Figs, 2, 3 and the like the may be supplied to
20 the computer.
[0077]
These programs can be stored and provided to the computer using any type
of non-transitory computer readable medium. The non-transitory computer
readable medium includes any type of tangible storage medium. Examples of the
25 non-transitory computer readable medium include magnetic storage media (such as
flexible disks, magnetic tapes, hard disk drives, etc.), opt ical magnetic storage
media (e.g. , magneto-optical disks), Compact Disc Read Only Memory (CD-ROM),
CD-R, CD-R/W, and semiconductor memories (such as mask ROM, Programmable
ROM (PROM), Erasable PROM (EPROM), flash ROM, Rand om Access Memory
30 (RAM), etc.). These programs may be provided to a computer using any type of
transitory computer readable medium. Examples of the transi tory computer
readable medium include electric signals, optical signals, and electromagnetic
waves. The transitory computer readable medium can provide the programs to a
23
computer via a wired communication line (e.g. , electric wires, and opt ical fibers)
or a wireless communication line.
[0078]
Another embodiment 2
A novel embodiment which is different from the above-described first an5 d
second embodiments is described hereinafter. The novel embodiment described
hereinafter can be implemented independently of the above -described first and
second embodiments and able to solve a different problem from those of the first
and second embodiments.
10 [0079]
Fig. 5 is a diagram showing a configuration example of a wireless
communicat ion system according to this embodiment . An MTC device 61 can
connect to a PLMN 62 and can communicate with an MTC server 63 through the
PLMN 62. The MTC device 61 can be also referred to as a UE that executes an
15 MTC UE application. The MTC device 61 may be an MTC gateway device.
[0080]
A Public Land Mobile Network (PLMN) 62 is a 3GPP network, i.e., a
Universal Mobile Telecommunications System (UMTS) or an Evolved Packet
System (EPS), for example. The PLMN 62 includes a Radio Access Network
20 (RAN) and a core network. To be more specific, the PLMN 62 includes a base
station as a RAN node, a mobili ty management node as a control-plane entity of
the core network (e.g., an MME or a control plane function of an SGSN), and a
data transfer node as a user-plane entity of the core network (e.g., a P-GW, an
S-GW, a GGSN, or a user plane function of an SGSN). Further, the PLMN 62
25 may include a Machine Type Communicat ion Inter Working Function (MTC- IWF)
that allows an M2M service layer containing an MTC server 63 to interwork with
the PLMN 62.
[0081]
The MTC server 63 connects an M2M appl ication 64 to the PLMN 62 and
30 allows the M2M appl ication 64 to communicate with the MTC device 61 through
services served by the PLMN 62. The MTC server 63 is also referred to as a
Service Capability Server (SCS) or an M2M server.
[0082]
24
The M2M application 64 is placed outside the PLMN 62 (i.e., placed in an
external network) , executes an M2M application (MTC applicat ion) , and
communicates with an MTC UE application implemented in the MTC device 61.
The M2M applicat ion 64 is generally controlled by an M2M service provider (MTC
service provider). The M2M application 64 is also referred to as an M25 M
appl ication server or an MTC application server.
[0083]
The operation of the MTC device 61, the PLMN 62, and the MTC server 63
according to this embodiment is described in further detail below. In response to
10 an attach of the MTC device 61 to the PLMN 62 (Step S601), the PLMN 62
operates to notify the MTC server 63 of the attach of the MTC device 61 to the
PLMN 62 (Step S602). Note that , an attach of the MTC device 61 to the PLMN
62 means that mobility management of the MTC device 61 is started in the PLMN
62. For example, in the example of the EPS, the MTC device 61 is registered in
15 the MME of the PLMN 62 and transitions from the EPS Mobility Management
(EMM)-DEREGISTERED state to the EMM-REGISTERED state. In other words,
after the MTC device 61 has attached to the PLMN 62, the PLMN 62 can reach the
MTC device 61 by paging. Thus, stated differently, the PLMN 62 notifies the
MTC server 63 that the MTC device 61 can be reached by paging.
20 [0084]
The MTC server 63 receives an attach notification (S602) of the MTC
device 61 from the PLMN 62 and recognizes that it can now communicate with the
MTC device 61. Accordingly, the MTC server 63 may start communicat ing with
the MTC device 61 (Step S603).
25 [0085]
The operations in Steps S601 to S603 is particularly effect ive in the case
where the MTC server 63 cannot accurately recognize the period when it can
communicate with the MTC device 61 through the PLMN 62. One example is the
case where the MTC device 61 stops the operat ion of a communication module in
30 most times in order to reduce power consumption. In this case, the MTC device
61 may have a wake/sleep schedule that is set by the MTC server 63. The
wake/sleep schedule defines a wake period and a sleep period. During the wake
period, the MTC device 61 has attached to the PLMN 62 and can communicate with
the MTC server 63 through the PLMN 62. During the sleep period, the MTC
25
device 61 has detached from the PLMN 62 and cannot respond to paging from the
PLMN 6, and thus the MTC server 63 cannot communicate with the MTC device
61.
[0086]
The MTC device 61 may communicate wi th the PLMN 62 even during th5 e
sleep period in response to a certain trigger event . However, the MTC server 63
cannot know the fact that the MTC device 61 has attached to the PLMN 62 (i.e. , it
can start communicat ion with the MTC device 61) except for the predetermined
wake period. Further, there can be a case where the MTC device 61 does not
10 attach to the PLMN 62 even during the wake period when there is no data to be
sent or when specified conditions for transmission are not satisfied. Furthermore,
there is a possibility that an internal clock in the MTC device 61 is not accurate
enough, and accordingly the wake/sleep schedule of the MTC device 61 is not
synchronous with the wake/ sleep schedule of the MTC server 63. In those cases,
15 the MTC server 63 cannot accurately know the fact that the MTC device 61 has
attached to the PLMN 62 (i.e., it can start communication with the MTC device
61).
[0087]
Therefore, as described above, by informing the MTC server 63 that the
20 MTC device 61 has attached to the PLMN 62 (i.e., communication with the MTC
device 61 can be started), the PLMN 62can increase the opportunities for the MTC
server 63 to communicate with the MTC device 61.
[0088]
This embodiment can be applied effectively to, for example, the case
25 where the MTC device 61 is coupled to a water gauge of a river and reports a
measured water level to the MTC server 63 or the M2M application 64. A short
wake period (e.g., 1 minute) and a long sleep period (e.g., 6 hours) may be set to
the MTC device 61 by the MTC server 63. Further, the MTC device 61 may
report a new measurement result only when a measured water level exceeds a
30 specified threshold. The MTC device 61 may not report any measurement result
for a long time (e.g., several months) as long as the water level is normal.
[0089]
However, when one or more measurement results have been reported from
one or several water gauges (MTC devices 61) and the measurement result(s)
26
indicates a value that alarms the occurrence of a flood, it is preferred to
immediately and frequent ly obtain measurement results of other water gauges
(MTC devices 61) to more specifically recognize the current situation. In this
case, it is preferred to update the wake/sleep schedule of all the relevant MTC
devices 61 (e.g., MTC devices 61 installed in the same river) immediately5 .
According to the operation in Steps S601 to S603 described above, the MTC server
62 can accurately recognize that i t is possible to start communication with the
MTC device 61 (i.e. , mobile terminated communicat ion), and thus the MTC server
62 can immediately send a new wake/sleep schedule also to the MTC device 62
10 from which no measurement result is reported.
[0090]
Fig. 6 is a sequence diagram showing a specific example of the operation
in Steps S601 to S603 described with reference to Fig. 5. In the example of Fig. 6,
the PLMN 62 includes an MME 621 and an MTC- IWF entity 622. In Step S701,
15 the MTC device 61 sends an ATTACH REQUEST to the MME 621 and initiates an
attach procedure with the MME 621. In Step S702, the MME 621 sends to the
MTC- IWF entity 622 a notificat ion indicat ing the attach of the MTC device 61 to
the PLMN 62. In Step S702, in response to the notification from the MME 621,
the MTC-IWF ent ity 622 sends to the MTC server 63 a notification indicating the
20 attach of the MTC device 61 to the PLMN 62. In Step S704, the MTC server 62
sends a new wake/sleep schedule to the MTC device 61 through the PLMN 62.
The new wake/sleep schedule may be sent via an E-mail, a Short Message Service
(SMS) message, or a Multimedia Messaging Service (MMS), for example.
[0091]
25 Further, the above-described embodiments are merely an exemplificat ion
of application of the technical ideas obtained by the present inventor. The
technical ideas are not limited to the above-described embodiments, and various
changes and modifications may be made as a matter of course.
[0092]
30 For example, the whole or part of the embodiments disclosed above can be
described as, but not limited to, the fol lowing supplementary notes.
[0093]
(Supplementary note 1)
A Policy and Charging Rules Function (PCRF) entity, including:
27
a control unit configured to, in response to detection of a specific packet
flow from user traffic sent or received by a mobile station through a bearer already
set up, provides, to a PCRF node having a Policy and Charging Enforcement
Function (PCEF), a first Policy and Charging Control (PCC) rule to be applied to
the specific packet flow5 .
[0094]
(Supplementary note 2)
The PCRF entity according to Supplementary note 1, in which the first
PCC rule is different from a second PCC rule to be applied to the user traffic.
10 [0095]
(Supplementary note 3)
The PCRF entity according to Supplementary note 1 or 2, in which the
provision of the first PCC rule to the PCEF node triggers generat ion of a new
dedicated bearer for transferring the specific packet flow.
15 [0096]
(Supplementary note 4)
The PCRF entity according to any one of Supplementary notes 1 to 3, in
which
the control unit provides, to a TDF node having a Traffic Detection
20 Function (TDF), an Application Detection and Control (ADC) rule for detecting
the specific packet flow, and
the control unit provides the first PCC rule to the PCEF node in response
to detection of the specific packet flow by the TDF node .
[0097]
25 (Supplementary note 5)
The PCRF entity according to Supplementary note 4, in which
the ADC rule contains an application name specifying the specific packet
flow, and
the first PCC rule indicates at least one of a source address, a destination
30 address, a port number , and a protocol identifier , which have been detected by the
TDF node for the specific packet flow based on the application name.
[0098]
(Supplementary note 6)
28
The PCRF entity according to any one of Supplementary notes 1 to 3, in
which
the mobile station is a Machine Type Communication (MTC) device, and
the control unit provides the first PCC rule to the PCEF node in response
to receiving from a Machine Type Communication Inter Working Functio5 n
(MTC- IWF) entity a request for quality of service to be applied to a specific
communicat ion of the MTC device.
[0099]
(Supplementary note 7)
10 The PCRF entity according to Supplementary note 4 or 5, in which
the mobile station is a Machine Type Communication (MTC) device, and
the control unit provides the ADC rule to the TDF node in response to
receiving from a Machine Type Communication Inter Working Function
(MTC- IWF) entity a request for quality of service to be applied to a specific
15 communicat ion of the MTC device.
[0100]
(Supplementary note 8)
The PCRF entity according to Supplementary note 4, 5 or 7, in which the
control unit notifies the TDF node of a period when the ADC rule is to be enforced.
20 [0101]
(Supplementary note 9)
The PCRF entity according to Supplementary note 7, in which
the request contains designation of a period when quality of service is to
be applied to the specific communication, and
25 the control unit notifies the TDF node of the period when the ADC rule is
to be enforced, which is determined based on the period when the quality of
service is to be applied.
[0102]
(Supplementary note 10)
30 A control method performed by a Policy and Charging Rules Funct ion
(PCRF) entity, the control method including:
in response to detection of a specific packet flow from user traffic sent or
received by a mobile station through a bearer already set up, providing, to a PCRF
29
node having a Policy and Charging Enforcement Function (PCEF) , a first Policy
and Charging Control (PCC) rule to be applied to the specific packet flow.
[0103]
(Supplementary note 11)
The control method according to Supplementary note 10, in which the firs5 t
PCC rule is different from a second PCC rule to be applied to the user traffic.
[0104]
(Supplementary note 12)
The control method according to Supplementary note 10 or 11, in which
10 the provision of the first PCC rule to the PCEF node triggers generat ion of a new
dedicated bearer for transferring the specific packet flow.
[0105]
(Supplementary note 13)
The control method according to any one of Supplementary notes 10 to 12,
15 in which the providing includes
sending, to a TDF node having a Traffic Detection Function (TDF) , an
Application Detection and Control (ADC) rule for detecting the specific packet
flow, and
providing the first PCC rule to the PCEF node in response to detection of
20 the specific packet flow by the TDF node.
[0106]
(Supplementary note 14)
The control method according to Supplementary note 13, in which
the ADC rule contains an application name specifying the specific packet
25 flow, and
the first PCC rule indicates at least one of a source address, a destination
address, a port number , and a protocol identifier , which have been detected by the
TDF node for the specific packet flow based on the application name.
[0107]
30 (Supplementary note 15)
The control method according to any one of Supplementary notes 10 to 12,
in which
the mobile station is a Machine Type Communication (MTC) device, and
30
the providing includes providing the first PCC rule to the PCEF node in
response to receiving from a Machine Type Communication Inter Working
Function (MTC- IWF) ent ity a request for quality of service to be appl ied to a
specific communication of the MTC device.
[01085 ]
(Supplementary note 16)
The control method according to Supplementary note 13 or 14, in which
the mobile station is a Machine Type Communication (MTC) device, and
the sending includes sending the ADC rule to the TDF node in response to
10 receiving from a Machine Type Communication Inter Working Function
(MTC- IWF) entity a request for quality of service to be applied to a specific
communicat ion of the MTC device.
[0109]
(Supplementary note 17)
15 A program for causing a computer to perform a control method related to a
Policy and Charging Rules Function (PCRF), in which the control method
includes:
in response to detection of a specific packet flow from user traffic sent or
received by a mobile station through a bearer already set up, providing, to a PCRF
20 node having a Policy and Charging Enforcement Function (PCEF) , a first Policy
and Charging Control (PCC) rule to be applied to the specific packet flow.
[0110]
(Supplementary note 18)
A network node placed in a Public Land Mobile Network (PLMN),
25 including:
a control unit configured to, in response to an attach of a Machine Type
Communication (MTC) device to the PLMN, sends, to an MTC server placed
outside the PLMN, a notification indicat ing that a communication with the MTC
device is possible.
30 [0111]
(Supplementary note 19)
The network node according to Supplementary note 18, in which the
network node is a Machine Type Communication Inter Working Function
(MTC- IWF) entity.
31
[0112]
(Supplementary note 20)
A method performed by a network node placed in a Public Land Mobile
Network (PLMN), including:
in response to an at tach of a Machine Type Communication (MTC) devic5 e
to the PLMN, sending, to an MTC server placed outside the PLMN, a notification
indicating that a communication with the MTC device is possible.
[0113]
(Supplementary note 21)
10 The method according to Supplementary note 20, in which the network
node is a Machine Type Communication Inter Working Function (MTC- IWF)
entity.
[0114]
This applicat ion is based upon and claims the benefit of priority from
15 Japanese patent application No. 2014-002755, filed on January 9, 2014, the
disclosure of which is incorporated herein in its entirety by reference.
Reference Signs List
[0115]
1 MACHINE TYPE COMMUNICATION INTER WORKING FUNCTION
20 (MTC- IWF) ENTITY
2 SERVICE CAPABILITY SERVER (SCS)
3 USER EQUIPMENT (UE)
4 MTC APPLICATION SERVER
11, 12 SIGNALING INTERFACE (OR REFERENCE POINT)
25 31 MTC UE APPLICATION
51 HOME SUBSCRIBER SERVER (HSS)
52 DIAMETER ROUTING AGENT (DRA)
53 MOBILITY MANAGEMENT ENTITY (MME)
54 RADIO ACCESS NETWORK (RAN)
30 55 SERVING GATEWAY (S-GW)
56 PACKET DATA NETWORK GATEWAY (P-GW)
57 TRAFFIC DETECTION FUNCTION (TDF)
101 CONTROL UNIT
501 CONTROL UNIT
32
561 SIGNALING UNIT
562 PACKET PROCESSING UNIT
571 SIGNALING UNIT
572 DETECTION UNIT
5
33
WE CLAIM:
1. A Machine Type Communication Inter Working Funct ion (MTC- IWF)
entity comprising:
control means for, in response to receiving from a Service Capabilit5 y
Server (SCS) a first request for quality of service to be applied to a specific
communicat ion of a Machine Type Communi cation (MTC) device, sending to a
Policy and Charging Rule Function (PCRF) entity a second request for applying
the quality of service to the specific communication.
10
2. The MTC- IWF ent ity according to Claim 1, wherein the first request
specifies the quality of service by indicating at least one of a QoS Class Identifier
(QCI), an Allocat ion and Retention Priority (ARP), a Maximum Bit Rate (MBR), a
Guaranteed Bi t Rate (GBR) , and a priority level .
15
3. The MTC- IWF ent ity according to Claim 1 or 2, wherein the first
request specifies the specific communication by indicating: (a) an applicat ion
name; or (b) at least one of a source address, a dest ination address, a port number ,
and a protocol identifier for identifying a packet flow of the specific
20 communicat ion.
4. The MTC- IWF ent ity according to any one of Claims 1 to 3, wherein
the first request contains an external ident ifier associated with the MTC
device,
25 the control means exchanges a control message with a Home Subscriber
Server (HSS) and thereby obtaining, based on the external ident ifier , an internal
identifier that is associated with the MTC device and is used in a Public Land
Mobile Network (PLMN), and
the second request contains the internal identifier for identifying the MTC
30 device.
5. The MTC- IWF enti ty according to any one of Claims 1 to 4, wherein the
control means exchanges a control message with a Diameter Routing Agent (DRA)
and thereby deciding a PCRF enti ty to which the second request is to be sent .
34
6. The MTC- IWF enti ty according to any one of Claims 1 to 5, wherein the
control means decides a charging polity to be applied to the specific
communicat ion in response to receiving the first request.
5
7. A control method performed by a MTC Inter Working Function
(MTC- IWF) entity, the control method comprising:
in response to receiving from a Service Capabi lity Server (SCS) a first
request for quality of service to be applied to a specific communication of a
10 Machine Type Communication (MTC) device, sending to a Policy and Charging
Rule Function (PCRF) entity a second request for applying the quality of service to
the specific communication.
8. A non-transi tory computer readable medium storing a program for
15 causing a computer to perform a control method re lated to a Machine Type
Communication Inter Working Function (MTC- IWF), wherein the control method
comprises:
in response to receiving from a Service Capabi lity Server (SCS) a first
request for quality of service to be applied to a specific communication of a
20 Machine Type Communication (MTC) device, sending to a Policy and Charging
Rule Function (PCRF) entity a second request for applying the quality of service
requested by the first request to the specific communication.
9. A Policy and Charging Rules Funct ion (PCRF) entity comprising:
25 control means for, in response to receiving from a Machine Type
Communication Inter Working Function (MTC- IWF) entity a request for quality of
service to be applied to a specific communication of a Machine Type
Communication (MTC) device, performing control for applying the quality of
service to the specific communication.
30
10. The PCRF enti ty according to Claim 9, wherein the control means
controls at least one of a PCRF node having a Policy and Charging Enforcement
Function (PCEF) and a TDF node having a Traffic Detection Function (TDF) in
order to apply the quality of service to the specific communicat ion.
35
11. The PCRF enti ty according to Claim 10, wherein
in response to receiving the request , the control means provides, to the
TDF node, an Application Detection and Control (ADC) rule for detecting a
specific packet flow related to the specific communicat ion from user traffic sent o5 r
received by the MTC device through a bearer already set up , and
in response to detection of the specific packet flow by the TDF node, the
control means provides, to the PCEF node, a Policy and Charging Control (PCC)
rule to be applied to the specific communication.
10
12. The PCRF enti ty according to Claim 11, wherein
the ADC rule contains an application name specifying the specific
communicat ion, and
the PCC rule indicates at least one of a source address, a destination
15 address, a port number , and a protocol identifier of the specific packet flow, which
have been detected by the TDF node for the specific packet flow based on the
appl ication name.
13. The PCRF enti ty according to Claim 11 or 12, wherein the control
20 means notifies the TDF node of a period when the ADC rule is to be enforced.
14. The PCRF enti ty according to Claim 13, wherein
the request contains designation of a period when the quality of service is
to be applied to the specific communication, and
25 the control means not ifies the TDF node of the period when the ADC rule
is to be enforced, which is determined based on the period when the quality of
service is to be applied.
15. A control method performed by a Policy and Charging Rules Function
30 (PCRF) entity, the control method comprising:
in response to receiving from a Machine Type Communicat ion Inter
Working Funct ion (MTC- IWF) enti ty a request for quality of service to be applied
to a specific communication of a Machine Type Communication (MTC) device,
36
performing control for applying the quality of service to the specific
communicat ion.
16. A non-transitory computer readable medium storing a program for
causing a computer to perform a control method related to a Policy and Chargin5 g
Rules Function (PCRF), wherein the control method comprises:
in response to receiving from a Machine Type Communicat ion Inter
Working Funct ion (MTC- IWF) enti ty a request for quality of service to be applied
to a specific communication of a Machine Type Communication (MTC) device,
10 performing control for applying the quality of service to the specific
communicat ion.