Technical Field
[0001]
This invention relates to method for enforcement of non-IP data policing over service exposure function.
Background Art
[0002]
The following abbreviations and terminology (whenever differently stated) are used in the current invention:
[0003]
[Table 1]

[0004]
The following terminologies are used within this invention.
[0005]
The terms ‘serving node’ or ‘MME/SGSN’ or ‘MSC/SGSN/MME’ or C-SGN (CIoT Serving Gateway Node) is generally used through the various embodiments of this invention to describe a functional entity like MSC, or SGSN or MME, or C-SGN or other possible control plane functional entity in the mobile network which terminate the control plane signalling (known as NAS signalling) between the core network and the terminal. The serving node (MME/SGSN) can be also a functional entity from future generation networks which is responsible for mobility and session management.
[0006]
The term HSS/HLR means the repository where the UE’s subscription data is stored and can be either an HSS or an HLR or a combined entity.
[0007]
The terms ‘terminal’, or ‘device’, or ‘user terminal’ or ‘UE’ (User Equipment) or ‘MT’ (Mobile Terminal) are used in an inter-exchangeable manner where all of the terms express the similarly the equipment used to send/receive data and signalling from network or mobile network or radio access network.
[0008]
In the recent years due to the penetration of Internet of Things (IoT) and Machine-to-Machine (M2M) technologies the standard bodies like 3rd Generation Partnership Project (3GPP) start working on improvements known as Machine Type Communication (MTC) since Release 10. In order to even more reduce the price of end devices and the price in the operator’s network for serving such devices, 3GPP carried out a work called Cellular IoT (CIoT). This work studied and evaluated the architecture enhancement to support ultra-low complexity, power constrained, and low data-rate IoT devices. The documentation of this study is captured in the document 3GPP TR23.720. The conclusions were 1) to specify a mandatory control plane (CP) solution, which is documented in section 2 in the TR and 2) to specify optionally user plane (UP) solution, which is documented in section 18 in the TR. Therefore the CP solution is also referenced as ‘solution 2’ and the UP solution is referenced as ‘solution 18’.
[0009]
The EPS optimized for CIoT supports traffic pattern that is different as compared to the normal UEs and may support only sub-set and necessary functionalities as compared with the existing EPS. An EPS optimized for CIoT can be enabled by having sub-set of functionalities implemented in single logical entity C-SGN (CIoT Serving Gateway Node). Mobility and Attach procedures are performed as described in other clauses for corresponding entities MME, S-GW and P-GW. An example single node non-roaming CIoT architecture is shown in Figure 1. The detailed description of the reference points (interfaces) can be found in specification 3GPP TS23.401 and 3GPP TS23.682.
[0010]
The selection between CP or UP solution happens during Attach procedure or during a TAU procedures. The UE indicates a ‘Preferred Network Behaviour’ including the following:
　　　　- Whether Control Plane CIoT EPS optimisation is supported;
　　　　- Whether User Plane CIoT EPS optimisation is supported;
　　　　- Whether Control Plane CIoT EPS optimisation is preferred or whether User Plane Plane CIoT EPS optimisation is preferred;
　　　　- Whether S1-U data transfer is supported;
　　　　- Whether SMS transfer without Combined Attach is requested;
　　　　- Whether Attach without PDN Connectivity is supported.
The serving node sends in the Attach or TAU accept message the ‘Supported Network Behaviour’ information.
[0011]
In the CIoT EPS optimisations the UE can support "Attach without PDN connectivity", which mean that no PDN connectivity, and thus, no EPS bearers are established during the Attach procedure. The UE can request a PDN connectivity (IP or non-IP) at later point of time using NAS (E)SM signaling.
[0012]
If the serving node configures the CP CIoT EPS optimization to be used, the data is transferred between UE and the serving node in NAS PDUs including the EPS bearer Identity of the PDN connection they relate to. Both the IP and non-IP data types are supported. This is accomplished by using the NAS transport capabilities of RRC and S1-AP protocols and the data transport of GTP-u tunnels between MME and S-GW and between S-GW and P-GW, or if a Non-IP connection is provided by via the MME with the SCEF, then data transfer occurs as indicated in TS 23.682 [74].
[0013]
Figure 2 shows a signaling flow of mobile originated (MO) data transmission for Control Plane CIoT EPS Optimisation (i.e. CP solution). This figure is according to TS23.401. When using CP solution for user data transport, the MME (for uplink, UL) and UE (for downlink, DL) uses the EPS Bearer Identity (EBI) contained within the NAS PDUs to identify the associated EPS bearer.
[0014]
If the MME wishes to use the CP solution for mobile terminating (MT) services, then an example procedure is shown in Figure 3 from TS23.401.
[0015]
The CIoT EPS optimisations can also apply to LTE (EUTRAN) system. In particular, the main intention is to cover wide-band (WB) EUTRN UEs (e.g. cat-M) with low cost properties. However, if a WB EUTRAN UE capable of NB-IoT uses NB-IoT solutions (CP or UP solution), there could be several restrictions when changing RATs. For example, if the UE has activated non-IP connection, then the UE may not reselect 2G/3G access and continue using the non-IP connection.
[0016]
The non-IP Data Delivery (NIDD) via SCEF will be capture in 3GPP TS23.682, as currently the 3GPP Tdoc S2-160832 (which needs to be implemented in TS23.682) shows the procedures. NIDD may be used to handle mobile originated (MO) and mobile terminated (MT) communication with UEs, where the packets used for the communication are not based on the internet protocol (IP). The configuration of the SCEF for the delivery of the non-IP data is shown in Figure 4 description and detailed description can be found in 3GPPTdoc S2-160832.
[0017]
For example purposes, Figure 5 shows the procedure using which the SCS/AS sends non-IP data to a given user as identified via External Identifier or MSISDN. This procedure assumes that procedures in establishment of EPS bearer for non-IP data and SCEF configuration procedure (as per Figure 4) are completed.
Citation List
Non Patent Literature
[0018]
nplcit 1 : 3GPP TS23.401 v144.0, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access; Stage 2, v13.5.0, 2015-12
nplcit 2 : 3GPP TR23.720, Architecture enhancements for Cellular Internet of Things; v1.2.0, 2015-11
nplcit 3 : 3GPP TS23.203, Policy and charging control architecture; v13.5.1, 2015-09
Summary of Invention
Technical Problem
[0019]
Problem description
One important feature/characteristic, which is considered for network design, is the data rate (or data amount or number of transmissions per time period) transmitted over a certain period of time. Usually the data rate is measured in bits per second, whereas data amount is measured in bytes per hour or per day or per week, etc. Measures for data rate limitation or throttling can be taken by the network if the data rate exceeds certain limit or allowed data rate. Usually the data rate limitation or traffic shaping over the UP is performed in the PGW (for DL data) and at eNB for UL data. Since non-IP data is considered to be transmitted over CP only and may be routed from the serving node towards SCEF, new mechanisms (not currently available) are needed.
In particular, mechanism(s) is needed to limit the data rate in both uplink (DL) and downlink (DL) for non-IP data transmission (also known as NIDD)
[0020]
In addition to the data rate limitation, data amount limitation, number of data transmissions limitation, etc., for non-IP data different priorities or QoS parameters can be applied. Currently there are no mechanisms to deal with such features.
[0021]
A situation for data rate exceed can happen if an application of an UE or an application in Application server (AS) misbehaves.
Solution to Problem
[0022]
In one aspect, the invention provides a rate controlling method for non-IP data using CIoT EPS optimization, comprising: limiting a message rate of the non-IP data based on at least one of a configured message rate control parameter in a Service Capability Exposure Function, SCEF, and based on an indicated message rate control parameter by a core network node.
[0023]
In one aspect, the invention provides a control node for non-IP data using CIoT EPS optimization, comprising: means configured to limit a message rate of the non-IP data based on at least one of a configured message rate control parameter in a Service Capability Exposure Function, SCEF, and based on an indicated message rate control parameter by a core network node.
[0024]
In one aspect, the invention provides a rate controlling method for non-IP data using CIoT EPS optimization, comprising: informing a user equipment, UE, and a SCEF, Service Capability Exposure Function, of a message rate control that a serving PLMN (Public Land Mobile Network) intends to limit a message rate of the non-IP data based on an indicated message rate control parameter.
[0025]
In one aspect, the invention provides a core network node for rate controlling of non-IP data using CIoT EPS optimization, comprising: means configured to inform a user equipment, UE, and a SCEF, Service Capability Exposure Function, of a message rate control that a serving PLMN (Public Land Mobile Network) intends to limit a message rate of the non-IP data based on an indicated message rate control parameter.
[0026]
In one aspect, the invention provides a communication method used in a user equipment, UE, for non-IP data using CIoT EPS optimization, comprising: receiving a message rate control parameter from a core network node; and limiting a message rate at which the UE generates uplink data to comply with a policy corresponding to the message rate control parameter.
[0027]
In one aspect, the invention provides a User Equipment, UE, for rate controlling of non-IP data using CIoT EPS optimization, comprising: receiving means configured to receive a message rate control parameter from a core network node; and limiting means configured to limit a message rate at which the UE generates uplink data to comply with a policy corresponding to the message rate control parameter.
Advantageous Effects of Invention
[0028]
　　　　(1) Dynamic policy enforcement over SCEF is applied without the involvement of PCRF.
　　　　(2) The policy enforcement includes the amount/volume of data transmitted over large period of time (e.g. day, week). The application at SCS/AS is informed in case or enforced data limitation.
Brief Description of Drawings
[0029]
[fig. 1] Figure 1 shows an example single node non-roaming CIoT architecture.
[fig. 2] Figure 2 shows a signaling flow of mobile originated (MO) data transmission for Control Plane CIoT EPS Optimisation (i.e. CP solution).
[fig. 3] Figure 3 shows signaling flow for MT Data transport in NAS PDUs.
[fig. 4] Figure 4 shows configuration if SCEF for NIDD procedure.
[fig. 5] Figure 5 shows the procedure using which the SCS/AS sends non-IP data to a given user as identified via External Identifier or MSISDN.
[fig. 6] Figure 6 shows signaling flow for policy information setup in the SCEF.
[fig. 7] Figure 7 shows the T6 reconfiguration (or modify) procedure.
[fig. 8] Figure 8 shows a possible solution for enforcement of data limitation in the DL.
[fig. 9] Figure 9 shows an example signaling flow for the solution of data rate limitation enforcement for UL data.
[fig. 10] Figure 10 shows a block diagram for UE.
[fig. 11] Figure 11 shows a block diagram for RAN node.
[fig. 12] Figure 12 shows a block diagram for serving node.
[fig. 13] Figure 13 shows a block diagram for HSS/HLR or SCFF.
Description of Embodiments
[0030]
In order to solve the above described problem, different solutions are described in various embodiments herewith.
[0031]
As described in the problem description in this invention, it is assumed that non-IP data is transferred over the control plan (CP) encapsulated in NAS PDUs between the UE and serving node (MME). For the transmission of non-IP data, one or multiple non-IP bearers can be setup depending on the number of applications using non-IP data and the configuration of the UE or service agreement between the service provider and network operator. For example in one configuration multiple Application can be configured to use the same APN, or in another configuration each application can be configured with a separate APN. The setup of a non-IP bearer can happen in advance before the UE’s application or the application on the network side (i.e. SCS/AS) start sending data. This is sometimes needed especially for the MT data transmission (or DL data) as the SCEF need to be configured with routing information, e.g. for the connection establishment over the T6 (or T6a or T6b) interface.
[0032]
The solution introduced herewith is referred as solution 1.
[0033]
Once the application in the UE and AS start exchanging data in UL or DL, some functional entity in the 3GPP domain needs to perform traffic counting and charging policy functionality. This functionality is similar to the functionality performed by PCEF, which is considered as part of PGW, where the data counting in UL and DL is performed, charging records are generated, traffic shaping can be applied, etc., based on either preconfigured policy or via a dynamic policy exchange with the PCRF.
[0034]
This solution proposes that such policy functionality is performed by the SCEF. The SCEF can apply one of the following policies or any combinations of them: DL rate limitation (per bearer or for all non-IP bearers), or UL rate limitation (per bearer or for all non-IP bearers), or limitation of data rate per bearer, or limitation of data rate for all non-IP bearers (optionally for both UL and DL together). One example of data rate can be 2000 bytes per day in UL and 4000 bytes of data in the DL; whereas another example can be that all non-IP data sent in both UL and DL per day do not exceed 10 Kbytes. After detecting that a data limit was hit, SCEF may execute certain actions.
[0035]
One problem to solve is how the policy information for rate limitation per bearer or aggregated rate for all non-IP bearers or other limitation parameters (e.g. which time period of the day transmission is allowed to/from a UE) is configured in the SCEF. In this invention the information to be configured in the SCEF is referred as ‘policy information’ and includes, but not limited to:
　　　　- Gating control: including the limitation of maximum data amount to be transmitted per UE, or per APN, or per PDN connection, or per bearer, etc. For example this parameter can be 3000 bytes per day; or 10 Kbytes per week, or similar.
Alternatively another limitation can be the aggregated maximum data rate, e.g. 200 bits per second. One such existing parameter, which can be used, is the AMBR (Aggregate Maximum Bit Rate), which is applicable e.g. per UE, e.g. called UE-AMBR applicable separately for both UL and DL.
　　　　- QoS control, including (1) the prioritization of a single non-IP data packet related to other non-IP packets within a single bearer or (2) the prioritization of one non-IP bearer over other(s) non-IP bearer.
　　　　- Usage Monitoring Control: to apply usage monitoring for the accumulated usage of network resources on a per non-IP bearer/session and user basis;
　　　　- Other information for traffic policy as per TS23.203.
[0036]
For the gating (or other data limitation) functionality in the SCEF there are several alternatives possible. At least one of following information can be exchanged instead of “maximum data amount”.
a) total data volume which UE allowed receive or send for a certain period (e.g. minute/hour/day/week);
b) max throughput or data rate (per certain period(e.g. second/hour/day/week):
c) max number of single transmissions, e.g. transmission of non-IP packets (per certain period(e.g. second/hour/day/week));
d) a flag to indicate if total data volume which UE will receive exceeds/lowers a threshold.
Also, two or more parameters among a) - d) can be exchanged together as the alternative information.
[0037]
In general, it is proposed that the ‘policy information/parameters’ for the non-IP connection(s) (meaning for non-IP APNs) is configured and stored in the SCEF. The following options can be used to configure the SCEF with the ‘policy information/parameters’:
　　　　A. SCEF is statically configured by the operator (similar what is available today for PCEF). This can be applied for example by preconfiguring specific policies per APN. Each UE having a connection over the SCEF and using the specific APN would be under the constraints of the pre-configured policies for this APN.
　　　　B. SCEF is configured via the HSS/HLR (basically the UE subscription repository).
　　　　C. SCEF is configured via the serving node (e.g. MME or SGSN) during the establishment of T6 connection.
　　　　D. SCEF is configured via the PCRF.
[0038]
The applicability of option D is a bit questionable, as for a cheap IoT devices there may not be provisioning in the PCRF. One reason to limit the network operational costs and avoid PCRF provisioning, but also other reason can be that there are no GBR or dedicated bearers foreseen to be used for IoT devices.
[0039]
Option B can be performed during the establishment of T6 connection (PDN connection) between the SCEF and MME for a given UE. It is proposed that the SCEF fetches the UE’s subscription (or the relevant part of the UE’s subscription) from the HSS/HLR in order to store e.g. the UE’s External ID or other parameters. During this exchange between SCEF and HSS/HLR the SCEF receives also the subscription parameters related to the non-IP APN(s) and the corresponding subscribed policy information (e.g. AMBR, amount/volume of data limitation, QoS information, etc.). Then the SCEF uses this subscription data to configure the policies to be applied to the UE, or more specifically to a given PDN connection.
[0040]
Option B can be performed during the NIDD configuration procedure shown on Figure 4. During the exchange between SCEF and HSS the signaling can be extended to include ‘policy information/parameters’ for example in the NIDD Authorization Response (Result) message. A new format of this message can be:
NIDD Authorization Response (Result, APN (or UE) policy rules/information for non-IP) message.
[0041]
In the following, the configuration option C is described in details. The configuration with the policy information is performed during the connection setup over the T6a/T6b interface. This is exemplary shown on Figure 6.
[0042]
The support of accounting functionality in SCEF for NIDD is optional. Depending on operator configuration the MME, SCEF and IWK-SCEF support accounting functionality for NIDD via SCEF.
Accounting information shall be generated for every NIDD request and response messages.
Accounting information, e.g. number of successful NIDD Submit Request, number of failed NIDD Submit Request etc is collected by the MME, SCEF, and IWK-SCEF for intra-operator use, and also for inter-operator settlements.
Note that the details of the required accounting information are outside the scope of this specification.
The NIDD via SCEF feature shall support charging in accordance with TS 32.240 [28]. Interaction with Offline Charging systems shall be supported.
[0043]
The steps from Figure 6 are described as follows:
　　　　Step (1) UE performs Attach procedure. As part of the Attach procedure the serving node (e.g. MME) retrieves the UE’s subscription data from the subscription repository (e.g. HSS). The UE’s subscription data for non-IP connectivity may contain ‘policy information’ for the non-IP data. Such policy information can be but not limited to e.g. the AMBR or maximum data rate for all non-IP data, or for single non-IP PDN connection. When the UE requests the establishment of non-IP PDN connectivity during Attach procedure or as in independent procedure later, e.g. both cases are described in PDN Connectivity procedure (see TS 23.401), the serving node initiates the establishment of T6 (e.g. T6a) connection.
　　　　Step (2) The serving node sends Create SCEF Connection Request (User Identity, EPS Bearer Identity, policy information) message to the SCEF. The User Identity includes UE’s IMSI, or MSISDN, or External ID(s). The combination of EPS Bearer Identity and User Identity allows the SCEF to uniquely identify the PDN connection to the SCEF for a given UE. In addition the serving node can send the ‘policy information’ parameter(s) (also known as Information Element) for the non-IP data as described above. The policy information can have the same content as received from the HSS during step (1), but it is also possible that the MME modifies the subscription policy information based on local configuration. In case that the MME does not receive policy information from the HSS, MME can derive/generate policy based on local configuration.
　　　　Step (3) When receiving the Create SCEF Connection Request message, the SCEF processes the information correspondingly. If ‘policy information’ parameter(s) is contained in the message, the SCEF start internal processes for corresponding monitoring/inspection of the non-IP data to be transmitted. The SCEF creates and sends an SCEF EPS Bearer Context for the UE ID. The SCEF sends Create SCEF Connection Response (User Identity EPS Bearer Identity) message to the MME confirming establishment of PDN connection to the SCEF for the UE.
[0044]
It is possible that a particular UE can be connected to multiple SCEFs for multiple non-IP PDN connections. In such case, the serving node should derive the appropriate ‘policy information/parameters’ set for the corresponding SCEF. The serving node informs via steps (2) and (3) each SCEF with the corresponding ‘policy parameters’ during T6 connection establishment.
[0045]
It is also possible that a particular UE may have multiple non-IP applications and if separate PDN connections are needed for different applications, then different APNs are used for establishment of different non-IP PDN connections. In the proposed solution in Figure 6, this would mean that the serving node (e.g. MME) needs to generate ‘policy parameters’ set per APN or per PDN connection. These different ‘policy parameters’ set is exchanged between MME and SCEF during the T6 connection establishment.
[0046]
Dynamic configuration of policy information (policy rules) is possible triggered by the MME. For example based on criteria like (1) increased UEs of the same type or (2) increased delay for transmission of non-IP data over the NAS protocol, or (3) increased load in the radio access network, or any other reason, the MME can decide to start a procedure to update the policy information in the SCEF. It is assumed that the MME is able to derive new policy information (new policy rules) based on the above mentioned criteria. It is also assumed that the MME stores the previously configured policy information to the SCEF. Once the MME derives new/updated policy information (policy rules), the MME can initiate a Configuration Update procedure towards the SCEF. Such a procedure can be e.g. T6 Connection Reconfiguration procedure initiated by the MME towards the SCEF.
[0047]
Figure 7 shows the T6 reconfiguration (or modify) procedure. Please note that this procedure can be also considered as non-IP PDN Connection or non-IP EPS bearer reconfiguration (or modification) procedure. With other words the T6 connection reconfiguration may be impacted based on the PDN connection reconfiguration. This procedure can be used to update or modify some of the non-IP PDN connection (or non-IP EPS bearer) parameters configured between the serving node MME/SGSN and SCEF. For example using this reconfiguration or modify procedure, the MME can initiate reconfiguration of some policy parameters or QoS parameters.
[0048]
The steps from Figure 7 are described as follows:
　　　　1. Based on various inputs the MME may be aware about an update of the non-IP APN parameters like policy, QoS, priority, limitations, etc.
For example, as shown in step 1.1 a reconfiguration of existing connections or PDN connection update, or based on UE mobility event, or something else, the MME may be informed about the updated parameters.
　　　　In another example shown on step 1.2, the HSS may internally updated the subscription parameters which may influence the policing of data traffic, especially if update of the subscription parameters for a particular non-IP APN.
It is also possible that the MME derives new policy parameters by itself (i.e. internally).
　　　　2. The MME requests Reconfigure (or Modify) T6 Connection procedure towards the SCEF. This message can exemplary called Modify (or Reconfiguration) T6 Connection request message. This message contains the changed or updated parameters for a T6 connection, i.e. policy information, updated UE-AMBR, updated max. amount of data, etc.
　　　　3. After receiving the request for reconfiguration or modification of T6 connection from the MME, the SCEF updates the UE’s context (various policy or QoS parameters) stored in the SCEF. If the processing of the received message in the SCEF if successful, the SCEF sends a Modify (or Reconfiguration) T6 Connection response message.
In case that the SCEF fails to process the message from step 2) or the update of the UE’s context fail, the SCEF sends a Modify (or Reconfiguration) T6 Connection response message containing a corresponding failure cause value.
[0049]
Please note that the ‘T6 Reconfiguration (or Modify) procedure’ can be also used by the MME/SGSN to change MME/SGSN identities used for the T6 connection. In the reverse direction the SCEF can also inform the MME/SGSN about changed T6 end-point identifiers (T6 EPI). With other words, the ‘T6 Reconfiguration (or Modify) procedure’ can be used to reconfigure (or exchange) the corresponding T6 entity about the changed T6 end-point identifiers (T6 EPI). This can be used in a similar way as the exchange of GTP TEID.

Claims
[Claim 1]
A rate controlling method for non-IP data using CIoT EPS optimization, comprising:
　　　　limiting a message rate of the non-IP data based on at least one of a configured message rate control parameter in a Service Capability Exposure Function, SCEF, and based on an indicated message rate control parameter by a core network node.
[Claim 2]
The rate controlling method according to claim 1, wherein
　　　　the configured message rate control parameter includes information per Access Point Network, APN.
[Claim 3]
The rate controlling method according to claim 1 or 2, further comprising:
　　　　transmitting an instruction corresponding to the configured message rate control parameter towards a user equipment, UE, for causing the UE to comply with the instruction.
[Claim 4]
The rate controlling method according to any one of claims 1 to 3, further comprising:
　　　　receiving from the core network node a create SCEF (Service Capability Exposure Function) connection request message including the indicated message rate control parameter; and
　　　　starting the limiting the message rate of the non-IP data based on the indicated message rate control parameter.
[Claim 5]
The rate controlling method according to claim 4, wherein
　　　　the receiving the create SCEF connection request message is performed during a T6a/b connection establishment.
[Claim 6]
The rate controlling method according to any one of claims 1 to 5, wherein
　　　　at least one of the configured message rate control parameter and the indicated message rate control parameter is separate for uplink and downlink and in a form of the number of packets per time unit.
[Claim 7]
The rate controlling method according to any one of claims 1 to 6, wherein
　　　　the limiting the message rate of the non-IP data is performed by discarding or delaying at least one packet.
[Claim 8]
A control node for non-IP data using CIoT EPS optimization, comprising:
　　　　means configured to limit a message rate of the non-IP data based on at least one of a configured message rate control parameter in a Service Capability Exposure Function, SCEF, and based on an indicated message rate control parameter by a core network node.
[Claim 9]
The control node according to claim 8, wherein
　　　　the configured message rate control parameter includes information per Access Point Network, APN.
[Claim 10]
The control node according to claim 8 or 9, further comprising:
　　　　means configured to transmit an instruction corresponding to the configured message rate control parameter towards a user equipment, UE, for causing the UE to comply with the instruction.
[Claim 11]
The control node according to any one of claims 8 to 10, further comprising:
　　　　means configured to receive from the core network node a create SCEF (Service Capability Exposure Function) connection request message including the indicated message rate control parameter; and
　　　　means configured to start the limiting the message rate of the non-IP data based on the indicated message rate control parameter.
[Claim 12]
The control node according to claim 11, wherein
　　　　the means configured to receive receives the create SCEF connection request message during a T6a/b connection establishment.
[Claim 13]
The control node according to any one of claims 8 to 12, wherein
　　　　at least one of the configured message rate control parameter and the indicated message rate control parameter is separate for uplink and downlink and in a form of the number of packets per time unit.
[Claim 14]
The control node according to any one of claims 8 to 13, wherein
　　　　the means configured to limit limits the message rate of the non-IP data by discarding or delaying at least one packet.
[Claim 15]
A rate controlling method for non-IP data using CIoT EPS optimization, comprising:
　　　　informing a user equipment, UE, and a SCEF, Service Capability Exposure Function, of a message rate control that a serving PLMN (Public Land Mobile Network) intends to limit a message rate of the non-IP data based on an indicated message rate control parameter.
[Claim 16]
A core network node for rate controlling of non-IP data using CIoT EPS optimization, comprising:
　　　　means configured to inform a user equipment, UE, and a SCEF, Service Capability Exposure Function, of a message rate control that a serving PLMN (Public Land Mobile Network) intends to limit a message rate of the non-IP data based on an indicated message rate control parameter.
[Claim 17]
A communication method used in a user equipment, UE, for non-IP data using CIoT EPS optimization, comprising:
　　　　receiving a message rate control parameter from a core network node; and
　　　　limiting a message rate at which the UE generates uplink data to comply with a policy corresponding to the message rate control parameter.
[Claim 18]
A User Equipment, UE, for rate controlling of non-IP data using CIoT EPS optimization, comprising:
　　　　receiving means configured to receive a message rate control parameter from a core network node; and
　　　　limiting means configured to limit a message rate at which the UE generates uplink data to comply with a policy corresponding to the message rate control parameter.
[Claim 19]
A system comprising the control node according to claim 8; and the core network node according to claim 16.
[Claim 20]
A computer program comprising computer implementable instructions for causing a programmable communications device to perform the method of any one of claims of 1 to 7, 15 and 17.