Load control from control plane CIoT EPS optimization

Abstract

A core network node supporting Control Plane CIoT (Celluar Internet of Things) EPS (Evolved Packet System) Optimization includes a transmitter configured to transmit to a radio access network node an information indicating overload from data transfer via the Control Plane CIoT EPS Optimization. A radio access network node includes a receiver configured to receive, from a core network node, an information indicating overload from data transfer via Control Plane CIoT (Celluar Internet of Things) EPS (Evolved Packet System) Optimization.

Claims

1. A mobility management node comprising: one or more memories storing instructions; and one or more processor configured to process the instructions to: store a control plane data back-off timer for Control Plane Cellular Internet of Things (CIoT) Optimization per a User Equipment (UE); and transmit, to a radio access network node, the control plane data back-off timer to restrict a request from the UE for data transmission via the Control Plane CIoT Optimization, under overload conditions from data transfer via a Control plane, wherein the control plane data back-off timer does not apply to the UE for data transfer via a User plane.

2. A communication method for a mobility management node, the communication method comprising: storing a control plane data back-off timer for Control Plane Cellular Internet of Things (CIoT) Optimization per a User Equipment (UE); and transmitting, to a radio access network node, the control plane data back-off timer to restrict a request from the UE for data transmission via the Control Plane CIoT Optimization, under overload conditions from data transfer via a Control plane, wherein the control plane data back-off timer does not apply to the UE for data transfer via a User plane.

3. A user Equipment (UE) comprising: one or more memories storing instructions; and one or more processors configured to process the instructions to: receive a control plane data back-off timer for Control Plane Cellular Internet of Things (CIoT) Optimization via a radio access network node from a mobility management node that is under overload conditions and stores the control plane data back-off timer per the UE; and not initiating any data transmission via the Control Plane CIoT Optimization while the control plane data back-off timer is running, wherein the control plane data back-off timer does not apply to data transfer via a User plane.

4. A communication method of a User Equipment (UE), the communication method comprising: receiving a control plane data back-off timer for Control Plane Cellular Internet of Things (CIoT) Optimization via a radio access node from a mobility management node that is under overload conditions and stores the control plane data back-off timer per the UE; and not initiating any data transmission via the Control Plane CIoT Optimization while the control plane data back-off timer is running, wherein the control plane data back-off timer does not apply to data transfer via a User plane.

Description

BRIEF DESCRIPTION OF DRAWINGS

(1) FIG. 1 (from TS23.401, s 5.3.4B.2) is a timing diagram illustrating Mobile Originated data transfer via Control Plane CIoT EPS optimization;

(2) FIG. 2 (from TS23.401, s 5.3.4B.3) is a timing diagram illustrating Mobile Terminated data transfer via Control Plane CIoT EPS optimization;

(3) FIG. 3 is a timing diagram illustrating an eNodeB initiated Connection Suspend procedure;

(4) FIG. 4 is a timing diagram illustrating a UE initiated Connection Resume procedure;

(5) FIG. 5 is a timing diagram illustrating handling of a C-Plane data back-off timer while UE is attached for Control Plane CIoT EPS Optimisation;

(6) FIG. 6 is a timing diagram illustrating handling of a C-Plane data back-off timer during registration;

(7) FIG. 7 is a timing diagram illustrating C-Plane CIoT data overload start and stop;

(8) FIG. 8 is a timing diagram illustrating C-Plane and U-Plane CIoT weight factors configuration via MME Configuration Update procedure;

(9) FIG. 9 is a timing diagram illustrating C-Plane and U-Plane CIoT weight factors update via S1 Setup procedure;

(10) FIG. 10 illustrates schematically a cellular (tele)communication system to which embodiments of the disclosure may be applied;

(11) FIG. 11 is a block diagram of a mobile device forming part of the system shown in FIG. 10;

(12) FIG. 12 is a block diagram of a base station forming part of the system shown in FIG. 10;

(13) FIG. 13 is a block diagram of a mobility management entity forming part of the system shown in FIG. 10; and

(14) FIG. 14 is a block diagram of a gateway forming part of the system shown in FIG. 10.

DESCRIPTION OF EMBODIMENTS

(15) Description of the Solutions with Embodiments

(16) One main idea of the proposed solution is to limit the transmission of data PDU(s) from the UE to the network (MME/SGSN) over the control plane applying the CIoT EPS Optimizations whereas the UE is still able to transmit control plane signalling (e.g. for TAU/RAU procedures or Service Request). The transmission limitation of data PDU(s) can be applied either as 1) no data PDU transmission for a certain time period or 2) as limited transmission rate for a certain time period (e.g. using a designated back-off timer). This main idea is described below in the alternatives in solution 1 or solution 2.

(17) Solution 1—C-Plane Data Back-Off Timer

(18) One possible solution to restrict the overload of the network (e.g. network control plane entity like MME, SGSN, CIoT-EPC Node and etc.) from data transfer via Control Plane CIoT EPS Optimisation (both, for IP and non-IP data) is to limit the transmission from the UE for a given time. In particular, it is proposed to introduce a back-off timer (called C-Plane data back-off timer or any other name with similar meaning like wait timer and etc) to restrict the UE from attempting data transmission via Control Plane CIoT EPS Optimisation during the duration of this timer. The back-off timer for Control Plane data does not prevent the UE to send a Service Request for any non Control Plane data services. This solution is demonstrated with the message sequence chart in FIG. 5.

(19) 1) A UE 3 establishes RRC connection with intention to transmit data via Control Plane CIoT EPS Optimisation.

(20) 2) The data is transferred to eNodeB 5 via the NAS data PDU within the RRC Connection Setup Complete message or any other RRC message. If the data is concatenated, the NAS data PDU may contain indication/flag for more data to follow or end of data.

(21) 3) The NAS PDU sent in step 2 is relayed to the MME 9 by the eNodeB 5 using a S1 Initial UE message.

(22) 4) Option 1 (step 4 & 5): If MME 9 is overloaded (e.g. load reached operator defined data/signalling load threshold), the MME 9 may reject the data transmission via Control Plane CIoT EPS Optimisation by releasing the S1 context with S1 Context Release Command to eNB and the MME 9 may include C-Plane data back-off timer.

(23) Alternatively, in case the UE 3 is using multiple PDN connections, the MME 9 can have different NAS data PDU transmission thresholds for different PDN connections identified by APNs. The different data PDU transmission thresholds via Control Plane CIoT EPS optimisation for different PDN connections can be based a) on operator configurations, or b) local settings in the serving node (MME/SGSN), or c) UE or APN subscriptions, or d) service requirements from 3.sup.rd party or e) congestion or temporarily unavailability of a U-plane entity like PGW or congestion or temporarily unavailability of the SCEF; f) on any other data limitation per APN. In such case the MME 9 can apply the C-Plane data back-off timer for data transmitted to/from a specific APN. Correspondingly, in the UE 3 the C-Plane data back-off timer is applied only for data transmission via Control Plane CIoT EPS Optimisation to the concerned APN. The UE 3 may transmit data PDUs belonging to other established PDN connections or to initiate the establishment of new PDN connections belonging to APNs different from the APN to which the C-Plane data back-off time applies.

(24) The applicability of the C-Plane data back-off timer for all data PDU transmission or for data PDU transmission per PDN connection can be indicated to the UE 3 either 1) by using different timer types and/or APN indication; or 2) by using the same timer type, but a new indication for timer applicability, or 3) by using the same timer type but including the APN indication in the NAS message from MME/SGSN to the UE 3.

(25) 5) Then the eNodeB 5 sends a RRC Connection Release message to the UE 3 in Acknowledged Mode and includes the C-Plane data back-off timer. When the UE 3 receives C-Plane data back-off timer, the UE 3 shall not attempt another for data transfer via Control Plane CIoT EPS Optimisation while the C-Plane data back-off timer is running or until UE re-selects to a cell from another MME service area.

(26) 6) Option 2: If the MME 9 is not overloaded, the MME 9 establishes bearers towards the P-GW (if already not established) and forwards further the uplink data.

(27) 7) A downlink data or acknowledgment may arrive as a response to the uplink data.

(28) 8) If downlink data arrives, it is encapsulated in a NAS data PDU and sent to the eNodeB in a S1 Downlink Message. If MME 9 is now overloaded (e.g. reached operator defined load threshold or an overload indication was received with the downlink data), the MME 9 may include C-Plane data back-off timer in the NAS data PDU.

(29) Alternatively the MME/SGSN can apply the limitation per PDN connection as shown in Option 1) above, e.g. in step 4.

(30) 9) The eNodeB 5 sends a RRC Downlink Data message including the downlink data and the C-Plane data back-off timer encapsulated in NAS data PDU.

(31) 10) Option 3: Alternatively, if MME 9 is overloaded (e.g. reached operator defined load threshold) or an overload indication was received with the downlink data, the MME 9 may include C-Plane data back-off timer in the S1 Context Release Command to eNodeB 5.

(32) 11) Then the eNodeB 5 sends a RRC Connection Release message to the UE 3 in Acknowledged Mode and includes the C-Plane data back-off timer.

(33) When a UE 3 receives C-Plane data back-off timer, the UE 3 shall not attempt another data transmission via Control Plane CIoT EPS Optimisation while the C-Plane data back-off timer is running or until UE re-selects to a cell from another MME service area.

(34) Please note that in the above description the term C-Plane data back-off timer is used, but in general this can be a time period, i.e. a C-Plane data back-off time. After the recipient of the signalling message (e.g. the UE) processes the C-Plane data back-off time, the UE 3 would start an internal C-Plane data back-off timer. Also, the MME/SGSN can start an internal C-Plane data back-off timer in order to monitor or verify the UE's behaviour, whether the UE 3 applies the instructed C-Plane data back-off time.

(35) Please also note that the above described solution may be interpreted is a way that the data PDUs transmission rate via Control Plane CIoT EPS Optimization is limited to “0” (zero) during the time period of the C-Plane data back-off time. In addition to this solution, alternatively the C-plane functional entity (MME/SGSN) can enforce a data PDU transmission rate limitation factor. For example this data PDU transmission rate limitation factor can be 50% or 20%, which means that the UE 3 should reduce the data PDU transmission rate via Control Plane CIoT EPS Optimisation by 50% (compared to the previous allowed transmission rate) for the time period of the C-Plane data back-off time. In another alternative solution, the MME/SGSN may inform the UE about an absolute value of a new data PDU transmission rate via Control Plane CIoT EPS Optimisation, which is supposed to be lower than the currently applied one. This value of a new data PDU transmission rate is applied during the duration of the C-Plane data back-off time. The optional parameters “data PDU transmission rate limitation factor” and “new data PDU transmission rate” described herewith are not shown in FIG. 5, but one or multiple of these new parameters can be included in the messages shown in steps 4/5 or 8/9 or 10/11.

(36) The C-plane functional entity (MME/SGSN) possesses means to derive an appropriate value for the C-Plane data back-off timer. It may depend on various factors as mentioned already in step 4 in FIG. 5.

(37) Another use case where the C-Plane data back-off timer could be used is to restrict the UEs to Attach/TAU/RAU for data transmission via Control Plane CIoT EPS Optimisation when the MME 9 is overloaded (or close to overload or reached an operator set threshold) and the operator wants to back-off further UEs attaching for data transmission via Control Plane CIoT EPS Optimisation. The MME 9 may consider UE subscription data (e.g UE features like low priority, delay tolerant and etc) in deciding whether and which UEs to restrict from attaching for data transmission via Control Plane CIoT EPS Optimisation for the duration of the C-Plane data back-off timer. This is demonstrated with the message sequence chart in FIG. 6:

(38) 1) The UE 3 initiates a registration procedure by transmission of an Attach/TAU/RAU Request. The UE 3 includes the Preferred Network Behaviour parameter where the UE 3 indicates support for Control Plane CIoT EPS Optimisation or User Plane CIoT EPS Optimisation or both. The UE 3 also indicates its preferred CIoT EPS Optimisation (i.e. Control Plane CIoT EPS Optimisation or User Plane CIoT EPS Optimisation)

(39) 2) The eNodeB 5 selects an MME 9 that supports the preferred CIoT EPS Optimisation indicated by the UE 3 and forwards the NAS message to that MME 9.

(40) 3a) If the UE 3 indicated support for both, Control Plane and User Plane CIoT EPS Optimisation and preference for Control Plane CIoT EPS Optimisation and the MME 9 is overloaded or close to overload (e.g. reached operator defined threshold load), the MME 9 may decide to accept registration for User Plane CIoT EPS Optimisation only. In this case the UE 3 is allowed to initiate data transmission via User Plane CIoT EPS Optimisation only.

(41) 3b) If the UE 3 indicated support for both, Control Plane and User Plane CIoT EPS Optimisation and preference for Control Plane CIoT EPS Optimisation and the MME 9 is overloaded or close to overload (e.g reached operator defined threshold load), the MME 9 may decide to accept the registration request for Control Plane EPS Optimisation however, the MME 9 may include in the registration accept (e.g. Attach/TAU/RAU accept) message C-Plane data back-off timer in order to restrict the UE 3 from attempts for data transmission via Control Plane CIoT EPS Optimisation for the duration of the C-Plane data back-off timer. The UE 3 is allowed for data transmission via User Plane CIoT EPS Optimisation if registered for it. The UE 3 shall not initiate data transfer via Control Plane CIoT EPS Optimisation until the expiry of the C-Plane data back-off timer.

(42) 3c) If the UE 3 indicated support for both, Control Plane and User Plane CIoT EPS Optimisation and preference for Control Plane CIoT EPS Optimisation and the MME 9 is overloaded or close to overload (e.g reached operator defined threshold load), the MME 9 may decide to reject registration for Control Plane CIoT EPS Optimisation and it may include C-Plane data back-off timer in order to restrict the UE 3 from further attempts to register for Control Plane CIoT EPS Optimisation for the duration of the C-Plane data back-off timer.

(43) Solution 1 is equally applicable as for 3G and 2G mobile network and terminals where SGSN stands for MME and RNC/BS stands for eNodeB, as well for 5G mobile networks and terminals.

(44) Solution 2—C-Plane CIoT Data Overload Message

(45) Solution 2 proposes that if the control plane entity of the network (e.g. MME or SGSN or CIoT-EPC Control Node and etc) gets overloaded (e.g. the load reaches a threshold set by the mobile network operator) and the main source for the overload is from data transfer via Control Plane CIoT EPS Optimisation, the MME may send Overload Start Message to eNodeB with C-Plane CIoT data parameter (or any other parameter with similar meaning) so that the eNodeB does not select that MME for data transfer via Control Plane CIoT EPS Optimisation or eNodeB rejects a request for data transfer via Control Plane CIoT EPS Optimisation if no other MME with that capability is available. This solution is demonstrated on FIG. 7.

(46) 1) Requests from UE(s) 3 for data transfer via Control Plane CIoT EPS Optimisation. The Control Plane CIoT EPS Optimisation preference is indicated within the RRC signalling (e.g RRC Connection Setup Complete or any other RRC message).

(47) 2) The eNodeB 5 forwards the requests from the UE(s) to MME_1 9-1 which is Control Plane CIoT Optimisation capable.

(48) 3) At some stage MME_1 9-1 gets overloaded from data transfer via Control Plane CIoT EPS Optimisation (i.e load from data transfer via Control Plane CIoT EPS Optimisation reaches a threshold defined by the operator). Then the MME_1 9-1 may send Overload Start message to eNodeB 5 and includes C-Plane CIoT data parameter meaning any further requests for data transfer via Control Plane CIoT EPS Optimisation shall not be forwarded by eNodeB 5 to MME_1 9-1 until MME_1 9-1 sends Overload Stop message with C-Plane CIoT data parameter in it.

(49) 4) Another UE 3 establishes a RRC connection with intention to transmit data via Control Plane CIoT EPS Optimisation. The data is transferred to eNodeB 5 via the NAS data PDU within the RRC Connection Setup Complete message or any other RRC message.

(50) 5a) As MME_1 9-1 is now overloaded (e.g. reached a threshold set by the operator) the eNodeB 5 starts routing all requests for data transfer via Control Plane CIoT EPS Optimisation to another MME that is Control Plane CIoT EPS Optimisation capable (e.g. MME_n 9-N) via S1 Initial UE message, for example.

(51) 5b) If no other MME capable of Control Plane CIoT Optimisation is available, the eNodeB 5 rejects the request from UE 3 by releasing RRC connection with RRC Connection Release message and the eNodeB may include C-Plane data back-off timer. When a UE 3 receives C-Plane data back-off timer, the UE 3 shall not attempt another data transfer via Control Plane CIoT EPS Optimisation while the C-Plane data back-off timer is running or until UE re-selects to a cell from another MME service area.

(52) 6) After some time the load from data transfer via Control Plane CIoT EPS Optimisation in MME_1 9-1 decreases below the overload threshold. Then, MME_1 9-1 send Overload Stop message including C-Plane CIoT data parameter (or any other parameter with similar meaning) to indicate that the overload from data transfer via Control Plane CIoT EPS Optimisation is over. When receives this message the eNodeB shall start considering MME_1 9-1 again when selecting an MME for data transfer via Control Plane CIoT EPS Optimisation.

(53) 7-8) eNodeB 5 starts routing the requests for data transfer via Control Plane CIoT EPS Optimisation to MME_1 9-1.

(54) Solution 3—Designated Weight Factors for Data Transfer Via Control Plane CIoT EPS Optimisation and USER Plane CIoT EPS Optimisation

(55) Solution 3 proposes to introduce weight factors for data transfer via Control Plane CIoT EPS Optimisation (C-Plane weight factor) and User Plane CIoT EPS Optimisation (U-Plane weight factor). This would allow for higher granularity Load balancing which would consider the MME load from both types of communication and also will allow to control the balance between data transfer via Control Plane CIoT EPS Optimisation and data transfer via User Plane CIoT EPS Optimisation.

(56) FIG. 8 and FIG. 9 demonstrate the way the new C-Plane weight factor and U-Plane weight factor would be configured in the eNodeB using the existing MME Configuration Update procedure and S1 Setup procedure.

(57) The eNodeB 5 uses the C-Plane weight factor and U-Plane weight factor for load balancing (MME selection) when a request from a UE for data transfer via Control Plane CIoT EPS Optimisation or User Plane CIoT EPS Optimisation is received.

(58) Technical Improvements Compared to Existing Technologies

(59) Solution 1:

(60) C-Plane data back-off timer—New type back-off timer used with AS and NAS signaling to restrict the load from data transfer via Control Plane CIoT EPS Optimisation. The MME 9 returns C-Plane data back-off timer to a UE via NAS or RRC signaling when the MME load from data transfer via Control Plane CIoT EPS Optimisation reaches a threshold set by the mobile operator. When UE receives C-Plane data back-off timer the UE shall not attempt a data transfer via Control Plane CIoT EPS Optimisation until the expiry of C-Plane data back-off timer or until it reselects to a cell from different MME service area. more data to follow or end of data flag—A new flag/parameter indication from the UE in the RRC or NAS signalling messages to indicate the last NAS data PDU when transferring concatenated NAS data PDUs via Control Plane CIoT EPS Optimisation. overload indication—A new parameter in the downlink data. If downlink data with overload indication arrives at MME the MME may include C-Plane data back-off timer in the NAS data PDU towards the UE via AS or RRC signalling. When UE receives C-Plane data back-off timer the UE shall not attempt a data transfer via Control Plane CIoT EPS Optimisation until the expiry of C-Plane data back-off timer or until it reselects to a cell from different MME service area.
Solution 2: C-Plane CIoT data—a new parameter in the Overload Start and Overload Stop messages. When an MME 9 gets overloaded from data transfer via Control Plane CIoT EPS Optimisation (i.e load from data transfer via Control Plane CIoT EPS Optimisation reaches a threshold defined by the operator), the MME 9 may send Overload Start message to eNodeB 5 and includes C-Plane CIoT data parameter meaning any further requests for data transfer via Control Plane CIoT EPS Optimisation shall not be forwarded by eNodeB 5 to this MME 9 until the MME 9 sends Overload Stop message with C-Plane CIoT data parameter, meaning the MME 9 is not overloaded anymore.
Solution 3: New C-Plane weight factor and U-Plane weight factor—to allow for higher granularity Load Balancing which would consider the MME 9 load from both types of data transfer (via Control Plane CIoT EPS Optimisation and User Plane CIoT EPS Optimisation) and also to allow to control the balance between Control Plane CIoT EPS Optimisation data and User Plane CIoT EPS Optimisation data. The new C-Plane weight factor and U-Plane weight factor would be configured in the eNodeB 5 by the MME 9 using the existing MME Configuration Update procedure and S1 Setup procedure. The eNodeB 5 uses the C-Plane weight factor and U-Plane weight factor for load balancing (MME selection) when a request from a UE for data transfer via Control Plane CIoT EPS Optimisation or User Plane CIoT EPS Optimisation is received
System Overview

(61) FIG. 10 schematically illustrates a mobile (cellular or wireless) telecommunication network 1 in which users of mobile devices 3A to 3C can communicate with each other and other users via E-UTRAN base stations 5A, 5B and a core network 7 using an E-UTRA radio access technology (RAT). As those skilled in the art will appreciate, whilst three mobile devices 3 and two base stations 5 are shown in FIG. 10 for illustration purposes, the system, when implemented, will typically include other base stations and mobile devices.

(62) As is well known, a mobile device 3 may enter and leave the areas (i.e. radio cells) served by the base stations 5 as the mobile device 3 is moving around in the geographical area covered by the telecommunication system 1. In order to keep track of the mobile device 3 and to facilitate movement between the different base stations 5, the core network 7 comprises a number of mobility management entities (MMEs) 9-1 to 9-N.

(63) The MMEs 9 are in communication with the base stations 5 coupled to the core network 7. The core network 7 also one or more gateways 18, such as a serving gateway (S-GW) 18S and/or a packet data network gateway (P-GW) 18P. Although shown separately, it will be appreciated that the functionalities of the S-GW 18S and the P-GW 18P may be provided by a single network entity, if appropriate.

(64) The mobile devices 3 and their respective serving base stations 5 are connected via an LTE air interface, the so-called “Uu” interface. The base stations 5 are connected to each other via a so-called “X2” interface. Each base station 5 is also connected to the core network nodes (such as one of the MMEs 9 and the S-GW 18S) via a so-called “S1” interface. From the core network 7, connection to an external IP network 20, such as the Internet, is also provided via the P-GW 18P. Although not shown in FIG. 10, the core network may also include further nodes, such as a home subscriber server (HSS) and/or the like.

(65) Mobile Device

(66) FIG. 11 is a block diagram illustrating the main components of one of the mobile devices 3 (or IoT device) shown in FIG. 10. As shown, the mobile device 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5 via one or more antenna 33. The mobile device 3 has a controller 37 to control the operation of the mobile device 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily shown in FIG. 11, the mobile device 3 will of course have all the usual functionality of a conventional mobile device 3 (such as a user interface 35) and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory 39 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.

(67) The controller 37 controls overall operation of the mobile device 3 by, in this example, program instructions or software instructions stored within the memory 39. As shown, these software instructions include, among other things, an operating system 41, a communications control module 43, an RRC module 44, a NAS module 45, and an IoT module 49.

(68) The communications control module 43 controls the communication between the mobile device 3 and the base station 5. The communications control module 43 also controls the separate flows of control data (Control Plane) and user data (User Plane, both uplink and downlink) that are to be transmitted to the base station 5 and other nodes (via the base station 5) such as the MME 9 and/or the S-GW 18S.

(69) The RRC module 44 is operable to generate, send and receive signalling messages formatted according to the RRC standard. For example, such messages are exchanged between the mobile device 3 and its serving base station 5. The RRC messages may include, for example, messages relating to the random access procedure and/or the RRC connection establishment/reconfiguration, and the RRC messages may also include messages comprising control data (e.g. NAS messages) to be relayed by the serving base station 5 to the MME 9.

(70) The NAS module 45 is operable to generate, send and receive signalling messages formatted according to the NAS protocol. For example, such messages are exchanged (via the base stations 5) between the mobile device 3 and the MMEs 9. The NAS messages may include, for example, the NAS messages comprising control data relating to mobility of a mobile device 3, e.g. control data for registering the mobile device 3 with an MME 9.

(71) The IoT module 49 is responsible for facilitating communications relating to ‘internet of things’ and/or other machine-type communication applications (including cellular IoT, narrowband-IoT, and wideband-IoT, if appropriate). The IoT module 49 is also responsible for managing the user plane and control plane relating to IoT communications, including user plane/control plane optimisation and associated signalling.

(72) Base Station

(73) FIG. 12 is a block diagram illustrating the main components of one of the base stations 5 shown in FIG. 10. As shown, the base station 5 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the mobile devices 3 via one or more antenna 53, a base station interface (X2) 54 for transmitting signals to and for receiving signals from other base stations, and a core network interface (S1) 55 for transmitting signals to and for receiving signals from the core network entities (e.g. the MMEs 9 and the S-GW 18). The base station 5 has a controller 57 to control the operation of the base station 5. The controller 57 is associated with a memory 59. Although not necessarily shown in FIG. 12, the base station 5 will of course have all the usual functionality of a cellular telephone network base station and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory 59 and/or may be downloaded via the communication network 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the base station 5 by, in this example, program instructions or software instructions stored within the memory 59. As shown, these software instructions include, among other things, an operating system 61, a communications control module 63, an RRC module 64, an S1AP module 67, and an IoT module 69.

(74) The communications control module 63 controls the communication between the base station 5 and the mobile devices 3 and other network entities (e.g. the MMEs 9/S-GW 18S) that are connected to the base station 5. The communications control module 63 also controls the separate flows of uplink/downlink user traffic and control data for the mobile devices 3 associated with this base station 5.

(75) The RRC module 64 is operable to generate, send and receive signalling messages formatted according to the RRC standard. For example, such messages are exchanged between the base station 5 and the mobile devices 3 that are associated with this base station 5. The RRC messages may include, for example, messages relating to the random access procedure and/or the RRC connection establishment/reconfiguration, and the RRC messages may also include messages comprising control data (e.g. NAS messages) to be relayed by the serving base station 5 to the MME 9.

(76) The S1AP module 67 is operable to generate, send and receive signalling messages formatted according to the S1 application protocol (S1AP) standard. For example, such S1AP messages are exchanged between the base station 5 and the MMEs 9 connected to this base station 5. The S1AP messages may include, for example, messages carrying NAS signalling, S1 setup messages, and associated responses.

(77) The IoT module 69 is responsible for facilitating communications relating to ‘internet of things’ and/or other machine-type communication applications (including cellular IoT, narrowband-IoT, and wideband-IoT, if appropriate). The IoT module 69 is also responsible for managing the user plane and control plane (for user equipment having IoT functionality) relating to IoT communications, including user plane/control plane optimisation and associated signalling.

(78) Mobility Management Entity

(79) FIG. 13 is a block diagram illustrating the main components of one of the MMEs 9 shown in FIG. 10. As shown, the MME 9 has a transceiver circuit 71, a base station interface (S1) 74 for transmitting signals to and for receiving signals from the base stations 5, and a core network interface 75 for transmitting signals to and for receiving signals from other core network nodes (such as other MMEs 9 and the gateways 18). The MME 9 has a controller 77 to control the operation of the MME 9. The controller 77 is associated with a memory 79.

(80) Software may be pre-installed in the memory 79 and/or may be downloaded via the communication network 1 or from a removable data storage device (RMD), for example. The controller 77 is configured to control the overall operation of the MME 9 by, in this example, program instructions or software instructions stored within the memory 79. As shown, these software instructions include, among other things, an operating system 81, a communications control module 83, a non-access stratum (NAS) module 85, an S1AP module 87, and an IoT module 89.

(81) The communications control module 83 controls the communication between the MME 9 and other network entities that are connected to the MME 9 (e.g. the base stations 5, other MMEs 9, the gateways 18, and any mobile devices 3 when connected to one of the base stations 5).

(82) The NAS module 85 is operable to generate, send and receive signalling messages formatted according to the NAS protocol. For example, such messages are exchanged (via the base stations 5) between the MME 9 and the mobile devices 3 that are associated with this MME 9. The NAS messages may include, for example, the NAS messages comprising control data relating to mobility of a mobile device 3, e.g. control data for registering the mobile device 3 with the MME 9.

(83) The S1AP module 87 is operable to generate, send and receive signalling messages formatted according to the S1 application protocol (S1AP) standard. For example, such messages are exchanged between the MME 9 and the base stations 5 connected to this MME 9. The S1AP messages may include, for example, messages carrying NAS signalling, S1 setup messages, and associated responses.

(84) The IoT module 89 is responsible for facilitating communications relating to ‘internet of things’ and/or other machine-type communication applications (including cellular IoT, narrowband-IoT, and wideband-IoT, if appropriate). The IoT module 89 is also responsible for managing the user plane and control plane (for user equipment having IoT functionality) relating to IoT communications, including user plane/control plane optimisation and associated signalling.

(85) Gateway

(86) FIG. 14 is a block diagram illustrating the main components of one of the gateways 18 shown in FIG. 10. As shown, the gateway 18 has a transceiver circuit 91, a base station interface (S1) 94 for transmitting signals to and for receiving signals from the base stations 5, and a core network interface 95 for transmitting signals to and for receiving signals from other core network nodes (such as the MMEs 9 and other gateways 18). The gateway 18 has a controller 97 to control the operation of the gateway 18. The controller 97 is associated with a memory 99.

(87) Software may be pre-installed in the memory 99 and/or may be downloaded via the communication network 1 or from a removable data storage device (RMD), for example. The controller 97 is configured to control the overall operation of the gateway 18 by, in this example, program instructions or software instructions stored within the memory 99. As shown, these software instructions include, among other things, an operating system 101, a communications control module 103, an S1AP module 107, and an IoT module 89.

(88) The communications control module 103 controls the communication between the gateway 18 and other network entities that are connected to the gateway 18 (e.g. the base stations 5, MMEs 9, other gateways 18, and any mobile devices 3 when connected to one of the base stations 5).

(89) The S1AP module 107 is operable to generate, send and receive signalling messages formatted according to the S1 application protocol (S1AP) standard. For example, such messages are exchanged between the gateway 18 and the base stations 5 connected to this gateway 18.

(90) The IoT module 109 is responsible for facilitating communications relating to ‘internet of things’ and/or other machine-type communication applications (including cellular IoT, narrowband-IoT, and wideband-IoT, if appropriate). The IoT module 109 is also responsible for managing the user plane and control plane (for user equipment having IoT functionality) relating to IoT communications, including user plane/control plane optimisation and associated signalling.

(91) Modifications and Alternatives

(92) Detailed example embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above example embodiments whilst still benefiting from the disclosure embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.

(93) In the above example embodiments, a 3GPP radio communications (radio access) technology is used. However, any other radio communications technology (i.e. WLAN, Wi-Fi, WiMAX, Bluetooth, etc.) can be used for managing transmissions of IoT devices in accordance with the above example embodiments. The above example embodiments are also applicable to ‘non-mobile’ or generally stationary user equipment.

(94) Examples of IoT Applications

(95) Some examples of Internet of Things (or MTC) applications are listed in the following table (source: 3GPP TS 22.368 V13.1.0, Annex B). This list is not exhaustive and is intended to be indicative of the scope of Internet of Things/machine-type communication applications.

(96) TABLE-US-00002 TABLE 2 Service Area IoT applications Security Surveillance systems Backup for landline Control of physical access (e.g. to buildings) Car/driver security Tracking & Tracing Fleet Management Order Management Pay as you drive Asset Tracking Navigation Traffic information Road tolling Road traffic optimisation/steering Payment Point of sales Vending machines Gaming machines Health Monitoring vital signs Supporting the aged or handicapped Web Access Telemedicine points Remote diagnostics Remote Sensors Maintenance/Control Lighting Pumps Valves Elevator control Vending machine control Vehicle diagnostics Metering Power Gas Water Heating Grid control Industrial metering Consumer Devices Digital photo frame Digital camera eBook

(97) In the above description, the mobile device, the base station, the MME, and the gateway are described for ease of understanding as having a number of discrete modules (such as the communications control modules and the RRC/NAS/S1AP/IoT modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.

(98) In the above example embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the mobile device (UE), the base station, the MME, and the gateway as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the mobile device (UE), the base station, the MME, and the gateway in order to update their functionalities.

(99) Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

(100) The whole or part of the example embodiments disclosed above can be described as, but not limited to, the following notes.

(101) (Supplementary note 1) A core network node supporting Control Plane CIoT (Celluar Internet of Things) EPS (Evolved Packet System) Optimization, comprising: a transmitter configured to transmit to a radio access network node an information indicating overload from data transfer via the Control Plane CIoT EPS Optimization.

(102) (Supplementary note 2) The core network node according to Supplementary note 1, wherein the transmitter is further configured to transmit an Overload Start Message with the information indicating the overload from the data transfer via the Control Plane CIoT EPS Optimization.

(103) (Supplementary note 3) The core network node according to Supplementary note 2, further comprising: a controller configured to request the radio access network node to not transmit a RRC (Radio Resource Control) connection request for the data transfer via the Control Plane CIoT EPS Optimization to the core network node.

(104) (Supplementary note 4) The core network node according to Supplementary note 3, wherein the controller is further configured to request the radio access network node to not accept the RRC connection request for the data transfer via the Control Plane CIoT EPS Optimization.

(105) (Supplementary note 5) The core network node according to Supplementary note 3, wherein the controller is further configured to request the radio access network node to reroute the RRC connection request for the data transfer via the Control Plane CIoT EPS Optimization to another core network node.

(106) (Supplementary note 6) A radio access network node, comprising: a receiver configured to receive, from a core network node, an information indicating overload from data transfer via Control Plane CIoT (Celluar Internet of Things) EPS (Evolved Packet System) Optimization.

(107) (Supplementary note 7) The radio access network node according to Supplementary note 6, wherein the receiver is further configured to receive an Overload Start Message with the information indicating the overload from the data transfer via the Control Plane CIoT EPS Optimization.

(108) (Supplementary note 8) The radio access network node according to Supplementary note 6 or 7, further comprising: a controller configured to not transmit a RRC (Redio Resource Control) connection request for data transfer via the Control Plane CIoT EPS Optimization to the core network node.

(109) (Supplementary note 9) The radio access network node according to Supplementary note 8, wherein the controller is further configured to not accept the RRC connection request for data transfer via Control Plane CIoT EPS Optimization to the core network node.

(110) (Supplementary node 10) The radio access network node according to Supplementary note 8, wherein the controller is further configured to reroute the RRC connection request for data transfer via Control Plane CIoT EPS Optimization to another core network node.

(111) (Supplementary note 11) The radio access network node according to any one of Supplementary notes 6 to 10, further comprising: a transmitter configured to transmit to a User Equipment (UE) a control plane data back-off timer to restrict data transfer via the Control Plane CIoT EPS Optimization when rejecting the RRC connection request for overload reason.

(112) (Supplementary note 12) The radio access network node according to Supplementary note 11, wherein the radio access network node is further configured to request the UE to not attempt a request for the data transfer via the Control Plane CIoT EPS Optimization while the control plane data back-off timer is running, by transmitting the control plane data back-off timer to the UE.

(113) (Supplementary note 13) A transmission method for a core network node supporting Control Plane CIoT (Celluar Internet of Things) EPS (Evolved Packet System) Optimization, comprising: transmitting to a radio access network node an information indicating overload from data transfer via the Control Plane CIoT EPS Optimization.

(114) (Supplementary note 14) The transmission method according to Supplementary note 13, wherein the transmitting is performed by transmitting an Overload Start Message with the information indicating the overload from the data transfer via the Control Plane CIoT EPS Optimization.

(115) (Supplementary note 15) The transmission method according to Supplementary note 14, further comprising: requesting the radio access network node to not transmit a RRC (Radio Resource Control) connection request for the data transfer via the Control Plane CIoT EPS Optimization to the core network node.

(116) (Supplementary note 16) The transmission method according to Supplementary note 15, wherein the requesting is performed by requesting not to accept the RRC connection request for the data transfer via the Control Plane CIoT EPS Optimization to the core network node.

(117) (Supplementary node 17) The transmission method according to Supplementary note 16, wherein the requesting is performed by requesting to reroute the RRC connection request for the data transfer via the Control Plane CIoT EPS Optimization to another core network node.

(118) (Supplementary note 18) A communication method, comprising: receiving, from a core network node, an information indicating overload from data transfer via Control Plane CIoT (Celluar Internet of Things) EPS (Evolved Packet System) Optimization.

(119) (Supplementary note 19) The communication method according to Supplementary note 18, wherein the receiving is performed by receiving an Overload Start Message with the information indicating the overload from the data transfer via the Control Plane CIoT EPS Optimization.

(120) (Supplementary note 20) The communication method according to Supplementary note 18 or 19, further comprising: not transmitting a RRC (Redio Resource Control) connection request for data transfer via the Control Plane CIoT EPS Optimization to the core network node.

(121) (Supplementary note 21) The communication method according to Supplementary note 20, wherein the not transmitting is performed by not accepting the RRC connection request for data transfer via Control Plane CIoT EPS Optimization to the core network node.

(122) (Supplementary note 22) The communication method according to Supplementary note 20, wherein the not transmitting is performed by rerouting the RRC connection request for data transfer via Control Plane CIoT EPS Optimization to another core network node.

(123) (Supplementary note 23) The communication method according to any one of Supplementary notes 18 to 22, further comprising: transmitting to a User Equipment (UE) a control plane data back-off timer to restrict data transfer via the Control Plane CIoT EPS Optimization when rejecting the RRC connection request for overload reason.

(124) (Supplementary note 24) The communication method according to Supplementary note 23, further comprising: requesting the UE to not attempt a request for the data transfer via the Control Plane CIoT EPS Optimization while the control plane data back-off timer is running, by transmitting the control plane data back-off timer to the UE.

(125) (Supplementary note 25) A computer program comprising computer implementable instructions for causing a programmable communications device to perform the method of any one of Supplementary notes 13 to 24.

(126) (Supplementary note 26) A system comprising the radio access network node according to Supplementary note 6; and the core network node according to Supplementary note 1.

(127) While the invention has been particularly shown and described with reference to example embodiments thereof, the invention is not limited to these embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the claims.

(128) This application is based upon and claims the benefit of priority from European Patent Application No. EP16275049.1, filed on Apr. 1, 2016, the disclosure of which is incorporated herein in its entirety by reference.